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



Attachment: smime.p7s
Description: Elektronicky podpis S/MIME

_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users

Reply via email to