OS X 10.10.5: IPv6 default route on Wifi doesn't disappear

Got a problem with Viscosity or need help? Ask here!

danielmanser

Posts: 12
Joined: Tue Jul 08, 2014 6:18 pm

Post by danielmanser » Fri Apr 29, 2016 6:45 pm
We ran into an issue lately where Mac OS X 10.10.5 clients lost IPv6 connectivity after a Viscosity disconnect. Further testing revealed that a default route didn't get removed.

Steps to reproduce:

1. Client with Mac OS X 10.10.5 (10.9 and 10.11 seem to be fine), no Ethernet plugged in
2. Connect to a IPv4/IPv6 dual-stack Wifi network
-> User can access both worlds, expected result
3. Connect to a IPv4/IPv6 dual-stack VPN service
-> User can access company-internal services over the VPN's IPv4/IPv6 tunnel, expected result
4. Disconnect Viscosity connection
-> User can access both worlds (but no internal services), expected result
5. Connect Mac to Office Ethernet
-> User experiences timeouts when connecting to internal services. The machine by default first tries IPv6 but fails back to IPv4 after 30 seconds (depending on the service/protocol).

We investigated further and found that the Wifi default route still exists, even after the user disconnects completely from Wifi. The issue only resolves after the user reboots their machine.

Is this behaviour known and is there a solution to it?

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Mon May 02, 2016 10:53 pm
Hi danielmanser,

Is your OpenVPN server pushing out an IPv6 default route? If so, this isn't the recommended approach for IPv6 tunnels. Instead the recommend approach is to push the routes covering all global addresses. These routes are listed in the article below. OS X may still create an interface scoped default route, but this will not persist after disconnection.
http://www.sparklabs.com/support/kb/art ... work-leaks

I'm afraid this isn't a known behaviour. Ultimately Viscosity's IPv6 routing behaviour should be consistent amount the support OS X versions. Please leave it with me and I'll do some testing under 10.10.5 and see if it's something I can replicate and investigate further.

Finally, as a work-around, ticking the "Reset network interfaces on disconnect" option under Preferences->Advanced might save users having to reboot after disconnecting.

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

danielmanser

Posts: 12
Joined: Tue Jul 08, 2014 6:18 pm

Post by danielmanser » Tue May 03, 2016 4:59 pm
Hi James

Yes, the server is pushing the IPv6 route 2000::/3. I'll test the setting and report back if it solves the issue.

Daniel

danielmanser

Posts: 12
Joined: Tue Jul 08, 2014 6:18 pm

Post by danielmanser » Wed May 04, 2016 3:49 pm
Unfortunately, ticking the "Reset network interfaces on disconnect" option didn't work. I suspect it is a OS X issue.

danielmanser

Posts: 12
Joined: Tue Jul 08, 2014 6:18 pm

Post by danielmanser » Tue May 17, 2016 9:09 pm
Unfortunately, the problem persists even with 10.11.

Steps to reproduce:

1. Ethernet connected (en3), WiFi connected (en0) with no VPN connection

Routing table:
Code: Select all
Internet6:
Destination                             Gateway
Flags         Netif Expire
default                                 fe80::209:fff:fe09:b07%en3
UGc             en3
default                                 fe80::219:7ff:feeb:f80%en0
UGcI            en0
::1                                     ::1
UHL             lo0
2001:db8:0:2d::/64                      link#5
UC              en0
2001:db8::2d:1610:9fff:fee2:fe1b        14:10:9f:e2:fe:1b
UHL             lo0
2001:db8::2d:d9c7:6527:6afb:7e21        14:10:9f:e2:fe:1b
UHL             lo0
2001:db8:0:45::/64                      link#4
UC              en3
2001:db8::45:a8d0:2d23:21ef:d583        b4:75:e:e4:43:3c
UHL             lo0
2001:db8::45:b675:eff:fee4:433c         b4:75:e:e4:43:3c
UHL             lo0
Default route from en3 is activ (en0 inactive due to the "I" flag).

2. Disconnect Ethernet
Code: Select all
Internet6:
Destination                             Gateway
Flags         Netif Expire
default                                 fe80::219:7ff:feeb:f80%en0
UGc             en0
::1                                     ::1
UHL             lo0
2001:db8:0:2d::/64                      link#5
UC              en0
2001:db8::2d:1610:9fff:fee2:fe1b        14:10:9f:e2:fe:1b
UHL             lo0
2001:db8::2d:5060:7655:434b:a93a        14:10:9f:e2:fe:1b
UHL             lo0
Route for en3 disappears. Route for en0 is active. Everything is fine.

