"Enable IPv6" seems to actually break IPv6

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

barryo

Posts: 3
Joined: Thu Feb 18, 2016 1:55 am

Post by barryo » Sun Oct 07, 2018 12:33 am
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

barryo

Posts: 3
Joined: Thu Feb 18, 2016 1:55 am

Post by barryo » Mon Oct 08, 2018 6:22 pm
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.

James

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

Post by James » Wed Oct 10, 2018 11:32 pm
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
James Bekkema
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

barryo

Posts: 3
Joined: Thu Feb 18, 2016 1:55 am

Post by barryo » Sat Nov 03, 2018 2:42 am
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).

James

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

Post by James » Mon Nov 05, 2018 8:48 am
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
James Bekkema
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
5 posts Page 1 of 1