Adding IPv6 to Remote Access VPNs

[Frank Bulk]

+1 for AnyConnect (on the ASA 5505).  We don't split-tunnel.

It lacks the ability to hand out IPv6 DNS servers (no RFC 6005 or stateless DHCPv6 or stateful DHCPv6 support at this time) over AnyConnect or from the LAN.

Frank

-----Original Message-----
From: ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de [mailto:ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de] On Behalf Of Dyonisius Visser
Sent: Monday, August 15, 2011 3:56 PM
To: ipv6-ops at lists.cluenet.de
Subject: Re: Adding IPv6 to Remote Access VPNs

Hi Ryan

> Hello list,
>
> I have been working on adding IPv6 connectivity to our remote access
> VPN solution (Windows Routng and Remote Access services, a solution I
> have inherited and am not terribly familiar with).  There are a few
> stumbling points that I would appreciate the list's input on.
>
> - For our IPv4 PPTP VPN, the RAS would provide the client an address
> from the local network segment (e.g. a /24 in the datacenter which is
> on a physical network segment).  For IPv6, the server does not appear
> to do NDP on behalf of the client, it seems that a separate routed
> prefix is to be used by the RAS for client addressing.  This leads me
> to wonder - is there any way to push specific routes to a VPN (PPTP
> now, am not opposed to using L2TP or other) clients?  If not, it would
> appear that the only way to have the client access the remote networks
> is to have it use the remote default gateway  - since the client would
> only have the connected route for the prefix used for RAS client
> addressing.
> - Does Windows RRAS (2008) support IPv6 as the transport for PPTP or L2TP?
> - Which protocols (PPTP, L2TP, other) does OS X support for
> transporting IPv6 and IPv6 transport?  While I do have a Windows 7
> test client here receiving an IPv6 address on the PPTP tunnel
> interface, Mac OS X does not.
>
> I am not opposed to advocating we move our remote access VPN to use
> our Netscreen firewalls if they would help resolve these issues and
> work with standard protocols (so as to not require a 3rd party client
> on Mac or Windows) and can authenticate against Active Directory/LDAP.
>
> IPv6 over dial-in/remote access VPN is a new element for me and I
> appreciate any collective insight the list can provide.
>
> It was unexpected but makes complete sense that our remote access VPN
> having IPv6 capabilities has actually become a blocking matter for our
> IPv6 deployment.
>
I had the same requirement. For my plans to move all internally used
services to IPv6 only (Postfix, OpenSSH, PostgreSQL, LDAP, name
resolving, etc, see
https://confluence.terena.org/display/~visser/Office+network+transition+to+IPv6+only),
a VPN solution that does not do IPv6 is a definite blocker.
I took a look at a Win2K8 RRAS solution back then. Tunneling IPv6 should
be possible with PPTP and SSTP. The latter should also be able to use
IPv6 as transport. However we also have some Macs, and at the time IPv6
over PPTP was not working for Macs, and there was no SSTP client.

We're now happily running Cisco AnyConnect on a little ASA5505, which
provides IPv4+IPv6 addresses for our (IPv4) users. AFAIK it is not
possible (yet!) to use IPv6 as transport, but that is only a problem in
IPv6-only access networks, which at the moment are very rare. In any
way, my users have not yet found one to connect home from.

The AnyConnect stuff works much better than our previous PPTP set-up.
Back then users complained a lot about not being able to connect, I
suspect GRE-unaware 90's NAT boxes or picky access policies were the
cause. Since my users appear in ever different places, often in the less
developed parts of the globe, this was hard to diagnose, let alone fix.
To me the fact that it now 'just works' outweighs the hassle of having
to install and maintain a 3rd party app on client computers.

>   If a user has IPv6 connectivity at home and dials into an IPv4-only
> VPN, s/he will resolve internal hostnames with AAAAs then attempt to
> connect via public connectivity instead of the VPN.  This results in
> timeouts and other unpreferable behavior until the user's VPN can
> provide trusted IPv6 connectivity to the remote environment.
>

I too had problems with split tunnelling, for some reason it worked for
IPv4, but not for IPv6: all IPv6 traffic would get tunnelled. This was
confusing for people, so in the end I configured things so that all
traffic always gets tunnelled. While this does not the yield the best
performance, it is simple to understand, and it does protect against
snooping when users connects to things like open wifi networks (as they do).

Cheers,

-- 
Dyonisius Visser
System & Networking Engineer
TERENA Secretariat
Singel 468 D, 1017 AW Amsterdam
The Netherlands
T +31 20 530 44 88 F +31 20 530 44 99
visser at terena.org | www.terena.org