[strongSwan] strongSwan fails to configure IPv6 source routes

Andrej Podzimek andrej at podzimek.org
Fri Jan 20 16:31:04 CET 2017


I've recently noticed a serious issue with my IPSec tunnels established by strongSwan: IPv4 works, but IPv6 doesn't. It used to work normally a few versions ago and I'm not sure when exactly it got broken. There is currently no IPv6 routing through my tunnel.

The client is on an IPv4-only network behind NAT. The server has a dual-stack setup with a public IPv4 address and a 6to4 configuration with multiple subnets. The client runs Fedora 24 and strongSwan 5.4.0-2.fc24. The server runs ArchLinux and strongSwan 5.5.1-2. The goal is to give the client (road warrior) access to the server's IPv4 *and* IPv6 subnets through IPSec. The IPv4 access works fine (as confirmed by tracepath's single hop), but IPv6 stopped working completely, i.e., routes and addresses are misconfigured and no routing takes place.

Server configuration:

         conn warrior46

Server routes added by StrongSwan:

         # ip -6 route show table 220
         2002:xxxx:yyyy:5::1 dev eth0 proto static src 2002:xxxx:yyyy:1::1 metric 1024  pref medium
         # ip -4 route show table 220 via <IPv4 address of server's gateway> dev eth0 proto static src

Client configuration:

         conn server46
                 right=<IPv4 address of server>
                 rightsubnet=2002:xxxx:yyyy::/48,<IPv4 address of server>/32,,,,,

Client routes added by StrongSwan:

         # ip -6 route show table 220
         # There's *nothing* in this table. (!)

         # ip -6 route show
         2002:xxxx:yyyy:5::1 dev wlp7s0  proto kernel  metric 256  pref medium
         fe80::/64 dev wlp7s0  proto kernel  metric 256  pref medium

         # ip -4 route show table 220 via dev wlp7s0  proto static  src via dev wlp7s0  proto static  src via dev wlp7s0  proto static  src via dev wlp7s0  proto static  src via dev wlp7s0  proto static  src
         <IPv4 address of server> via dev wlp7s0  proto static  src

This^^^ client route configuration lacks an item like "2002:xxxx:yyyy::/48 dev wlp7s0 src 2002:xxxx:yyyy:5::1". More surprisingly, the client (road warrior) can't even ping itself -- pinging 2002:xxxx:yyyy:5::1 yields "Destination unreachable: Address unreachable". I don't understand how a locally configured address can be unreachable:

         # ip addr show dev wlp7s0
         2: wlp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
             link/ether 60:57:18:55:a4:56 brd ff:ff:ff:ff:ff:ff
             inet brd scope global dynamic wlp7s0
                valid_lft 83163sec preferred_lft 83163sec
             inet scope global wlp7s0
                valid_lft forever preferred_lft forever
             inet6 2002:xxxx:yyyy:5::1/128 scope global tentative deprecated dadfailed
                valid_lft forever preferred_lft 0sec
             inet6 fe80::6257:18ff:fe55:a456/64 scope link tentative dadfailed
                valid_lft forever preferred_lft forever

I suspect that something must have gone wrong with the duplicate address detection (dadfailed), but have no idea what, because strongSwan is the only possible source of 2002:xxxx:yyyy:5::/64 addresses on the network, so there's no way a duplicate address could emerge somewhere.

Also, I think that the IPv6 address should be configured as /48 or /64, not /128, but even that shouldn't prevent the road warrior from pinging (at least) itself. Plus the road warrior should be able to ping other machines from 2002:xxxx:yyyy::/48 behind the server or (at least) the server itself. But that's not the case. :-(

For IPv4, everything works. Connections from a road warrior to machines in all of 10.0.{1,2,3,4}.0/24 work fine. Connections from the server (and subnets it routes to/from) back to (various road warriors) also work fine. Only IPv6 is affected.

Any ideas what could be wrong here would be very helpful. I'll be more than happy to gather some extra debugging data if need be.


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

More information about the Users mailing list