[strongSwan] strongSwan fails to configure IPv6 source routes

[Andrej Podzimek]

Hi,

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
                 left=%defaultroute
                 leftsubnet=::/0,0.0.0.0/0
                 leftcert=server.crt
                 leftid=@server.domain.name
                 leftfirewall=no
                 rightfirewall=no
                 right=0.0.0.0/0
                 rightid=@*.domain.name
                 rightsourceip=2002:xxxx:yyyy:5::/64,10.0.5.0/24
                 auto=add
                 dpdaction=clear

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
         10.0.5.1 via <IPv4 address of server's gateway> dev eth0 proto static src 10.0.1.1

Client configuration:

         conn server46
                 left=%defaultroute
                 leftid=@client.domain.name
                 leftcert=client.crt
                 leftsourceip=%config6,%config4
                 leftfirewall=no
                 rightfirewall=no
                 right=<IPv4 address of server>
                 rightid=@server.domain.name
                 rightsubnet=2002:xxxx:yyyy::/48,<IPv4 address of server>/32,10.0.1.0/24,10.0.2.0/24,10.0.3.0/24,10.0.4.0/24,10.0.5.0/24
                 auto=start
                 dpdaction=restart
                 closeaction=restart

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
         10.0.1.0/24 via 192.168.0.1 dev wlp7s0  proto static  src 10.0.5.1
         10.0.2.0/24 via 192.168.0.1 dev wlp7s0  proto static  src 10.0.5.1
         10.0.3.0/24 via 192.168.0.1 dev wlp7s0  proto static  src 10.0.5.1
         10.0.4.0/24 via 192.168.0.1 dev wlp7s0  proto static  src 10.0.5.1
         10.0.5.0/24 via 192.168.0.1 dev wlp7s0  proto static  src 10.0.5.1
         <IPv4 address of server> via 192.168.0.1 dev wlp7s0  proto static  src 10.0.5.1

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 192.168.0.73/24 brd 192.168.0.255 scope global dynamic wlp7s0
                valid_lft 83163sec preferred_lft 83163sec
             inet 10.0.5.1/32 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 10.0.5.0/24 (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.

Cheers,
Andrej

-------------- 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>