[Swan] LIbreswan 3.25 and dual stack ipv4 and ipv6

[Tony Whyman]

I've been experimenting with Libreswan 3.25 and setting up tunnels 
between two dual stack (ipv4 and ipv6) systems. The objective is to 
migrate to ipv6 for all IPsec tunnels. It seems that both IPv4 and IPv6 
tunnels can be established - but with issues and some awkward 
configuration entries. The implementation looks buggy.

The scenario is:

Both Client and Server are ubuntu 16.04 with up-to-date kernels.

Server is configured with both A and AAAA records in the DNS for the 
same domain name. The former gives its IPv4 address and the second its 
IPv6 address. This setup works fine for Apache, Sendmail, etc.

"netstat -tl" implies that Pluto is listening on all interfaces (ipv4 
and ipv6)

Initial Server Side configuration is

conn defaults
     authby=rsasig
     type=tunnel
     dpddelay=30
     dpdtimeout=120
     left=%defaultroute
     leftcert="<mycert>"
     leftrsasigkey=%cert
     leftid=%fromcert
     mtu=1420

conn client
     right=%any
     rightsubnet=vhost:%no,%priv
     rightrsasigkey=%cert
     rightid="<client's cert>"
     also=defaults
     auto=add

Client Side Configuration is:

conn defaults
     authby=rsasig
     type=tunnel
     dpddelay=30
     dpdtimeout=120
     dpdaction=restart
     left=%defaultroute
     leftcert="<my cert>"
     leftrsasigkey=%cert
     leftid=%fromcert
     mtu=1420

conn server
     right=<server domain name>
     rightrsasigkey=%cert
     rightid="<server cert>"
     also=defaults
     auto=add

While the above worked fine with the original IPv4 only stack, with dual 
stack it fails with

022 "server": We cannot identify ourselves with either end of this 
connection.  <server ipv4 address> or 0.0.0.0 are not usable

However, changing the Client config slightly so that

     right=<server IPv4 address>

it works! Pluto seems to have got confused when both A and AAAA records 
exist for the same domain name.

Oddly, if I now try a slightly different combination:

     left=<client IPv6 address)
     right=<server domain name>

I get a different error:

003 ERROR: "server" #3: sendto on enp2s0 to <server ipv4 address>:500 
failed in EVENT_v1_RETRANSMIT. Errno 101: Network is unreachable

Why it now wants to use to server's ipv4 address in this test is a 
mystery given the above.

Now making a further change  to the Client config

   right=<server IPv6 address>

appears to get to a state where the client is initiating main mode but 
then retransmitting without a response. The Pluto log on the server side 
records:

packet from <client ipv6 address>:500: initial Main Mode message 
received on <server ipv6 address):500 but no connection has been 
authorized with policy RSASIG+IKEV1_ALLOW

However, changing  the server side to

   left=<server IPv6 address>
   right=<client IPv6 address>

and it works! An ipv6 in ipv6 tunnel is established.

Conclusion
----------------

There seem to be two problem areas:

1. The interpretation of "%defaultroute". On a dual stack system this 
always seems to be the IPv4 interface. This applies to both outgoing 
connections and when matching an incoming connection to a configuration.

I have tried using ::0 as a "default" for IPv6, but to no avail. It 
looks like it has to be an explicit IPv6 address to work.

2. The interpretation of DNS results when both A and AAAA records exists 
for the same DNS Name.

I would have expected that the AAAA record would always be the default 
choice and that the source interface (%defaultroute) would follow the 
address family. But that does not appear to be the case.

There also appears to be no mechanism to force IPv4 or IPv6 no that 
"connaddrfamily" has been obsoleted.

The result of all this is that it appears that with dual stack systems, 
explicit IP addresses have to be used if you are to have any chance at 
all of establishing IPsec tunnels, and the only time when 
"left=%defaultroute" is workable is when "right=<ipv4 address>".

Regards

Tony Whyman

MWA