Hello, I'm using IPSec to access IPv6 from IPv4 networks behind NAT. My road warrior establishes three IPSec associations, two of which provide access to remote IPv6 and IPv4 networks and the third one, besides enabling access to remote NATed IPv4 networks, also provides access to ::/0, i.e., serves as an IPv6 access tunnel.
All of this used to work fine: Correct source addresses were chosen for my outbound connections and IPv6 was *always* preferred by getaddrinfo(). (I want IPv6 to be preferred on my machines at any time and at any cost. I even configured /etc/gai.conf to prefer 6to4 over IPv4, which is by default set the other way round.) Additionally, the two associations (that provide access to restricted IPv6 ranges) were preferred over the "generic" one (that provides access to ::/0) whenever applicable. So everything worked *exactly* as expected. Then I updated to 5.2.0... Surprisingly, getaddrinfo() started to prefer IPv4 all the time, affecting virtually all applications that deal with the network. When looking at the results returned by getaddrinfo(), IPv4 addresses were indeed listed before IPv6 addresses. This applied to *all* IP addresses returned by getaddrinfo(), no matter if they fell into the ranges defined by the two "restricted" associations or were supposed to be routed via IPv6 over the "generic" association. (Recall that *all* the three associations have both IPv4 (NAT/private) and IPv6 (global) addresses assigned to them.) Initially I couldn't figure out why IPv4 became preferred, so I thought it was a new getaddrinfo() bug and filed this desperate bug report: https://bugs.archlinux.org/task/41345 Well, I was wrong. Only later did I realize what 'ip addr show' was telling me: All IPv6 addresses set by StrongSwan are now marked as expired, i.e., "deprecated". This implies that although the machine accepts connections on those addresses, getaddrinfo() will *not* prefer remote addresses accesible only via those "deprecated" local source addresses. (However, sockets can still be bound to deprecated source addresses, obviously, because things like 'ssh -6' work just fine.) So that's the reason why getaddrinfo() didn't prefer such IPv6 addresses over IPv4 any longer -- they were deprecated, most likely from version 5.2.0 on. As a desperate hack, I mostly do this: device=eth0 # or wlan0, whatever is in use at the moment for i in $(ip -6 addr show dev "${device}" | grep 'inet6.*deprecated' | awk '{print $2}'); do ip -6 addr change "${i}" dev "${device}" preferred_lft forever done This restores law and order and 'ip addr show' will now say "forever" instead of "deprecated". getaddrinfo() will prefer IPv6 and everything works fine again for a while. Unfortunately, the IPv6 addresses are reset to "deprecated" on the next reassociation or on some other regular event. :-( So this change has to be performed repeatedly, or else you end up with IPv4 being preferred again pretty soon. How can this be resolved "once and for all"? Is there a way to modify some "updown" script such that it doesn't set the IPv6 addresses as expired? (I couldn't find this in /usr/lib/strongswan/_updown.) Admittedly, "forever" is not the right value here -- the addresses should be valid for the duration of the IPSec association (and the countdown should be reset each time they get renewed). Additionally, it is surprising that no such deprecated status or expiry time is set for IPv4 addresses. I'd say that this particular configuration should be the same for both IPv4 and IPv6, which is not the case at the moment. To sum up, a piece of advice on how to make StrongSwan set a reasonable preferred_lft would be very helpful. :-) Cheers, Andrej
smime.p7s
Description: Elektronicky podpis S/MIME
_______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
