PPTP Tunnel , encryption (im)possible ?

[Ninho]

Trying the new PPTP tunnel  (on Windows 2k) through the Frankfurt PoP. Tunneling appears to work OK.

Only, tunnel is unencrypted - Isn't encryption one of the desirable features of PPTP ? Could be useful e.g. if we wanted to hide some traffic from our ISP's prying eyes.

As seen here, when updating the connectoïd properties to require encryption, connection to the tunnel server failed. Is it just me (I might be missing an OS update...), or does the server not allow encrypted tunnels for some reason ?

Congratulations anyway, your constant advances to the service are watched and appreciated :=)


--
Ninho

[hisken]

[...]

I think this PPTP is a great new feature!  :)

PPTP encryption, isn't that proprietary stuff from Microsoft (MPPE)? That maybe a good reason HE doesn't want to support proprietary techniques (but, as far as I know, there is Linux kernel support). Anyway, I don't really miss it.

More importantly: This new PPTP feature brings NAT workaround support! One could now set up a PPTP tunnel, use the P-t-P endpoint as the tunnel endpoint and work around stupid routers that don't support proto-41 forwarding. Didn't test it yet, though.

Edit: http://mppe-mppc.alphacron.de/ (Linux kernel patch)

Although the module's source code is completely free, MPPC itself is patented algorithm. Patent for *Microsoft* PPC is holded by the  Hifn Inc. This is obvious ;-). Furthermore, MPPE uses RC4[1] encryption algorithm which itself isn't patented, but RC4 is trademark of RSA Data Security Inc.  To avoid legal problems, US citizens shouldn't use this module.

[Ninho]

PPTP encryption, isn't that proprietary stuff from Microsoft (MPPE)?
That maybe a good reason HE doesn't want to support proprietary techniques (but, as far as I know, there is Linux kernel support). Anyway, I don't really miss it.

More or less (formally, it's a joint specification by MS and others...)
Importantly, besides Windows, Linux clients can do PPTP encryption. ( Other OSes ? )

Even more importantly, there is at least one free/open PPTP server in addition to the MS ones that do PPTP encryption -> http://www.poptop.org/

Maybe HE can tell us what software their servers are running and presumably they could implement MPPE - unless there are ressource/cost considerations invovled...

This new PPTP feature brings NAT workaround support! One could now set up a PPTP tunnel, use the P-t-P endpoint as the tunnel endpoint and work around stupid routers that don't support proto-41 forwarding.

Indeed, may come handy for some of us

[hisken]

By the way: proto-41 isn't encrypted too (but you might already know that). In fact, if you take out the first 20 bytes (IPv4 header) from a proto-41 packet you'll get the exact IPv6 packet.

But I see your point in hiding your traffic from the ISP. If you really care about that, you'd probably go with an OpenVPN tunnel - that's what I call secure. You could set up a IPv6 tunnel somewhere on a server you trust, and then route one of your /64s through the OpenVPN tunnel to the secured endpoint. MPPE isn't really that secure anyway  :)

Even more importantly, there is at least one free/open PPTP server in addition to the MS ones that do PPTP encryption -> http://www.poptop.org/

Indeed, but you need Linux kernel >= 2.6.15 for MPPE to work without kernel patches/modules.

It may be possible that HE is using an older kernel, or even BSD or some kind of router OS.

[jimb]

I run poptop on one of my gentoo boxes as a remote access VPN server and can also confirm it does "max encryption" MPPE just fine.

It's nice to have since it allows me to make a VPN connection to home from any windows box without having to install any additional software such as a VPN client.  Just set up the PPTP connectoid and off to the races.

The biggest problem with PPTP I have is that it's not the most NAT friendly VPN protocol in my experience.  PPTP needs TCP 1723 and GRE to pass through a firewall/NAT and be NATed correctly.  With many NAT boxes in my experience, they only support a single outbound PPTP connection because it doesn't know how to route the return GRE traffic since there are no "ports" and such to distinguish return traffic from multiple outbound sessions.  So one experiences similar issues with regard to NAT that one has with 6in4, since they're both implemented as IPv4 transport protocols.  I've had occasion where another user was already using PPTP and I was not able to "get out" from behind a NAT because of it.

Some NATs seem to have helper code to do this, however, but not all.  Netfilter/iptables has a helper module, although I've never tested it.  The comments section from the top of the helper module explains things in detail:

/*
* ip_conntrack_proto_gre.c - Version 3.0
*
* Connection tracking protocol helper module for GRE.
*
* GRE is a generic encapsulation protocol, which is generally not very
* suited for NAT, as it has no protocol-specific part as port numbers.
*
* It has an optional key field, which may help us distinguishing two
* connections between the same two hosts.
*
* GRE is defined in RFC 1701 and RFC 1702, as well as RFC 2784
*
* PPTP is built on top of a modified version of GRE, and has a mandatory
* field called "CallID", which serves us for the same purpose as the key
* field in plain GRE.
*
* Documentation about PPTP can be found in RFC 2637
*
* (C) 2000-2005 by Harald Welte <laforge@gnumonks.org>
*
* Development of this code funded by Astaro AG (http://www.astaro.com/)
*
*/

So, it appears that some firewall/NAT implementations such as netfilter use the "CallID" field (which is specific to the PPTP hacked version of GRE) to distinguish the traffic.  But I wonder how many typical consumer grade NATs implement this?  For more enterprise grade stuff you might find at public wifi hotspots, airports, campuses and businesses, I know Cisco PIXs and ASAs implement a "fixup" for PPTP which I presume works the same way.  I'm pretty sure Juniper does too.  Not sure about other vendors.

Anyway, stuff like IPSEC with UDP encapsulation is way better for traversing NAT than PPTP.  It'd be pretty cool if HE could implement something like this, or even better, something like AYIYA, since that's basically IPv6 in "whatever" (for instance, UDP or TCP).

[kcochran]

It's nice to have since it allows me to make a VPN connection to home from any windows box without having to install any additional software such as a VPN client.  Just set up the PPTP connectoid and off to the races.

Exactly why we picked it.

The biggest problem with PPTP I have is that it's not the most NAT friendly VPN protocol in my experience.  PPTP needs TCP 1723 and GRE to pass through a firewall/NAT and be NATed correctly.  With many NAT boxes in my experience, they only support a single outbound PPTP connection because it doesn't know how to route the return GRE traffic since there are no "ports" and such to distinguish return traffic from multiple outbound sessions.  So one experiences similar issues with regard to NAT that one has with 6in4, since they're both implemented as IPv4 transport protocols.  I've had occasion where another user was already using PPTP and I was not able to "get out" from behind a NAT because of it.

This isn't really designed for someone to anchor multiple v6 tunnels behind their CPE devices.  It's designed for a home user to a) gain a static endpoint and b) have a pretty straightforward means of configuring their tunnel, especially when they have a normally dynamic IP address.

