Skip to content
Defaults to IPv4, if not UDP6 chosen?
Got a problem with Viscosity or need help? Ask here!
It looks like contrary to Securepoint Viscosity defaults to using IPv4 when connecting to our VPN-server, unless I specifically choose UDP6.
Is it possible to configure Viscosity to prefer IPv6 when connecting to the VPN-server, without breaking the possibility of falling back to IPv4?
Is it possible to configure Viscosity to prefer IPv6 when connecting to the VPN-server, without breaking the possibility of falling back to IPv4?
Hi haraldh,
Thanks for the feedback. We'll take a look into adding an option that would allow IPv6 to be preferred for a future release.
In the mean time, this can be achieved by adding your address twice with different protocols. Simply set you Protocol drop down to UPD6, then add your address a second time with the protocol set to UDP4, for example you might have the following in your address field:
Eric
Thanks for the feedback. We'll take a look into adding an option that would allow IPv6 to be preferred for a future release.
In the mean time, this can be achieved by adding your address twice with different protocols. Simply set you Protocol drop down to UPD6, then add your address a second time with the protocol set to UDP4, for example you might have the following in your address field:
Code: Select all
Regards,vpn.server.com, vpn.server.com:1194:udp4
Eric
Eric Thorpe
Viscosity Developer
Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
Viscosity Developer
Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
Thanks, I also noted that Viscosity defaults to be installed with OpenVPN Version 2.3.
This leads to the connection failing when configured as UDP6 and after 5 minutes when a re-negotiation happens.
I tried with "redirect-gateway ipv6" on the server-side, but since the client (and many out there are) still on 2.3, this also fails due to an unknown directive.
This leads to the connection failing when configured as UDP6 and after 5 minutes when a re-negotiation happens.
I tried with "redirect-gateway ipv6" on the server-side, but since the client (and many out there are) still on 2.3, this also fails due to an unknown directive.
Tue Sep 01, 2020 9:17 amEric wrote: Thanks for the feedback. We'll take a look into adding an option that would allow IPv6 to be preferred for a future release.I think it would be safe to assume that if one has both an IPv4 and an IPv6 address, that the protocol stack would prefer IPv6. This is how almost all programs I know of behave. This is the first time I've seen it the other way around, and we have had dual stack for ages, practically from when the RFC's where still being written on IPv6.
Hi haraldh,
I certainly do understand what you are saying, however OpenVPN defaults to IPv4 first. We did prefer the happy eyeballs approach for a long time, however this generated a lot of complaints and we switched back to preferring IPv4 where available to keep in line with vanilla OpenVPN.
This may change with OpenVPN 2.5, though this is still some way off.
Regards,
Eric
I certainly do understand what you are saying, however OpenVPN defaults to IPv4 first. We did prefer the happy eyeballs approach for a long time, however this generated a lot of complaints and we switched back to preferring IPv4 where available to keep in line with vanilla OpenVPN.
This may change with OpenVPN 2.5, though this is still some way off.
Regards,
Eric
Eric Thorpe
Viscosity Developer
Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
Viscosity Developer
Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
5 posts
Page 1 of 1