Adding IPv6 to Remote Access VPNs
ryan at u13.net
ryan at u13.net
Mon Aug 15 15:54:36 CEST 2011
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. 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.
Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20110815/acf9c15d/attachment.htm>
More information about the ipv6-ops
mailing list