PPTP Passthrough and How It Works
July 28, 2011 4 Comments
Most computers connect to the Internet through a NAT device (usually a router). PPTP natively doesn’t work with NAT. Since most VPN connections start from behind a router this is a very common problem. PPTP passthrough addresses this by allowing VPN connections to traverse a NAT with ease. NAT (or more specifically PAT) can’t function without the use of ports. It is important you understand how NAT functions and it’s reliance on ports. If unsure I would advise reading up on network address translation first.
NOTE: With some routers multiple VPN connections is not supported.
The PPTP Problem
PPTP uses a TCP channel on port 1723 for control and the GRE protocol to encapsulate data and create a VPN tunnel. The issue isn’t really PTPP itself but GRE; GRE doesn’t use ports. Since a requirement of NAT is that the connection must use an IP address and port number it doesn’t work with GRE. This is what PTPP passthrough addresses.
How PPTP Passthrough Works
There is nowhere on the internet that officially states how PPTP passthrough works so I started my own investigation. I found that PPTP doesn’t use the standard GRE protocol but an enhanced GRE version. When you compare GRE to Enhanced GRE there are several differences but the only one we are interested in here is the addition of something called the Call ID. When a PPTP client attempts a connection it generates a unique call ID and inserts it into the modified header. At this point I realised it could be used as a replacement for ports in the NAT translation. After a bit more research on call ID I came across how PPTP port mapping is handled by Microsoft routers. This MS article confirms that the Call ID is used to uniquely identify PPTP clients behind a NAT; it used as a substitute for ports for PPTP traffic ONLY. This is non standard to how NATs function but is necessary to allow PPTP to pass through it. As it is non standard routers need to know to switch from ports to call ID’s when it sees PTPP traffic. Adding this feature is what PPTP passthrough is.
Conclusion
Routers that support PPTP passthrough allow VPN clients to make outbound PPTP connections. The only way this would be possible is by using the methods described above. This leaves no doubt that the above must be exactly what PPTP passthrough is.
You may also want to read VPN passthrough
I’m having a little trouble understanding how PPTP works. Especially the following:
“PPTP traffic consists of a TCP connection for tunnel maintenance and GRE encapsulation for tunneled data”
Does that mean that the ‘TCP maintenance packets’ are encapsulated by another layer of TCP (port 1723) and IP headers and not encapsulated by GRE?
And am I correct in assuming that actual the tunneled data isn’t encapsulated with these extra TCP and IP headers defining a particular port, but only by GRE inside PPP?
Could you show an example of how these packets look like? For example:
[ethernet][PPP][IP][TCP][HTTP][TCP][IP][PPP][ethernet]
or
[ethernet][PPP][IP][TCP][GRE][IP][TCP][HTTP][TCP][IP][GRE][TCP][IP][GRE][PPP][ethernet]
I’m really confused as to how these packets are contructed?!?
The TCP 1723 connection is separate to the GRE connection. The 1723 packets are not encapsulated. The port/channel is used to send information back and forth to both parties giving information about the GRE connection. It controls the initiation, maintenance and tear down (closing the connection) of the GRE connection. It controls the flow of data etc.
The GRE encapsulates your LAN traffic and it is that simple. Say your IP is 192.168.0.1 and the remote LAN IP you send data to is 192.168.1.1. When you send data to the remote IP the tunnel detects this and sends it through the PPTP virtual interface. At this point all packets are now encapsulated in a new IP packet this time containing the public IP address and port of the remote location and is sent on it’s way. Once the remote PPTP endpoint receives it, it strips off the GRE headers and finds the LAN IP headers for 192.168.1.1 and sends them on there way. Make sense now?
Remember that GRE stands for General Routing Protocol and does exactly that, it encapsulates IP packets into another IP packet with extra routing information, that is all it does.
Okay, I think I understand now.
But what happens when the PPTP server is behind a NAT router/firewall? I understand you need to allow/forward traffic received on port 1723 to the PPTP server to setup the control channel for the GRE tunnel. But how does it treat the GRE-encapsulated data? Wouldn’t it also need PPTP passthrough to understand how to treat the inbound GRE-encapsulated data coming from the client?
As I understand from your article; when a NAT router supports PPTP passthrough it can detect the ‘Call ID’ from the GRE headers and use this as the (source/destination?) port to use for the NAT translation. Correct?
Yes you need to forward 1723 to the PPTP server.
In answer to your question about how it handles the GRE; strictly speaking you need to open up GRE on your router and forward this onto the PPTP server also. But most routers do this automatically when you open 1723. Since 1723 is for PPTP and GRE is part of PPTP most routers just auto forward GRE to the same IP you have forwarded PPTP to.
In answer to your last question about whether you have understood it correctly, yes you have.