charon prefers IPv6 for DNS hostnames even if left is set to IPv4
If left is set to an IPv4 address and right is an DNS hostname, resolving to IPv4 and IPv6,
charon will initiate the connection via IPv6
#1 Updated by Tobias Brunner over 4 years ago
- Tracker changed from Bug to Feature
- Status changed from New to Feedback
Thanks for the patch. Definitely makes sense to consider the local address family. However, there is a snag, it is possible to configure more than one address/hostname and even subnets and ranges (so the first address in the string might belong to such a range or subnet description). I've pushed a bunch of commits to the remote-host-family branch that take this (and e.g. ignoring %any) into account.
#3 Updated by Hauke Hagenhoff over 3 years ago
I would like to see this re-opened.
It's still not possible to force an IPv4 connection if the other side has AAAA records but no IPv6-support for IPSec.
There are literaly millions of those sides around ... AVM Fritz!Box routers with their built-in VPN using the MyFritz DynDNS service!
"If left is an IPv4" is not a decent switch for this, as the own side may have dynamic IPs too and has to be specified as %any or %defaultroute, where this patch does not work.
prefixed with "ipv4:" or "ipv6:" like one would expect it, e.g.
Force IPv4 even if an AAAA record exists (and even if system prefers IPv6)
Force IPv6 even if an A record exists (even if system prefers IPv4)
Besides the addition in brackets, this is the current behaviour
- neither ipv4/ipv6:
Try preferred family first, but also fall-back to other if connection fails
IMHO this would be the user friendliest and also most logical approach.
While preferring IPv6 if the system is set to is perfectly ok, there is no problem with a fall-back either.
Any decent app tries a fall-back when connecting via the preferred family fails.
See http://ipv6-test.com/ also testing the fall-back capability of the browser.
If a fall-back is not acceptable, enforcing can still be done by prepending ipv6: