SparkLabs Forum.

Community Help.


"Enable IPv6" seems to actually break IPv6

tl;dr: when enabling IPv6 in Viscosity's preferences, the interface gets a /128 IP:

Code: Select all

vtap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
   ether d2:dc:69:c2:ab:95
   inet 192.0.2.10 netmask 0xffffff00 broadcast 192.0.2.255
   inet6 fe80::18e2:6ee4:b380:8db0%vtap0 prefixlen 64 secured scopeid 0x10
   inet6 2001:db8:18:7::4 prefixlen 128


This is unusable and any pushed routes do not take as the gateway (OpenVPN server) is not reachable.

However, if I uncheck (disable) the 'Enable IPv6' option for the connection, it works! It's a it counter-intuitive ;-)

Code: Select all

vtap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
   ether a2:5a:d2:f7:75:98
   inet 192.0.2.10 netmask 0xffffff00 broadcast 192.0.2.255
   inet6 fe80::a05a:d2ff:fef7:7598%vtap0 prefixlen 64 scopeid 0x10
   inet6 2001:db8:18:7::4  prefixlen 64


Note the prefixlen = 128 on the top and prefixlen = 64 just above.

While just leaving IPv6 enabled unchecked does allow for IPv6 routing, I think the problem compounds as the local DNS resolver will not query for a AAAA record as v6 is not marked as enabled (this is an assumption on my part as to why aaaa records are not sought).

This is Viscosity 1.7.11 (1463) connecting to OpenVPN 2.4.4 with a sample config as follows:


Code: Select all

proto udp6
mode server
dev tap
topology subnet
server 192.0.2.1 255.255.255.0
ifconfig-ipv6 2001:db8:7::1/64 2001:db8:7::2
ifconfig-ipv6-pool 2001:db8:7::3/64
push "dhcp-option DNS 192.0.2.162"
push "dhcp-option DNS6 2001:db8:2::4"
push "dhcp-option DOMAIN example.com"
push "dhcp-option DOMAIN example.com"
push "redirect-gateway def1 ipv6"



Thanks a million,

Love the product by the way - we recommend it to everyone!

Cheers,
Barry
By the way - I'm happy to work with the developers for testing to get this working properly. You'll get me via barry [at] islandbridgenetworks [dot] ie.
Hi barryo,

The "Enable IPv6" option enables IPv6 automatic configuration for TAP connections (via DHCPv6 or stateless auto configuration). It's not needed for connections where the IP address is being manually assigned by OpenVPN. Viscosity should detect this and automatically turn the option off if it's not required: you should see a message like "Disabling Automatic IPv6 on interface vtap0 (not required)" in the connection log if this is occurring.

It seems likely something is going awry with the disabling of IPv6 automatic configuration. If I had to guess I'd say the VPN interface is obtaining an IPv6 address via automatic IPv6 configuration, and so when OpenVPN comes along with its manual IP address in the same range it's just getting added as a secondary IP address (hence the /128). When IPv6 automatic configuration gets turned off, only the /128 IP remains.

Obviously it would be ideal if Viscosity were able to handle this too, so I've created a ticket for us internally to look into further. In the meantime you could try making sure no DHCPv6 or SLAAC services are running on the VPN network and see if that helps. Alternatively there is no harm in leaving the Enable IPv6 option off if you're pushing the IPv6 address via OpenVPN.

Cheers,
James
Hi James,

sorry for the delayed reply here.

The "Enable IPv6" option enables IPv6 automatic configuration for TAP connections (via DHCPv6 or stateless auto configuration). It's not needed for connections where the IP address is being manually assigned by OpenVPN.


Ah okay, good to know and this is in fact our situation (address being supplied by OpenVPN).

Viscosity should detect this and automatically turn the option off if it's not required: you should see a message like "Disabling Automatic IPv6 on interface vtap0 (not required)" in the connection log if this is occurring.


Confirmed - in fact this is what I see re IPv6:

Code: Select all

2018-11-02 15:26:43: IPv6 enabled on tap interface vtap0
2018-11-02 15:26:44: /sbin/ifconfig vtap0 inet6 2a05:5300:1::3/64
2018-11-02 15:26:44: add_route_ipv6(2a05:5300:1::/64 -> 2a05:5300:1::3 metric 0) dev vtap0
2018-11-02 15:26:44: add_route_ipv6(::/3 -> 2a05:5300:1::1 metric -1) dev vtap0
2018-11-02 15:26:44: add_route_ipv6(2000::/4 -> 2a05:5300:1::1 metric -1) dev vtap0
2018-11-02 15:26:44: add_route_ipv6(3000::/4 -> 2a05:5300:1::1 metric -1) dev vtap0
2018-11-02 15:26:44: add_route_ipv6(fc00::/7 -> 2a05:5300:1::1 metric -1) dev vtap0
2018-11-02 15:26:44: Initialization Sequence Completed
2018-11-02 15:26:44: Disabling Automatic IPv6 on interface vtap0 (not required)


Again though, the vtap0 interface has a /128:

Code: Select all

inet6 2a05:5300:1::3 prefixlen 128


It seems likely something is going awry with the disabling of IPv6 automatic configuration. If I had to guess I'd say the VPN interface is obtaining an IPv6 address via automatic IPv6 configuration, and so when OpenVPN comes along with its manual IP address in the same range it's just getting added as a secondary IP address (hence the /128). When IPv6 automatic configuration gets turned off, only the /128 IP remains.


So definitely not this - we're not running radvd or anything else server side and I've tcpdump the server side interface and there's no RA/DHCP6/etc going to the client.

Alternatively there is no harm in leaving the Enable IPv6 option off if you're pushing the IPv6 address via OpenVPN.


So we do do this right now but the DNS issue remains - as the local DNS resolver will not query for a AAAA record as v6 is not marked as enabled (this is an assumption on my part as to why aaaa records are not sought).
So we do do this right now but the DNS issue remains - as the local DNS resolver will not query for a AAAA record as v6 is not marked as enabled (this is an assumption on my part as to why aaaa records are not sought).


That shouldn't be the case: all network interfaces in recent versions of macOS are marked as IPv6 enabled by default.

You could potentially try temporarily setting up DHCPv6 on the VPN network as a test, to see whether it makes any difference to macOS's resolver behaviour.

Cheers,
James
5 posts Page 1 of 1

Copyright © 2016 SparkLabs Pty Ltd. All Rights Reserved. Privacy Policy