[strongSwan] IPv6 (Link Local) Router Soliciations over VPN (for Windows 7)

[Richard Laager]

My colleague and I are trying to setup a road warrior VPN using IPsec
and IKEv2. The goal is for unmodified Windows 7 (and up) to connect
using the built-in VPN client.

Dual-stack inside the VPN is a hard requirement, which is where we're
running into problems. That is, IPv4 works fine, but IPv6 does not.

We are running Strongswan 5.1.2 on Ubuntu 14.04 "Trusty". Our base
ipsec.conf is as follows (IP addresses and hostname sanitized):

config setup
    plutostart=no

conn %default
    keyexchange=ikev2
    ike=aes256-sha1-modp1024!
    esp=aes256-sha1!
    dpdaction=clear
    dpddelay=300s
    rekey=no

conn office-vpn
    left=69.89.200.1,2607:f850:AAAA:BBBB::1
    leftsubnet=0.0.0.0/0,::/0
    leftauth=pubkey
    leftcert=HOSTNAME.pem
    leftid=@HOSTNAME
    leftfirewall=yes
    right=%any
    rightsourceip=10.0.0.0/24,2607:f850:CCCC:DDDD::/64
    #rightsubnet
    rightauth=eap-mschapv2
    eap_identity=%any
    auto=add

This is basically the example config from the wiki (which does not
mention IPv6):
https://wiki.strongswan.org/projects/strongswan/wiki/Win7EapMultipleConfig

This works, including with multiple clients, except that Windows does
not add a default route for IPv6. Windows does add a default route for
IPv4. If we manually add an IPv6 default route from the client's command
line, IPv6 works. To learn an IPv6 default route, Windows sends Router
Solicitations (from, e.g. fe80::1 to ff02::2) and expects a Router
Advertisement.

We setup radvd with "UnicastOnly on", and no prefixes. It's listening on
eth0, which is our VPN gateway's public interface. We previously tried
using ipsec0, as suggested here, but that by itself didn't seem to make
any difference: https://gist.github.com/jice/188f18ab361d03bb9058

If we add ff00::/8 to rightsubnet (e.g. rightsubnet=%dynamic,ff00::/8),
then we get `ip xfrm policy` traffic selectors for ff00::/8 too, and the
Router Solicitation and Router Advertisement packets pass correctly. The
client gets a default route, and everything works. However, when we try
to connect the VPN from a second client, it fails to connect because of
duplicate traffic selectors for ff00::/8:
charon: 07[CFG] unable to install policy ::/0 === ff00::/8 out (mark 0/0x00000000) for reqid 2, the same policy for reqid 1 exists
charon: 07[CFG] unable to install policy ff00::/8 === ::/0 in (mark 0/0x00000000) for reqid 2, the same policy for reqid 1 exists
charon: 07[CFG] unable to install policy ff00::/8 === ::/0 fwd (mark 0/0x00000000) for reqid 2, the same policy for reqid 1 exists
charon: 07[CFG] unable to install policy ::/0 === ff00::/8 out (mark 0/0x00000000) for reqid 2, the same policy for reqid 1 exists
charon: 07[CFG] unable to install policy ff00::/8 === ::/0 in (mark 0/0x00000000) for reqid 2, the same policy for reqid 1 exists
charon: 07[CFG] unable to install policy ff00::/8 === ::/0 fwd (mark 0/0x00000000) for reqid 2, the same policy for reqid 1 exists

rightsubnet=%dynamic,fe80::/64 behaves similarly.

The following combination assigns the client a link-local address.
Router Solicitation & Router Advertisement packets pass. Two clients can
connect successfully, but as neither client gets a public IPv6 address,
they obviously can't actually communicate with the world over IPv6:
    rightsourceip=10.11.0.0/24,fe80::/64
    #rightsubnet

We tried listing two IPv6 blocks in rightsourceip, but the logs
indicated only one IP was assigned to the client, and we only got one
set of IPv6 traffic selectors. Is there any way to assign two IPv6
addresses, one from fe80:: so the Router Solicitation & Router
Advertisements work, and one public IPv6 address?

We tried to use DHCPv6 to assign clients a public IPv6 address. The
client gets a public IPv6 address successfully, but since there's no
traffic selector for it on the gateway, the client can't actually
communicate with the world via IPv6.

When charon is adding traffic selectors for a rightsubnet IPv6 address
X, if it also added a traffic selector for fe80::LAST_64_BITS_OF_X, it
seems like link-local traffic over the tunnel would Just Work. Is this a
reasonable solution (which may require writing code)?

Any other ideas on how to get this to work?

Here's the same question, where the OP gave up and switched to Windows:
https://lists.strongswan.org/pipermail/users/2013-April/004573.html

-- 
Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150323/7b92e06c/attachment.pgp>