[SOLVED] Guest network for AirPort Extreme (VLAN 1003)

Software SW help
1

I’m a brand new user of Turris Omnia. The default Omnia setup works for my basic needs, but I also wanted to setup a guest VLAN for visitors in my house.

In my LAN I have 2 wifi routers from Apple (they are not in a bridge, they are independent APs with the same SSID name/password). When guests connect to them via guest SSID, their traffic gets tagged as VLAN 1003 (and untagged traffic should not be repeated to them).

I was able to setup guest interface, guest firewall zone and VLAN eth0.1003 on my Turris, see[1].

With this setup my LAN works just as expected, DHCP works, assigns subnet 192.168.3.x addresses and I’m able to use the internet. All works the same when I connect via Apple wifi router through non-guest SSID.

The problem is in connecting to Apple wifi router via guest SSID. It works only partially:

  1. DHCP works, assigns subnet 192.168.4.x IPs
  2. I can ping router at 192.168.4.254

But I cannot ping any further. I cannot ping 10.0.0.252 (router’s IP on WAN side) or any other valid IP on public internet.
When working from my Mac machine commands like route or traceroute spit cryptic errors like these:

$ route get 77.75.77.73
route: writing to routing socket: not in table

So I cannot even diagnose stuff from affected machine. I was unable to employ any logging or monitoring tools to help me on router side.

I don’t have much experience configuring routers. Went through Turris forums, openwrt wiki and googled a lot. Also I experimented with firewall, switch and interface settings via LuCI and ssh. No luck.

My theory is that Turris does not tag packets as VLAN 1003 on the way back. And Apple’s router simply ignores them because it treats them as untagged traffic which should stay in LAN only.

Also please note that similar setup works on my previous MikroTik router which I achieved fiddling with Webfig web interface. I believe I did everything the same.

Any ideas / hints how to troubleshoot and possibly fix this would be greatly appreciated. Thank you.

[1] https://gist.github.com/darwin/3229599ec8077129661dc3b9e00f75c9

2

The obvious troubleshooting would be to run tcpdump on both internal and external interface and even on the end device. Since your devices properly get assigned IPv4 addresses from DHCP, there is probably not a problem in not tagging some packets. It looks more like a problem with firewall. Please check using tcpdump, whether packets are lost on their way to towards the Internet or on the return path. This could give you some more clues.

3

Thanks for the tcpdump hint. That was the tool I was looking for.

So from tests on affected machine (connected via guest SSID) and compared to unaffected machine connected via non-guest SSID it looks like routing is somehow misconfigured.

When monitoring all packets on unaffected machine, ping first issues an ARP request, gets reply. And then starts pinging, the same it is on affected machine when pinging 192.168.4.254 (the only working ping):

When pinging some public IP on affected machine, e.g 212.58.244.22 (bbc.com), no ARP request is issued and tcpdump is silent (I’ve tried several new public IPs which are unlikely to be cached)

Ping packets from affected machine are not visible on Turris router.

4

My posts were flagged when trying to post more gist links :frowning:

5

a netstat from affected machine (connected via guest SSID)

netstat -nr                                                                                                                                  16:31:39
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.4.254      UGScI           3        0     en0
127                127.0.0.1          UCS             1        0     lo0
127.0.0.1          127.0.0.1          UH              6    87272     lo0
169.254            link#4             UCS             1        0     en0
192.168.4          link#4             UCS             1        0     en0
192.168.4.210/32   link#4             UCS             1        0     en0
192.168.4.254/32   link#4             UCS             3        0     en0
192.168.4.254      d8:58:d7:0:35:49   UHLWIir         2       15     en0    836
224.0.0            link#4             UmCSI           1        0     en0
255.255.255.255/32 link#4             UCSI            1        0     en0

Internet6:
Destination                             Gateway                         Flags         Netif Expire
::1                                     ::1                             UHL             lo0
fe80::%lo0/64                           fe80::1%lo0                     UcI             lo0
fe80::1%lo0                             link#1                          UHLI            lo0
fe80::%en0/64                           link#4                          UCI             en0
fe80::4c5:b712:d3af:367a%en0            9c:20:7b:92:e4:32               UHLWIi          en0
fe80::6203:8ff:fe8e:d85e%en0            60:3:8:8e:d8:5e                 UHLI            lo0
fe80::6e70:9fff:fed0:9810%en0           6c:70:9f:d0:98:10               UHLWIi          en0
fe80::7aca:39ff:fefd:cebd%en0           78:ca:39:fd:ce:bd               UHLWIi          en0
fe80::da58:d7ff:fe00:3549%en0           d8:58:d7:0:35:49                UHLWIi          en0
fe80::%awdl0/64                         link#8                          UCI           awdl0
fe80::1412:28ff:fe42:c93c%awdl0         16:12:28:42:c9:3c               UHLI            lo0
ff01::%lo0/32                           ::1                             UmCI            lo0
ff01::%en0/32                           link#4                          UmCI            en0
ff01::%awdl0/32                         link#8                          UmCI          awdl0
ff01::%en4/32                           link#10                         UmCI            en4
ff02::%lo0/32                           ::1                             UmCI            lo0
ff02::%en0/32                           link#4                          UmCI            en0
ff02::%awdl0/32                         link#8                          UmCI          awdl0
ff02::%en4/32                           link#10                         UmCI            en4
6