Anyway, stuff like IPSEC with UDP encapsulation is way better for traversing NAT than PPTP.  It'd be pretty cool if HE could implement something like this, or even better, something like AYIYA, since that's basically IPv6 in "whatever" (for instance, UDP or TCP).

IPsec isn't exactly enduser-friendly to configure and doesn't simplify the dynamic IP issue, and UDP still trips over the state timeout issue people trip over regularly in their NATs.  AYIYA requires additional client software to be installed.  PPTP should be better supported on CPE units which don't pass proto-41, and it's an easy thing to complain to the manufacturer for not supporting.  It also will avoid the timeout issue in most cases, and it doesn't normally require any additional software to be installed.

[jimb]

Anyway, stuff like IPSEC with UDP encapsulation is way better for traversing NAT than PPTP.  It'd be pretty cool if HE could implement something like this, or even better, something like AYIYA, since that's basically IPv6 in "whatever" (for instance, UDP or TCP).

IPsec isn't exactly enduser-friendly to configure and doesn't simplify the dynamic IP issue, and UDP still trips over the state timeout issue people trip over regularly in their NATs.  AYIYA requires additional client software to be installed.  PPTP should be better supported on CPE units which don't pass proto-41, and it's an easy thing to complain to the manufacturer for not supporting.  It also will avoid the timeout issue in most cases, and it doesn't normally require any additional software to be installed.

I've found the typical VPN client to be fairly user-proof, especially if bundled or capable of downloading a configuration file.  Pretty much just type in a username and password and it connects you up.  I've worked in plenty of shops which had scores of non-technical users using VPN clients from home and the road with few real issues.  I'd expect AYIYA to be similarly easy to use, although I can't say I've played with an AYIYA client yet.

But of course, as you say, both require the installation of additional software, which can generate plenty of problems itself.  Then there's the issues of licensing, being able to distribute the software, etc, etc.  It's definitely far easier to use something everyone already has built into Windows, and which is available for other OSes as well.

Having this PPTP tunnel available along with the ability to connect the IPv6 hose up to the end of it is definitely a win for your intended user base (single user dynamic IP folks at home).  It's a great addition that will be appreciated by many.

I was just thinking of users in other scenarios, such as users at work, behind a campus NAT at school, or road warriors in airports or whatever who might want some IPv6 connectivity.  In these scenarios, I've found through attempting to connect to my home PPTP server that it's a bit of a "roll of the dice" whether it'll work or not, where IPSEC VPN clients tend to be better supported since they use UDP.

Anyway, I wasn't knocking the PPTP solution, I think it's great, just adding a suggestion to perhaps add a similar additional capability which has an easier time traversing NATs.  Although I can't think of anything that avoids the aforementioned problems.  :)

[rm]

It's nice to have since it allows me to make a VPN connection to home from any windows box without having to install any additional software such as a VPN client.  Just set up the PPTP connectoid and off to the races.

Exactly why we picked it.

But why not support L2TP instead? Windows supports L2TP out of the box too, and that protocol (using UDP only) is much more NAT-friendly and from what I heard, puts less load on the servers. I see many Ethernet-based ISPs migrating from PPTP to L2TP for their Internet access VPN service, with users saying only positive things about the change.