3. Open Viscosity VPN connection
Code: Select all
Internet6:
Destination                             Gateway
Flags         Netif Expire
default                                 fe80::219:7ff:feeb:f80%en0
UGSc            en0
::1                                     ::1
UHL             lo0
2000::/3                                utun0
USc           utun0
2001:db8:0:2d::/64                      link#5
UC              en0
2001:db8::2d:1610:9fff:fee2:fe1b        14:10:9f:e2:fe:1b
UHL             lo0
2001:db8::2d:5060:7655:434b:a93a        14:10:9f:e2:fe:1b
UHL             lo0
2001:db8:0:82::/64                      fe80::1610:9fff:fee2:fe1b%utun0
Uc            utun0
2001:db8:0:82::107                      link#12
UHL             lo0
Route on en3 is static ("S" flag).

4. Stop VPN
Code: Select all
Internet6:
Destination                             Gateway
Flags         Netif Expire
default                                 fe80::219:7ff:feeb:f80%en0
UGSc            en0
::1                                     ::1
UHL             lo0
2001:db8:0:2d::/64                      link#5
UC              en0
2001:db8::2d:1610:9fff:fee2:fe1b        14:10:9f:e2:fe:1b
UHL             lo0
2001:db8::2d:5060:7655:434b:a93a        14:10:9f:e2:fe:1b
UHL             lo0
The route on en3 remains (correct), but is still static (not correct). The "S" flag should disappear.

5. Reconnect Ethernet cable
Code: Select all
Internet6:
Destination                             Gateway
Flags         Netif Expire
default                                 fe80::219:7ff:feeb:f80%en0
UGSc            en0
default                                 fe80::219:7ff:feeb:f80%en0
UGcI            en0
::1                                     ::1
UHL             lo0
2001:db8:0:2d::/64                      link#5
UC              en0
2001:db8::2d:1610:9fff:fee2:fe1b        14:10:9f:e2:fe:1b
UHL             lo0
2001:db8::2d:5060:7655:434b:a93a        14:10:9f:e2:fe:1b
UHL             lo0
2001:db8:0:45::/64                      link#4
UC              en3
2001:db8::45:2487:7be2:fa8c:eb18        b4:75:e:e4:43:3c
UHL             lo0
2001:db8::45:b675:eff:fee4:433c         b4:75:e:e4:43:3c
UHL             lo0
A new dynamic route for en0 is set up. No route for en3 (Ethernet). Now IPv6 traffic is routed through the Wifi interface instead of en3. This is a problem because the Wifi is dual-stack, but not in a trusted scope, whereas the Ethernet connection is. Means: IPv6 traffic to internal resources will be routed through the (public) Wifi.

On the server side, I'm pushing the IPv6 route:
Code: Select all
# IPv6 stuff
tun-ipv6
push "tun-ipv6"
ifconfig-ipv6 2001:db8:0:82::1 2001:db8:0:82::2
ifconfig-ipv6-pool 2001:db8:0:82::100/64
push "route-ipv6 2000::/3"
We think the problem is that the Default route on en0 is static.

Explanation to subnets:

2001:db8::2d/64 = Wifi guest network
2001:db8::45/64 = Office (trusted) subnet
2001:db8::82/64 = Subnet inside the VPN tunnel

danielmanser

Posts: 12
Joined: Tue Jul 08, 2014 6:18 pm

Post by danielmanser » Wed May 18, 2016 1:14 am
We've done some more testing.

When Viscosity connects, it sets the Wifi route to static ("S" flag). When disconnecting the VPN and also shutting down the Wifi interface, the static route remains (which is bad).

My guess is that as long as there is a static route, OS X does not configure another default route (which should probably happen when connecting Ethernet). RA's are being sent from the router behind the Ethernet cable, and received by the client (checked with Wireshark).

danielmanser

Posts: 12
Joined: Tue Jul 08, 2014 6:18 pm

Post by danielmanser » Wed May 18, 2016 4:26 pm
Tested with openvpn 2.3.10 from Homebrew; this works as expected. Is Viscosity adding a static IPv6 route?

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Fri May 27, 2016 9:59 pm
Hi Daniel,

Thanks for your detailed troubleshooting information.

We've put together a beta build which should hopefully help. It has not been tested under all possible conditions as of yet, but please give it a try and let us know if you users still experience any problems. You can update to the latest beta version like so:

1. Open Viscosity's Preferences window and click on the General toolbar icon
2. Tick the "Include beta versions" checkbox
3. Click the Check Now button to see if a beta update is available

As for why it was occurring with Viscosity, but not with vanilla OpenVPN: Viscosity registers VPN interfaces with the OS. The OS then attempts to manage a number of services for the interface, including the routing table. You can prevent this registration from occurring if desired by turning off Viscosity's DNS support for the interface by setting the DNS Mode to Disabled.

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
8 posts Page 1 of 1