Skip to content
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
"Enable IPv6" seems to actually break IPv6
Got a problem with Viscosity or need help? Ask here!
tl;dr: when enabling IPv6 in Viscosity's preferences, the interface gets a /128 IP:
However, if I uncheck (disable) the 'Enable IPv6' option for the connection, it works! It's a it counter-intuitive
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:
Thanks a million,
Love the product by the way - we recommend it to everyone!
Cheers,
Barry
Code: Select all
This is unusable and any pushed routes do not take as the gateway (OpenVPN server) is not reachable.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
However, if I uncheck (disable) the 'Enable IPv6' option for the connection, it works! It's a it counter-intuitive
Code: Select all
Note the prefixlen = 128 on the top and prefixlen = 64 just above.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
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
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
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
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
Hi James,
sorry for the delayed reply here.
Ah okay, good to know and this is in fact our situation (address being supplied by OpenVPN).
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
Again though, the vtap0 interface has a /128: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)
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
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
5 posts
Page 1 of 1