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

I want to share the following information provided by Jim Harrison about the random authentication prompts from Windows Media Player (WMP).

Problem:

WMP sometimes displays authentication prompts even though the logged-on user account is resolvable by the ISA server and has permissions to access the content through the ISA server policies.

Scenario:

The ISA web proxy is configured for Windows Integrated authentication. The ISA server policies enforces authentication for HTTP traffic. WMP is configured to use the ISA server as a web proxy server for the HTTP protocol (this includes “autodetect” or “browser”).  

Discussion:

When WMP is acting as a web proxy client (CERN) and the web proxy server requires Windows Integrated authentication, WMP will not auto-authenticate to the web proxy server if the web proxy server is specified as either an FQDN or an IP address. If the web proxy server is specified as a NetBIOS (unqualified) name, WMP will auto-authenticate using the interactive account credentials. If the web proxy server requires Basic or Digest authentication, an authentication prompt is expected, regardless of how the web proxy server is specified. This behavior is the same if the web proxy server is obtained via an automatic configuration (WPAD) script.

By default, ISA 2004 and higher lists the web proxy servers using their IP addresses in the WPAD script. This default was chosen to prevent name resolution errors from impeding normal client-to-web proxy communications. While this works well enough for browsers, WMP has issues when the web proxy server is specified using anything other than the NetBIOS name.

Solution (two-part):

1. Disable the proxy server settings for HTTP (pick one).

• Using WMP:
  under Tools, Options, Network, Protocols, HTTP, set to None
  
• Using Regedit:
  Key: HKCU\Software\Microsoft\MediaPlayer\Preferences\ProxySettings\HTTP
  Name: ProxyStyle
  Type: DWORD
  Value: 0
  
• Using GPO:
  under User Configuration\Administrative Templates\Windows Components\Windows Media Player\Networking, set the Configure HTTP Proxy option to Disabled.

2. Install the Firewall client from Microsoft downloads http://www.microsoft.com/downloads/details.aspx?Fa...43da89

After making this two changes, the Firewall client will handle all HTTP requests from WMP and ISA server authentication will now be satisfied through the Firewall client control channel instead of the HTTP protocol mechanisms. This will stop the random authentication prompts from WMP.

HTH,
Stefaan

When ISA server delivers the WPAD script, it sets a Cache-Control header with the value “max-age=3000″, that means 50 minutes. Internet Explorer rounds this up to 1 hour. So, if you are testing WPAD changes, i.e. you are playing with “Auto Discovery” or “Direct Access”, then you will need to be sure to delete the previously acquired WPAD script and resolved WPAD name.

The easiest way to accomplish this is to execute the following steps:

1. Clear the Internet Explorer cache completely: ActiveX Controls, Cookies, History, etc..
   
2. Close all instances of Internet Explorer.
   
3. Delete all WPAD script instances. Open a command window as administrator and type the following command:
   del \wpad*.dat /s
   
4. Clear the DNS and Netbios name caches. Open a command window as administrator and type the following commands:
   ipconfig /flushdns
   nbtstat -R

You should now have a clean starting point for testing WPAD script changes.

HTH,
Stefaan