[strongSwan] IPv6 connections silently lost

[Andrej Podzimek]

Hello,

I have a tunnel with multiple IPv6 and IPv4 address ranges. (All of them are configured within the same connection.) After at most a couple of hours, the IPv6 ranges stop working. This means that IPv4 traffic is still routed through the tunnel and all the IPv4 ranges are all listed in ipsec statusall, but the IPv6 ranges no longer work and are no longer listed on the '===' line of ipsec statusall. The IPv6 ranges just disappear silently, no explanation is logged.

Surprisingly, ipsec down followed by ipsec up does *not* resolve the issue, because it breaks one of the other IPSec connections. This seems to be random, but at least one IPSec connection always gets clobbered (IPv6 ranges no longer usable) by resetting another IPSec connection. The only thing that helps is to reset all the connections and to flush the tables 220, roughly like this:

	for i in "${connections[@]}"; do ipsec down "${i}"& done; wait
	ip -6 route flush table 220; ip route flush table 220
	for i in "${connections[@]}"; do ipsec up "${i}"& done; wait

If I don't flush tables 220, then renewing any of the connections (three of them exist in total) always breaks one of the other connections. Re-establishing of *all* the connections seems to be the only way to deal with the issue. After the renewal, the connections work for a random period of time (roughly half an hour to a couple of hours) before another IPv6 failure occurs on at least one of them.

The IPSec tunnels are established over an IPv4-only network from behind NAT. Both the server and the client have the same key lifetime configuration.

Is this a known problem? How can this happen to IPv6 ranges only, despite the fact that they are listed in the same connection as the IPv4 ranges? I badly need a hint on how to diagnose this problem, because it makes IPSec virtually unusable, especially when it comes to remote filesystems mounted over IPv6. The underlying IPv4 connection between the server and the client works OK all the time; there are no outages that could cause the IPSec failures.

Cheers,
Andrej

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