[strongSwan] IPv6 source addresses marked as deprecated (preferred_lft == 0)

[Andrej Podzimek]

Hello Martin,

Only now did I appreciate the original bug report #598 that caused the routing problem. However incredible it may seem, I'm facing an exact inversion of my previous issue in a different network configuration.

The original problem (summary):
On a road warrior routing to ::/0 via IPSec, the virtual IPv6 address was marked preferred_lft 0, so although the machine accepted IPv6 connections and even made them when forced to, getaddrinfo() always preferred IPv4 destination addresses over IPv6, based on the preference of non-deprecated IPv4 source addresses over the deprecated IPv6 address.

The new problem:
A machine has a 6to4 access to IPv6 (2002:xxxx:xxxx::/48 etc.) and wants to use IPSec only when talking to a specific IPv6 subnet (say 2a01:yyyy:yyyy:yyyy::/64), connecting without IPSec anywhere outside that subnet. (I think this is called "split tunnel mode" or the like.) The problem is that the virtual IPv6 address obtained to access the tunnel has preferred_lft set to forever, which is wrong for this particular case. Consequently, exactly as mentioned in bug #598, the virtual IPv6 address is preferred over the 6to4 address for outbound connections, perhaps because "native IPv6" addresses are preferred over 6to4. This limits the capability to initiate IPv6 connections solely to the small subnet behind the tunnel, though Pv6 connections can be accepted from anywhere (both via IPSec and via 6to4).

Presumably, marking the tunnel address as deprecated resolves this problem (for a short time):
	ip -6 addr change "${tunnel_virtual_address}" dev "${device}" preferred_lft 0

Admittedly, both the first problem (using IPSec as an IPv6 gateway) and the second problem (an IPSec tunnel with a 6to4 tunnel in split tunnel mode) occur in unusual scenarios. However, it would be great to have a possibility to specify the address selection preferences explicitly in these cases, as already suggested here: https://lists.strongswan.org/pipermail/users/2014-August/006431.html

The "new" problem occurs with strongswan 5.2.1 as well as with the latest git pull.

Cheers,
Andrej


> Hi Andrej,
>
>> Surprisingly, getaddrinfo() started to prefer IPv4 all the time,
>
>> All IPv6 addresses set by StrongSwan are now marked as expired, i.e.,
>> "deprecated".
>
> Looks like a regression that has been introduced with [1]. You may try
> to revert that patch to restore the pre-5.2.0 behavior.
>
> Probably we should find a better way how to exclude IPv6 addresses from
> non-tunnel use (#598 [2]).
>
> Regards
> Martin
>
> [1]http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=90854d28
> [2]https://wiki.strongswan.org/issues/598
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4266 bytes
Desc: Elektronicky podpis S/MIME
URL: <http://lists.strongswan.org/pipermail/users/attachments/20141116/bd461b4e/attachment.bin>