Adding IPv6 to Remote Access VPNs

[Ryan Rawdon]

On Aug 17, 2011, at 4:33 PM, Frank Bulk wrote:

> +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.

Does AnyConnect work with OS X and/or Linux?  If I dropped split tunneling as a requirement, then our PPTP RAS on Win2k8 only falls short on cross-platform support for v6.  I need to dig deeper on this and see if it is also broken for Linux clients and also whether L2TP may have more success.


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