OSX removing IPv6 addresses from openvpn
Recently, I tried to set up Viscosity.app to do VPN, and found one interesting bug : the interface is configured with IPv4 and IPv6 addresses, but a few seconds later OSX removes the IPv6 addresses!
Apparently, this is a long know bug, with the first references being in 2004 (10 years ago!!) on the archive.org copy of afp548.com in https://web.archive.org/web/20050316003941/http://www.afp548.com/article.php?story=20041015131913324 :
"There is another agent, however, that drives Unix admins into fits. The Kernel Event Monitor (KEM) waits for kernel events that tell it that an interface has gone down. When this happens it informs configd which interface has gone down. Configd then re-reads its config from the preference.plist file and sends out the new settings to the configuration agents which make sure the interfaces are configured they way they should be. This then triggers the IPMA which redoes the routing table according to the new information.
And that is what trips up the admins. They use their traditional methods of configuring an interface and use ifconfig to make it so. This works great. Until, for whatever reason, the KEM tells Configd things have changed. Configd then reverts everything back to whatever is held in the preference.plist file. This cheeses Unix admins off.”
Indeed, that’s a problem - especially since there’s nothing in preference.plist to fix.
There is no know workaround either (cf http://apple.stackexchange.com/questions/98467/preventing-osx-from-removing-ipv6-from-a-tap-interface suggestion to use “ipconfig set tapN AUTOMATIC-V6” that does not work)
While I was still investigating, I was suggested the following by Viscosity support :
I’d recommend turning off Viscosity’s “Accept IPv6 Router Advertisements” option if it is on (under Preferences->Advanced). If this option is on it’s probable Mac OS X is trying to configure IPv6 on the tap adapter itself and overriding any OpenVPN settings. Mac OS X/configd will not attempt to do automatic IPv6 configuration on a layer-3 (TUN) adapter.
Another thing to try is to turn off DNS support for the connection (under the Networking tab when editing the connection). Obviously in most cases this is less than ideal, but if it solves the issue it may help identify where the problem lies.
I’d also recommend adding a small “route-delay” to the connection, as occasionally OpenVPN may attempt to configure a TAP interface before it is ready. You can do this by adding the command “route-delay 10” (without quotes) under the Advanced tab for your connection.
Finally, as a work-around, you can try enabling IPv6 router advertisements on the router of your remote VPN network and allow the TAP interface to auto-configure itself rather than have OpenVPN manually attempt to do so.
Of course, nothing of that works, the 2nd was already turned off, and the 3rd only delays the routes.
The first doesn’t do anything, because the problem is due to the interface itself.
If when tap0 appears you try to do a ifconfig, you will see the correct IPv6 addresses, which are then removed by configd and its minions.
The statement “Mac OS X/configd will not attempt to do automatic IPv6 configuration on a layer-3 (TUN) adapter” is wrong.
I could ascertain that when I tried tun mode : apparently the interface type is set differently in the tun driver, which causes arp_client_init to fail and configd to stop trying to remove the ipv6 address. In syslog:
2014-07-11 3:30:05.240 PM configd: arp_client_init(tun0): unsupported network type
2014-07-11 3:30:05.240 PM configd: MANUAL tun0: arp_client_init failed
2014-07-11 3:30:05.244 PM configd: IPConfiguration: failed to start link-local service on tun0, invalid operation
Look at http://sourceforge.net/p/tuntaposx/code/ci/master/tree/tuntap/src/tap/tap.cc line 100 :
this->family_name = TAP_FAMILY_NAME;
this->family = IFNET_FAMILY_ETHERNET;
this->type = IFT_ETHER
Now look at http://sourceforge.net/p/tuntaposx/code/ci/master/tree/tuntap/src/tun/tun.cc line 55:
this->family_name = TUN_FAMILY_NAME;
this->family = IFNET_FAMILY_TUN;
this->type = IFT_OTHER;
It’s not that OSX won’t attempt to do automatic IPv6 configuration on a layer-3 (TUN) adapter - it will try, but fail, and therefore give up.
The real fix would be to pass the tap address to OSX configuration layer to prevent it from removing it, which is almost impossible, since in “networksetup” command line tool the tap0 interface is not considered as “hardware” - and therefore the information can’t be stored.
There might be a possibility with “scutil”, if the tap0 entry can be populated when tap0 is up and before configd decides to remove things, but it would require passing some commands with the right timing, which can only be done by inspecting viscosity source code, which I don’t have.
tunnelblick had the exact same problem (http://code.google.com/p/tunnelblick/issues/detail?id=116) and had to resort to tricks, so I also used a dirty trick : an applescript that runs when the interface is up that’s basically reading the correct ip and route from the syslog and restores them.
— add to /etc/sudoers:
— yourusername ALL=(ALL) NOPASSWD: /sbin/ifconfig
— yourusername ALL=(ALL) NOPASSWD: /sbin/route
set ifconfig to do shell script “grep `pgrep openvpn` /var/log/system.log | grep ifconfig |grep inet6 |sed -e ‘s/.*\/sbin/\/sbin/g’ -e ‘s/^/sudo /g’”
set route to do shell script “grep `pgrep openvpn` /var/log/system.log|grep route |grep \/56 |sed -e ‘s/.*(/route add -inet6 /g’ -e ‘s/->.*)//g’ -e ‘s/dev/-interface/g’ -e ‘s/^/sudo /g’”
do shell script ifconfig
do shell script route
Viscosity, please run some scutil command as soon as tap0 comes up.
Syndicated 2014-07-15 19:34:00 from Guylhem's most recent funny hacks & thoughts