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

[Martin Willi]

Hi Richard,

> If we add ff00::/8 to rightsubnet [...] 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:

Linux XFRM can't handle identical policies, as it wouldn't know over
which SA it should send a packet matching multiple tunnels. This applies
to Multicast selectors, too, as these are not handled in a special way.

With the upcoming 5.3.0 release, we will introduce the forecast [1]
plugin, which uses Netfilter marks to distinguish identical policies.
Based on that, the plugin listens for multicast packets, and distributes
them over all matching policies. Unfortunately, the plugin is currently
limited to IPv4, making it IPv6-aware is probably not that trivial.

> 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

Interesting.

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

Yes, but only if the client requests multiple such addresses. IKEv2
defines these attributes as multi-valued only if multiple values have
been requested (see [2]). While one could try to do it nonetheless, I
have my doubts that Windows accepts that.

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

So you are suggesting to assign a link-lokal virtual IP, allow the
client to do Router Solicitation to get an Advertisement, for which you
anticipated the address and included it in your negotiated TS? Or the
other way round?

If that works with the Windows client, why not. There is a narrow() hook
on the listener_t interface [3] that can be used to mangle traffic
selectors from a plugin in its NARROW_RESPONDER invocation. 

> Any other ideas on how to get this to work?

I'm wondering why this won't work by just assigning the IPv6 virtual IP
like it does with IPv4 addresses. Doesn't have the "Use default gateway
on remote network" in the "Advanced..." settings of the "Internet
Protocol Version 6" Networking Properties of your client connection have
any effect? Does adjusting the metric change anything?

Also, one might try to install the connection programmatically using
RasSetEntryProperties, as there are some additional options when doing
so. The RASEO2_IPv6RemoteDefaultGateway option from [4] really sounds
like what you want, but most likely is the same setting as described
above.

Not sure if anything changes when talking RFC 5739, unfortunately we
don't support that extension yet.

Another idea is to write a Windows client application that listens for
connection events using RasConnectionNotification(), then automatically
installs IPv6 routes for the connection.

Regards
Martin

[1]https://wiki.strongswan.org/projects/strongswan/wiki/forecast
[2]http://tools.ietf.org/html/rfc7296#section-3.15.1
[3]http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/bus/listeners/listener.h#l218
[4]https://msdn.microsoft.com/en-us/library/windows/desktop/aa377274(v=vs.85).aspx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150324/b8becf94/attachment-0001.pgp>