[jimb]

It's nice to have since it allows me to make a VPN connection to home from any windows box without having to install any additional software such as a VPN client.  Just set up the PPTP connectoid and off to the races.

Exactly why we picked it.

But why not support L2TP instead? Windows supports L2TP out of the box too, and that protocol (using UDP only) is much more NAT-friendly and from what I heard, puts less load on the servers. I see many Ethernet-based ISPs migrating from PPTP to L2TP for their Internet access VPN service, with users saying only positive things about the change.

Interesting.  I had forgotten that L2TP was also built into Windows too.  Perhaps not for OSX?

[kcochran]

But why not support L2TP instead? Windows supports L2TP out of the box too, and that protocol (using UDP only) is much more NAT-friendly and from what I heard, puts less load on the servers. I see many Ethernet-based ISPs migrating from PPTP to L2TP for their Internet access VPN service, with users saying only positive things about the change.

The extra overhead of IPsec for the tunnel load on some of our more populated servers could hurt, plus the need for an X.509 PKI setup if we wanted to avoid pre-shared keys and manual updating of IP addresses, unless we used a global PSK, which just seems like a bad idea.  L2TP without IPsec would be an option, but that particular configuration seems a more complicated configuration on most OSs, if supported at all.

As to no encryption to the tserv over the VPN transport, if your traffic wasn't encrypted to start with, it wouldn't be encrypted when it left the VPN anyway.

[Ninho]

(...) As to no encryption to the tserv over the VPN transport, if your traffic wasn't encrypted to start with, it wouldn't be encrypted when it left the VPN anyway.

Of course, but there are situations when an ISP may be suspected to be nosy and users may trust Hurricane Electric as a "data transporter" rmore than their own ISP. I sure do. ISP collects at least aggregated and possibly personal navigation data, and it befits me to frustrate them as far as possible albeit that they don't care much about myself...

Don't mistake me, I'm not requesting tunnel encryption, but if it can be proposed optionally and does not overload the servers (and clients!) it's a good thing in my book. I believe the PPTP encryption is relatively light (and not too secure...). IMHO, we ought to to fight the notion that "only bad people" have cause to hide their communications and data, before the authorities be tempted to enforce a ban on encryption (again).

[rm]

But why not support L2TP instead? Windows supports L2TP out of the box too, and that protocol (using UDP only) is much more NAT-friendly and from what I heard, puts less load on the servers. I see many Ethernet-based ISPs migrating from PPTP to L2TP for their Internet access VPN service, with users saying only positive things about the change.

The extra overhead of IPsec for the tunnel load on some of our more populated servers could hurt, plus the need for an X.509 PKI setup if we wanted to avoid pre-shared keys and manual updating of IP addresses, unless we used a global PSK, which just seems like a bad idea.  L2TP without IPsec would be an option, but that particular configuration seems a more complicated configuration on most OSs, if supported at all.

As to no encryption to the tserv over the VPN transport, if your traffic wasn't encrypted to start with, it wouldn't be encrypted when it left the VPN anyway.

I meant unencrypted L2TP, of course.
GNU/Linux, Windows Vista and 7 connect to L2TP without IPsec absolutely fine.
Windows XP works fine too, but first it needs this .reg-file applied, and a reboot:

Code Select Expand

REGEDIT4

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters]
"ProhibitIpSec"=dword:00000001
A large ISP here uses unencrypted L2TP without any issues. If you want some proof, here's their user guide (use google translate or something), and on another page they even say "Use L2TP if at all possible, PPTP is strongly not recommended and should be used as a last resort only".
At work, I had my share of "fun" troubleshooting incoming PPTP connections from our clients as well.

[jucs]

As to no encryption to the tserv over the VPN transport, if your traffic wasn't encrypted to start with, it wouldn't be encrypted when it left the VPN anyway.

You're of course right about that. But sometimes you actually only need to secure the data the way out of your current network, because it is especially unsecure. As this is the case for me, I'd be very happy to see any kind of encryption supported by HE ;-)

[jimb]

As to no encryption to the tserv over the VPN transport, if your traffic wasn't encrypted to start with, it wouldn't be encrypted when it left the VPN anyway.

You're of course right about that. But sometimes you actually only need to secure the data the way out of your current network, because it is especially unsecure. As this is the case for me, I'd be very happy to see any kind of encryption supported by HE ;-)

Use SSH/SCP, SSL, etc, at the application layer.  The HE tunnel should be treated exactly as a normal internet connection from an ISP.  No more or less secure for your data.

[nicoduck]

Another (until now) not discussed possibility would be OpenVPN.
Since OpenVPN uses tcp and TLS there is no need for an extra function in the Router (I think soume mobile broadband provider have problems or eben block anything related to gre).

One "feature" of Aiccu is that it uses the tun/tap device. Most virtual servers have no support for sit and gre but for the tun/tap device (which is used for aiccu and also openvpn) so the only possible solution to use (non-native) IPv6 is to use aiccu and a tunnelbroker which supports tic.