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 analyze this scenario for L2TP/IPsec based VPN clients. Take note that because the L2TP protocol is protected by the IPsec protocol, that means that IPsec is the outer protocol seen by the NAT device, we will focus on the IPsec NAT Traversal problem only.
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 L2TP/IPsec 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 we will see, the design of the IPsec NAT Traversal protocol (NAT-T) does *not* require that the NAT device have a special NAT editor or “helper” for the IPsec protocol. Ironically, a NAT box with an IPsec “helper” functionality might create further incompatibilities, making an already difficult problem harder or even impossible to solve. For more information, check out the IETF document RFC 3715 – IPsec-NAT Compatibility Requirements.
Before diving into the details, it’s necessary to have a good understanding of how the IPsec protocol works and especially how the IPsec NAT Traversal is done. Also, a good understanding of how to troubleshoot such a scenario is very handy. To refresh your knowledge on how the IKE Negotiation happens, check out my blog Basic Troubleshooting for IPsec based VPN’s and related links. In short:
- In the main mode messages 1 and 2 the peers announce their IPsec NAT-T capability (VendorID or VID).
- If both peers do support it then the NAT-T discovery phase is done in the main mode messages 3 and 4 (NAT-D payloads).
- Assuming at least one NAT device is detected along the path then, from the main mode mode messages 5 and 6 onwards, the IKE traffic will move to a new UDP port number, the IKE Header will change to a Floated IKE Header format and the peer behind the NAT device will start sending NAT-keepalive packets.
Now that we know what to look for, we can finally analyze 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 IPsec IKE negotiation on both sides of the NAT device for the first and the second VPN client. When analyzing the traces, we carefully looked into the IKE main mode messages, including their IP and UDP header.
For both VPN clients we can summarize the result in the following figure:
The IKE main mode negotiation start as usual at UDP port 500. The NAT device changes as expected the IP address and UDP port number of the initiator (192.168.11.22:500 and 192.168.11.20:500). The translated packet header fields are marked with a yellow color in the above figure. After the IKE main mode message 4, both peers have detected the presence of the NAT device and therefore all further communication (main mode, quick mode and ESP) will happen at UDP port 4500 (NAT-T). Again, the NAT device will change the IP address and UDP port number of the initiator (192.168.11.22:4500 and 192.168.11.20:4500). Those translated packet header fields are also marked with a yellow color. Take note that the NAT device should not change anything else. In other words the UDP payload should not be touched at all. Moreover, the normal NAT housekeeping in the NAT device should be enough to distinguish the different IPsec sessions from each other.
For those interested what a network monitor trace looks like in the above scenario, the following figure shows what the second VPN client and the ISA server see on the wire during the L2TP/IPsec VPN setup:
Another way to prove that both VPN clients could connect to the ISA server, is looking on all the IPsec peers which IPsec security associations (SAs) are established. In the following figure we show all the main and quick mode SAs and how they are related to each other on both the second VPN client (one of the initiators) and the ISA server (the responder):
On the left-hand side the main and quick mode SAs of the VPN client (initiator) are listed. On the right-hand side the main and quick mode SAs of the ISA server (responder) are shown. Take note we marked some communication related info:
- When looking up the corresponding main mode SAs on the initiator and the responder, make sure that the cookies matches (1).
- Once the main mode SAs are found it is easy to find the used IP addresses and UDP port numbers (2). In this example you can see that the initiators socket (IP address and port number) is translated from 192.168.11.20:4500 to 192.168.1.30:62636.
- To find the corresponding quick mode SAs can be a little bit harder, especially on the ISA server (responder). The reason for this is that there might be a large number of them in a production environment. The trick is to use the IP addresses and UDP port numbers found in the main mode SA (3).
- Once the quick mode SAs are found you will note they do not reveal much additional communication related info (4 and 5). From the point of view of the IPsec NAT Traversal problem, the fact there is a quick mode SA is far more important.
It should be obvious by now that in order to pass multiple L2TP/IPsec VPN clients through a NAT device, the NAT device must *not* have a special NAT editor or “helper” for the IPsec protocol. In fact a NAT box with an IPsec “helper” functionality might create further incompatibilities. So, if you have problems with multiple L2TP/IPsec 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