<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body>
<p>Hello list,<br /><br />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.<br /><br />- 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.<br />- Does Windows RRAS (2008) support IPv6 as the transport for PPTP or L2TP?<br />- 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.<br /><br />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.<br /><br />IPv6 over dial-in/remote access VPN is a new element for me and I appreciate any collective insight the list can provide.<br /><br />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. 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.<br /><br />Ryan</p>
<div> </div>
</body></html>