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

[Richard Laager]

https://wiki.strongswan.org/issues/817 is another example of this issue.

On Tue, 2015-03-24 at 10:34 +0100, Martin Willi wrote:
> 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?

That setting is checked. Interestingly, the client behaves the same even
with it *unchecked*. However, maybe it is still using the tunnel
for ::/0 because we have no other IPv6 default route. Outside of the
tunnel, the test client machine has IPv4 connectivity only.


After correcting syntax errors and throwing the plugin boilerplate
around it, the code I previously posted worked as designed. We are now
able to receive the router solicitation from the Windows client, and
respond with a router advertisement. The client can access the IPv6
Internet.

I've attached a diff against strongswan 5.1.2 which adds a plugin called
link_local_ts. To recap, this plugin adds a remote traffic selector of
fe80::XYZ/128 for each IPv6 /128 remote traffic selector, where XYZ is
the lower 64-bits of the original traffic selector. For example, if
there's an existing traffic selector of 2001:db8::123, this plugin will
add a traffic selector of fe80::123. The plugin is careful to avoid
adding redundant traffic selectors (i.e. direct duplicates or subsets of
existing traffic selectors).

The plugin boilerplate and narrowing hook setup code all comes from the
addrblock plugin, so I preserved the copyright notices from it. If you
don't feel that the boilerplate code is copyrightable, they can be
removed.

I'd like to see this plugin considered for inclusion with strongswan.
Are there any other steps I can take to help with that process?


After fixing that problem, we ran into a related issue. For whatever
reason, the Windows client only sends router solicitations on the
initial connect. If it gets no response, it does try repeatedly. But if
it gets a response, that's it. It does not send another router
solicitation when the router advertisement expires. So once the initial
router advertisement expires, the client's IPv6 stops working, never to
work again.

But, if the VPN server continues to send periodic router advertisements
unsolicited, the client stays working, even after the expiration of the
original router advertisement.

It seems to me that we have two options:
 1) Get IPv6 multicast to work, where the RAs would be duplicated for
    each connected client. You said there was a new plugin to do this
    for IPv4, but adapting it for IPv6 would be non-trivial.
 2) For now, I've added a leftupdown wrapper that edits /etc/radvd.conf,
    listing all connected VPN clients in a radvd "clients {} block".
    For example, "clients { fe80::1; fe80::2; }". While I've only tested
    with one client so far, this is sufficient to make this fully work.
    That is, radvd periodically sends router announcements to the
    client, and it stays working.

    For the benefit of others trying to do this, I've attached that
    script and also my radvd.conf. I have not tested to confirm whether
    AdvLinkMTU is necessary.

So, to recap, to provide IPv4 and IPv6, with default routes, to a
Windows 7 system using its built-in VPN client, you need:
A) https://wiki.strongswan.org/projects/strongswan/wiki/Win7UserMultipleConfig
B) leftsubnet=0.0.0.0/0,::/0
C) In addition to IPv4, provide an IPv6 block in rightsubnet=.
D) leftupdown=/path/to/the/attached/_updown
   Adapt `service radvd reload` as necessary for your distro.
E) OPTIONAL: If using usernames & passwords, rightauth=eap-mschapv2
F) OPTIONAL: Depending on your iptables setup, leftfirewall=yes
G) Build the link_local_ts plugin from the patch I attached.
H) Install radvd and use the radvd.conf I attached.
I) OPTIONAL: If your VPN server needs router announcements for its IPv6
   connectivity, you may need to add some firewall rules or something to
   keep the system from hearing the local radvd.

-- 
Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strongswan-5.1.2-link_local_ts_plugin.diff
Type: text/x-patch
Size: 12033 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150401/7746ee03/attachment-0002.bin>
-------------- next part --------------
interface eth0
{
   # This is necessary to send RAs at all.
   AdvSendAdvert on;

   # Only respond to VPN clients directly.  Do not multicast on the LAN.
   # Note that radvd < 1.9.9 has a bug where it will still multicast.
   UnicastOnly on;

   # Windows uses a 1300 byte MTU for IPv4, so we might as well make IPv6 match.
   AdvLinkMTU 1300;

   # A custom _updown wrapper manages the list of clients:
   #clients { };
};
-------------- next part --------------
A non-text attachment was scrubbed...
Name: _updown
Type: application/x-perl
Size: 1906 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150401/7746ee03/attachment-0003.bin>
-------------- 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/20150401/7746ee03/attachment-0001.pgp>