We'll review here PPTP VPN, how it works, and its current security state.
For the basis knowledges and theory of VPN, see this post
Last edit : June 30 2014
PPTP ( Point-to-Point Tunelling Protocol ) is the oldest type of VPN protocol. It is versatile ( it can encapsulate other layer 3 protocol than IP ), widely implemented ( most computer OS and mobile OS support PPTP ), and manage to traverse firewall quite easily.
Moreover, it is fast and light for the CPU.
Here is the PPTP encapsulation used to build the tunnel :
The tunnel is initiated and maintained with a control channel using TCP 1723
The tunnel itself uses GRE ( IP protocol 47 )
So two connections are used to maintain the tunnel, a control channel and the GRE tunnel itself.
Here is the PPTP tunnel, in a host-to-site configuration. The host initiates the connection :
Important to note is that the GRE tunnel, using PPP, is able to tunnel other layer 3 protocols than IP.
PPTP IP networking
At the IP level, the PPTP Server creates a private subnet, on a different range than its native lan subnet, and starts routing this two subnets. It assigns itself one IP, and readies to leases to VPN clients IP addresses in this range, advertising itself as a gateway :
To be noted is that PPTP creates a virtual network interface, both on the PPTP server and on the PPTP clients.
The DHCP advertisements are advertised with a minimal metric, so that all the client's traffic will use this gateway, and not its local lan gateway.
If PC1 traffic is not directed to Subnet B, The VPN Gateway will route it to the Internet using its WAN interface. Here is the path of a client's outbound connection to the Internet :
A few final notes :
Subnets A, B and C have to be different, for the VPN routing to function. This may lead to the need to renumber the Home Lan Subnet ( Subnet B ) to a rarely used subnet range ( example : 192.168.197.0 / 8 )
SIte-to-site PPTP VPN or Host-to-Host PPTP VPN behave in a similar way.
PPTP and NAT
PPTP uses a GRE tunnel, and GRE uses no ports. This creates a difficulty for the IPv4 NAT Router to identify PPTP VPN sessions and direct to the right LAN host. This scenarios may happen :
1. The IPv4 NAT Router doesn't understand what is happening, and drops the traffic.
2. The IPv4 NAT Router manage to handle a unique PPTP VPN session, linking the GRE tunnel to the last outbound GRE LAN host. But it can't handle multiple simultaneous or fast switching PPTP VPN sessions.
3. The IPv4 NAT Router performs Deep Packet Inspection and keep states, to bind GRE WAN IPs and LAN hosts.
Or the IPv4 NAT Router understand GREv2, which adds an ID tag.
In this case, multiple simultaneous or fast switching PPTP VPN sessions will function seamlessly
The ' PPTP VPN Passthrough ' option may need to be ticked on the IPv4 NAT Router.
( I have an experiment going on, to poll-out Wifi Hotspot PPTP VPN functionning. I'll post results here )
PPTP provides authentication. Beside, MPPE ( Microsoft Point to Point Encryption ) can provide encryption, and MPPC ( Microsoft Point to Point Compression ) can provide compression.
Here are the available authentication methods with their security features :
PAP Clear text authentication
No MPPE support
CHAP Good, protection from replay attack, no password sent
No MPPE support
MSCHAPv1 Trivial to crack, using a XOR compute
MSCHAPv2 Dictionnary attack
Brute force attack ( 23 hours )
Retro-protocol attack ( towards MSCHAPv1 )
EAP-TLS Secure, but requires public key infrastructure
PAP is obviously unsecure. CHAP doesn't support MPPE. MSCHAPv1 is unsecure.
So we only have MSCHAPv2 and EAP-TLS left from a security standpoint.
MPPE supports 40 bits and 128 bits encryption. 40 bits is totally insecure, so 128 bits is mandatory.
Beside, the authentication and encryption protocols are just as secure as the password length, so using a 128 bits password is mandatory too.
note : MPPE is subject to bit flipping attacks. There is no Data Integrity here.
note 2 : MS-CHAPv2 strength is equivalent to a single DES ( 56 bits )
Here is a chart to sum-up the Data leaks of each option :
( IPs is for source and destination IPs encryption, not tunnel endpoints encryption of course ).
( The EAP-TLS line will be completed soon )
It is to be noted that two options ( if available ) somehow makes brute-forcing attacks a little more difficult :
. Stateless encryption : Key is changed in each packet ( vs Statefull encryption, where key is changed every 256 packets )
PPTP data Leaks
PPTP has several issues with data leaks. Let's review them one by one.
Tunnel stability : If the tunnel gets down for whatever reason, this will remain unnoticed for a lapsetime that will allow data to freely flow through the unprotected path. This issue is difficult to mitigate. Solutions to this issue :
. Using firewall rules
. Subtly changing the OS routing tables+using all static IPs ( Ex : Set all static IPs, enter a bogus default gateway, and add a static route for the PPTP Server IP : No packet will leave the LAN, except towards the PPTP server. The PPTP server will then set itself as a default gateway all through the tunnel life. When the tunnel gets down, packets are again trapped in teh LAN).
IPv4 DNS leaks : When using DHCP, the registered DNS server may be the local router wich acts as a DNS proxy ( ex : 192.168.1.1 ). This address may be kept while creating the tunnel ( Using Windows mainly ). In this case, the DNS requests might not take the VPN path : 192.168.1.1 being a local network, the VPN might get bypassed .
Another case may be the VPN DNS being a little too long to respond, the OS may failover to the regular registered DNS.
The simplest solution to this problem is to use static DNS IP of a trusted third-party provider ( ex : OpenVPN, Google Public DNS, Comodo Secure DNS, ... ) on all network interfaces ( normal or VPN ).
IPv6 leaks : PPTP tunnels almost never support the transport of IPv6 packets. Modern OS being set to prefer using IPv6 over IPv4, if there is an available IPv6 connectivity, the unprotected path will get preferred. The simple solution to this is to disable IPv6 on the network interfaces.
PPTP Security Conclusions
In the end, the two PPTP useable options are :
. MSCHAPv2 ( with 128 bits encryption/128 bits entropy password, and optionally stateless encryption+compression )
First, let's state that PPTP is always way better than nothing while using a public wifi hotspot.
MSCHAPv2, while vulnerable, may be enough in many cases assuming a complexe password is used. You need to evaluate if cracking this PPTP is of any interest for someone, and worth the time and money spent. Still, CPU, GPGPU and ASICS crunching power is on a ever upslope, so these 23 hours of brute-force resistance are allready weakened as we're writing here.
Finally, there are the stability and leaking issues the really need some extra-care.
If we want a real secure VPN, L2TP, IPSEC or SSL VPN is needed.