Skip to content
OS X 10.10.5: IPv6 default route on Wifi doesn't disappear
Got a problem with Viscosity or need help? Ask here!
- Posts: 12
- Joined: Tue Jul 08, 2014 6:18 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?
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?
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
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
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
- Posts: 12
- Joined: Tue Jul 08, 2014 6:18 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
Yes, the server is pushing the IPv6 route 2000::/3. I'll test the setting and report back if it solves the issue.
Daniel
- Posts: 12
- Joined: Tue Jul 08, 2014 6:18 pm
Unfortunately, ticking the "Reset network interfaces on disconnect" option didn't work. I suspect it is a OS X issue.
- Posts: 12
- Joined: Tue Jul 08, 2014 6:18 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:
2. Disconnect Ethernet
3. Open Viscosity VPN connection
4. Stop VPN
5. Reconnect Ethernet cable
On the server side, I'm pushing the IPv6 route:
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
Steps to reproduce:
1. Ethernet connected (en3), WiFi connected (en0) with no VPN connection
Routing table:
Code: Select all
Default route from en3 is activ (en0 inactive due to the "I" flag).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
2. Disconnect Ethernet
Code: Select all
Route for en3 disappears. Route for en0 is active. Everything is fine.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
3. Open Viscosity VPN connection
Code: Select all
Route on en3 is static ("S" flag).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
4. Stop VPN
Code: Select all
The route on en3 remains (correct), but is still static (not correct). The "S" flag should disappear.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
5. Reconnect Ethernet cable
Code: Select all
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.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
On the server side, I'm pushing the IPv6 route:
Code: Select all
We think the problem is that the Default route on en0 is static.# 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"
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
- Posts: 12
- Joined: Tue Jul 08, 2014 6:18 pm
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).
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).
- Posts: 12
- Joined: Tue Jul 08, 2014 6:18 pm
Tested with openvpn 2.3.10 from Homebrew; this works as expected. Is Viscosity adding a static IPv6 route?
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
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
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
8 posts
Page 1 of 1