You mean you don’t see outgoing echo requests even on the same machine which is supposed to send them? Then there’s something broken in that machine. Not seeing ARP for non-local hosts is normal, ARP is link-local address resolution protocol, it is not used for off-link destinations (such datagrams are forwarded to the gateway)

7

Yes, I don’t see outgoing echo requests

Observations:

  1. Tried from 2 independent machines (MacOS 10.11 and 10.12) - same behaviour (completely silent tcdump while ping is running)
  2. When switching wifi connection on the same machine to non-guest SSID, it works as expected.
8

Got further with my investigations.

The netstat -nr routing table on affected machine looks fine at first glance, but simple commands like route -n get default or route -n get 8.8.8.8 are failing with route: writing to routing socket: not in table. That is suspicious.

I’ve done rigorous comparison of netstat -nr between failing guest SSID and working non-guest SSID on the same machine. And I noticed only one difference. In flags in default route, failing routing table has additional “I”. I wasn’t able to google what that flag means. Even downloading latest sources for net-tools and inspecting source code did not reveal its purpose. I think this is something specific for Apple’s fork of net-tools.

I wanted to try to setup flags and remove the “I” to match working config. I tried to remove the default route and that failed with the same route: writing to routing socket: not in table error.

And finally I tried sudo route -n flush, which reported deletion of default route. Then I added a new default route with the same parameters: sudo route add default 192.168.4.254. And voila! Pings started working, the internet connections is up. netstat -nr prints “UGSc” flags instead of troublesome “UGScI”.

So this is the root of the trouble. Now I need to figure out why is the routing table generated this way. Is it a fault of the DHCP server?

9

Here is explanation what I flag means:

1 Like
10

You should be able to delete the ifscoped routes if you give -ifp INTERFACE as an argument to the route delete command.

And I found this explanation about Apple’s default routing selection for you:

If you look at the routing table on an iOS device using a tool such as System Status, you will see that when multiple networks are available at the same time (such as WiFi and cellular), iOS will usually mark the lower priority interfaces with the RTF_IFSCOPE flag (“I”) and the interface without this flag will be the dominant interface, where OpenVPN or other network apps like Safari will open connections on this interface by default. Normally, iOS considers WiFi to be a higher priority than cellular data, so if both are available, iOS usually sets the RTF_IFSCOPE flag on the cellular data interface to favor WiFi.

From OpenVPN ignores connected WiFi and uses cellular data - OpenVPN Support Forum

1 Like
11

Thanks for the info @white.

Interesting is that that flush + add fixed the issue on the other machine as well. Now I’m commenting connected via guest SSID. And netstat -nr shows “UGSc” on both machines although I have not performed the fix on this one. Also restarting OS from fresh persist with good settings.

I wonder if it is possible that some of my early attempts to configure Turris somehow confused APs in my LAN so that they then somehow provided problematic routing. And that poisoned routing tables on both of my machines. Quite a stretch, but I have no idea how routing gets propagated.

Anyways it works for me now. I below is a link to my final working configs just for the record. Thank you all for the help.

http://pastebin.com/9e7i1sxd

12

Just for record.

Today I hit this issue again but only while trying to setup the secondary WIFI AP in Turris (no AirPorts involved).

Exactly the same issue as described here (without solution):
https://discussions.apple.com/thread/7158805

13

Ok, after additional tinkering with my setup I found source of the issue and how to permanently fix it.

This RTF_IFSCOPE flag is somehow forced by DHCP server or rather its misconfiguration.

I fixed it by setting list dhcp_option '6,192.168.5.254' on my wlan1 interface, where 192.168.5.0/24 is the wlan1 subnet and 192.168.5.254 is the IP address of my router/gateway running my own DHCP and DNS server.

I’m a networking noob, but my theory is that having traffic properly routed into a separate network interface (tun0 managed by OpenVPN in my case) and no explicit DHCP/DNS config, the wifi connection tries to ask for DHCP in tun0 and someone there gives misleading info (maybe no info at all). And macOS networking subsystem decides that the interface is not ready and adds RTF_IFSCOPE flag there (maybe while assuming there is another non-scoped interface available).

Anyways the dhcp_option tweak reproducibly fixed the issue and removing it reproducibly brings it back.