Multiple PPTP VPN clients behind a NAT device

An ever recurring topic on the message boards is the inability to connect to a VPN server with multiple VPN clients from behind a NAT device. We can assure you that if you run an up-to-date ISA 2004/2006 server, that means one with all the latest ISA and Windows service packs, the culprit is *not* the ISA server but definitely the NAT device not handling properly multiple VPN clients. In this blog we will analyse this scenario for PPTP based VPN clients.

As always, we will use my ISA lab running in VPC 2007 to setup this scenario. The ISA 2006 Server used is listening on the Local External Network (192.168.1.0/24) and the PPTP VPN clients are sitting on the Remote External Network (192.168.11.0/24). Both networks are interconnected with a Windows 2003 RRAS box acting as a NAT device (N:1). As you probably know, RRAS implements a PPTP aware NAT editor to fully support such a scenario.

Before diving into the details, it’s necessary to have a good understanding of how the PPTP protocol works. Of course the authorative resource is the IETF document RFC 2637 – Point-to-Point Tunneling Protocol (PPTP). If you take the pain reading that RFC, be aware that the VPN client is acting as PNS (PPTP Network Server) and the ISA Server as PAC (PPTP Access Concentrator). However, we can recommend an excellent written Cable Guy article called PPTP Traffic Analysis. It explains very well how the PPTP protocol works and what you have to watch out for when NAT is involved along the path. This is definitely a must read!

When tracing a normal PPTP session setup with a network monitor, you should see the following sequence of frames:

In this example the VPN client is 192.168.1.20 and the VPN gateway (the ISA server) is 192.168.1.10. So, both are connected to the same network ID (192.168.1.0/24). As mentioned in the Cable Guy article the negotiation of the Call ID in the PPTP Outgoing Call Request and Outgoing Call Reply messages is extremely crucial. If we expand those frames 6 (left) and 7 (right) in the above example we get:

You can clearly see that the VPN client chooses the value 256 as his Call ID and the VPN gateway the value 63881. Take note that the VPN gateway repeats the client’s Call ID in the Outgoing Call Reply message as Peer’s Call ID. This must match the Call ID of the corresponding Outgoing Call Request message. Also, those Call ID’s will be further used in the Enhanced GRE header of the PPTP data packets to multiplex/demultiplex the different tunnel sessions between the VPN client (PNS) and the VPN gateway (PAC).  More precisely, each sending party will use the peer’s Call ID in the Call ID field to indicate to which session the packet belongs. In other words, the tunnel is identified by the source and destination IP address and the Call ID field in the Enhanced GRE header. To illustrate this, we expanded the frames 9 (left) and 10 (right) in the above example:

Now that we know what to look for, we can finally analyse the N:1 NAT scenario. To accomplish that we placed two VPN clients behind a NAT device (in this case an RRAS server) and simultaneously traced with a network monitor the PPTP session setup on both sides of the NAT device for the first and the second VPN client. When analysing the traces, we carefully looked into the PPTP Outgoing Call Request and Outgoing Call Reply messages, as well into a PPTP data packet in each direction belonging to that session.

For the first VPN client we can summarise the result in the following diagram:

Because this is the first VPN client connecting to that specific VPN gateway, the NAT editor may but must not do anything special except the normal translation of the IP addresses in the IP header (PPTP control connection and PPTP data packets) and the TCP port numbers in the TCP header (PPTP control connection). Remember that the VPN gateway (the ISA server in this case) will see the NATted IP address as source of the tunnel. Also, take note that the VPN client assigns itself again a Call ID value of 256. Apparently this is the standard value for the Windows VPN clients we used on Windows XP and Vista.

For the second VPN client we can summarise the result in the following diagram:

Because the second VPN client is completely unaware of the first one, the second might also pick the same Call ID value, as in this case. Therefore, the NAT editor on the NAT device must also be capable to monitor the PPTP tunnel creation and if necessary translate the Call ID generated by the VPN client to a unique value just like the TCP/UDP source port numbers are translated. Otherwise, the tunnel can not be unambiguous identified between the NAT device and the VPN gateway. Remember that the triple source IP, destination IP and Call ID must always be unique per tunnel. Also, take note that the Call ID generated by the VPN gateway will always be unique because the gateway is perfectly aware of the other tunnels from/to that specific NAT device (NATted IP address).

It should be obvious by now that in order to pass multiple PPTP VPN clients through a NAT device, the NAT device *must* have a specific PPTP NAT editor. So, if you have problems with multiple PPTP VPN clients behind a NAT device, don’t blame the ISA server but get out your favorite network monitor tool to determine if the NAT device is behaving well.

HTH,
Stefaan