Disabling IPv6 on the netiface causes a fatal error

[thinner]

Since the ignoring of --tun-ipv6 and All tun devices on all platforms are always considered to be IPv6 capable. disabling IPv6 on the tun interface basically means disabling OpenVPN :) In and of itself it might not be very problematic, but it is a very easy way for companies to disable OpenVPN on their employees' computers.

It's very easy to recreate. On

Linux

just run sysctl -w net.ipv6.conf.all.disable_ipv6=1 and sysctl -w net.ipv6.conf.default.disable_ipv6=1

Windows

Go to Network Connections, right-click the adapter and select properties. Then uncheck Internet Protocol Version 6 (TCP/IPv6)

and then just start OpenVPN as you normally would.

The error in the log is

NETSH: C:\Windows\system32\netsh.exe interface ipv6 set address interface=NUM ADDRESS store=active
ERROR: netsh command failed: returned error code 1

[David Sommerseth]

Confirming the same issue on Linux (Scientific 7.3, RHEL 7.3 clone)

Just used the same two sysctl settings as suggested in the initial report.

Fri Mar  3 12:30:53 2017 us=492962 /usr/sbin/ip link set dev tun0 up mtu 1500
Fri Mar  3 12:30:53 2017 us=520790 /usr/sbin/ip addr add dev tun0 local 10.194.1.14 peer 10.194.1.13
Fri Mar  3 12:30:53 2017 us=525471 /usr/sbin/ip -6 addr add fd00:abcd:194:1::1002/64 dev tun0
RTNETLINK answers: Permission denied
Fri Mar  3 12:30:53 2017 us=527249 Linux ip -6 addr add failed: external program exited with error status: 2

The workaround is obvious though, set net.ipv6.conf.default.disable_ipv6=0. It is enough to modify the default.

[David Sommerseth]

Just run more tests on Fedora 24 with an older openvpn-2.3.12 install, the same issue is present here too. So this is not related to --tun-ipv6 at all.

Also noticed that only setting net.ipv6.conf.default.disable_ipv6=1 breaks the tunnel.

For OpenVPN 2.4 clients another more viable workaround is to use the new --pull-filter. I added these two options to my test configuration and it connects even if IPv6 is disabled on the client:

pull-filter ignore "ifconfig-ipv6 "
pull-filter ignore "route-ipv6 "

[Antonio Quartulli]

I think the problem is that the ip6 addr commands are performed by openvpn_execve_check() with S_FATAL, thus openvpn aborts in case of failure (this is true also in 2.3.x, as verified).

Imho a quick workaround would be to relax openvpn_execve_check() by removing S_FATAL and let the ipv6 commands gracefully fail without entirely aborting (and maybe printing a warning at the same time).

Best approach would be to detect if ipv6 is enabled in the system and print a warning if not, but an ipv6 should be configured.

I am afraid the last approach is going to be a platform nightmare..

[Gert Döring]

I do not consider this a bug in OpenVPN - disabling IPv6 in 2017 is a pilot error.

What I would accept as a bug is "OpenVPN totally fails if you disable IPv4 in your host system". This will eventually be a common case and we totally cannot handle it.

For folks that insist on disabling IPv6 *and* connect to a more modern VPN service that sends IPv6 config, dazo's suggestion to use --pull-filter is a good one - special requirements like these are what led to that feature.

@ordex: windows is not a good example on error handling - we have umpteen different methods for IPv4, and half of them consist of workarounds for workarounds ("check if the IPv4 address that we poked into the tap driver arrived on the windows side"). The IPv6 part is nice and clean - if the VPN config requests v6, it better should succeed. Ignoring errors will lead to silent failures ("why is v6 not working?") which will *not* lead to more user happiness.

There is one thing which might make me consider a patch for 2.3 - someone sending a v6 config unconditionally to all clients, and a Windows XP system without IPv6 failing to set up the tunnel. Since XP users are stuck on 2.3.x, the option of installing 2.4 and using pull-filter does not exist.

[David Sommerseth]

I agree that disabling IPv6 in general is a very bad idea in this time and age. But haven seen several different policy documents in regards to network configuration in larger companies and enterprises, there might be policies requiring configurations to disable IPv6. Most of these companies knows they need to change that, but such processes do take time.

That itself isn't a reason such a failure would appear. As these sites should then not configure VPNs providing IPv6 addresses either. However, sites might be migrating towards IPv6 support and some services do get IPv6 enabled. Thus they enable that on the VPN and enables IPv6 through policy management tools for those "test pilot users" but not the rest of the company. Which breaks clients for the rest of the company. In addition there might be several reasons why not to deploy a second OpenVPN server for the test pilot users as well (like VPN IP ranges are configured in many firewalls and similar access control checks).

I begin to lean towards having a new --workaround:disable-ipv6-configuration option (yes, long, explicit and ugly! This should be annoying), which basically is just a simplified ifconfig-ipv6 and route-ipv6 pull-filter. That shouldn't be too hard to handle for v2.3. For v2.4/master I am a bit more reluctant, as we already have --pull-filter, but having the same on both releases would simplify unified configurations across versions. Regardless, this option should also make some snarky, loud complaints to the log file: "WARNING: Your configuration file disables IPv6? This product was released in 2017. Are you truly sure?"

But I'm only leaning towards such an approach. I am not yet convinced it is a reasonable solution.

[Gert Döring]

I am closing this ticket now. It's 4 years later, 2.3 is falling out of support, and 2.4 and up have the relevant infrastructure to selectively ignore IPv6 if needed.

Also, I have not actually heard anyone else complain that "this is a huge problem"...