WindowsNetworking.com Newsletter of April 2008

WindowsNetworking.com Monthly Newsletter of November 2008 Sponsored by: GFI

Welcome to the WindowsNetworking.com newsletter by Thomas W Shinder MD, MVP. Each month we will bring you interesting and helpful information on the world of Windows Networking. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to: tshinder@windowsnetworking.com

Have your event logs monitored automatically

Let GFI EventsManager do the dirty work – Have event logs monitored automatically and get warned about critical events! Analysis of event logs including SNMP Traps, Windows Event logs, W3C logs and Syslog.

Download a free trial today

1. IPSec NAT Traversal

The Network Address Translation (NAT) routing protocol allows multiple internal network clients to access the Internet through a NAT server that only has one or a handful of IP addresses. There are actually several types of NAT. The networking purist would maintain that the term NAT only applies when you map an IP address on the external interface of the NAT server to an IP address on the internal network. This type of NAT is more commonly known as "static NAT'. All packets to and from a particular IP address on the external interface of the NAT server are associated with a specific host on the internal network.

The type of NAT we normally work with is sometimes called "PNAT" (Port and Network Address Translation). This allows multiple clients on the internal network to use the same IP address on the external interface of the NAT server as their source address when communicating with Internet servers. The NAT server replaces the original source IP address and TCP/UDP port number (which together represent the original "socket" if you are working with a socket based application) with a valid public IP address and port number on its own external interface. The NAT server keeps track of the changes it made in its "NAT table" so that it can properly return packets to the internal network clients after the NAT server receives responses from the Internet servers.

NAT works because it can change network and transport layer header information. When the NAT server changes the source IP address on a packet, it changes the network layer header information. When the NAT server changes the UDP or TCP source port number, it changes the transport layer header information. There usually are no problems with changing this header information because the NAT server keeps track of the original packet configurations in its NAT table.

How IPSec Breaks NAT

You run into problems when you want to use IPSec based VPN technology to connect a VPN client behind a NAT server to an IPSec VPN server on the Internet. The reason for this is the IPSec protocols are designed to authenticate and/or encrypt information in the packet. When a NAT server tries to change the information in the packet, it will either cause the packet to be considered invalid by an IPSec protocol, or it will be unable to perform the translation because information the NAT protocol needs to access is encrypted.

The two IPSec protocols causing problems for NAT are the Authentication Header protocol (AH) and the Encapsulating Security Payload protocol (ESP). AH is used to authenticate packets while ESP can authenticate and/or encrypt packets. Both these protocols can work in transport or tunnel mode. Transport mode is used when you want to create a host to host connection. A host to host connection creates a tunnel used only by the machines representing the tunnel endpoints. On the other hand, Tunnel mode allows a tunnel client to connect to a tunnel server to access resources on the tunnel server and the network or networks behind the tunnel server.

AH in Transport Mode authenticates the entire packet from IP header to the end of the application layer data and trailers. AH in Tunnel Mode also authentications all headers from the IP tunnel header to the application layer data and trailers. ESP in Transport Mode authenticates from the ESP header to the ESP trailer and it encrypts the TCP/UDP header and application data, while leaving the IP header and ESP authentication trailer in the clear (no authentication or encryption).

What do you think a NAT server would do to AH in either transport or tunnel mode? AH has authenticated the entire packet from IP header to trailers. When the NAT routing protocol tries to change the IP and UDP/TCP header information, the AH protocol will balk, flag the packet as having its integrity violated, and drop it. This is the case with both AH transport and tunnel mode.

Now what do you think would happen with ESP packets? When using ESP in Transport mode, the IP header is in the clear, so the NAT routing protocol can change that without causing any problems. However, TCP/UDP header is encrypted! The translation will fail because the transport layer header is encrypted, and the NAT server that performs PNAT must be able to access and change this information. ESP in Tunnel Mode is possible for the packet header standpoint, but there are other issues related to IKE security negotiations that make IPSec through NAT fall apart.

NAT Traversal to the Rescue

It is clear that something has to change if you want to use an IPSec based protocol through a NAT server. The change proposed by the IETF is to encapsulate IPSec traffic in a UDP header which is not exposed to ESP (we would not even worry about AH because of its proclivity to authenticate the entire packet). UDP encapsulation allows the ESP protected packet to "traverse" the NAT server.

This type of UDP tunneling allows the source port and IP address to change because the tunnel headers are not affected by ESP. When the UDP packet arrives at the IPSec VPN server, the UDP header is removed and the VPN server can make an assessment regarding whether the packet is normal IPSec packet or an IPSec NAT Traversal packet. The entire process is referred to as "IPSec NAT Traversal".

IPSec NAT Traversal actually involves a negotiation of the NAT Traversal protocol between the VPN client and server, as described by the following steps:

  1. VPN client and server exchange vendor specific ID string (which is an MD5 hash) to confirm that both sides support IPSec NAT Traversal.
  2. NAT Discovery takes place and determines which participant is behind the NAT device. This is important because the VPN client behind the NAT device needs to send keep-alive messages every 9 seconds. NAT Discovery messages compare source and destination IP addresses to determine which host is the VPN client behind the NAT.
  3. IPSec NAT Traversal will be used between the VPN client and Server after the NAT device is discovered to be in the path. The VPN client and server will use UDP encapsulated transport or tunnel mode ESP.
  4. The transport or tunnel mode ESP packets are encapsulated in a UDP packet with a destination port number 500, which is the same port number used for the Internet Key Exchange Protocol (IKE - ISAKMP/Oakley). The VPN server can use the same port number of NAT Traversal packets and non-NAT Traversal packets. The IPSec NAT Traversal aware VPN server identifies the NAT Traversal packets because the UDP header from the client overwrites the 8 bytes of the IKE initiator cookie field is all zeros. 
  5. During the active VPN session, the VPN client sends a "keep alive" packet to the VPN server every 9 seconds. This is important because if the NAT server in front of the VPN client times out the current session and port assignment on the external interface of the NAT server, then when the VPN client starts sending packets again to the VPN server, a new port number is assigned, which breaks the IPSec security associations between the VPN client and server (which are dependent on the source UDP header information). Security associations would break before you want them to if it were not for the "keep alive" messages.

While IPSec NAT Traversal does solve most of the major problems with passing IPSec packets through the NAT device, it can not solve all of them. The major problem lies in the fact that poorly designed protocols such as FTP, the H.323 protocol suite, LDAP and many others embed the actual source IP address in the application layer data.

A NAT device can usually get around this problem by using NAT editors to change the information in the application layer data so that the appropriate public IP address and ports numbers are used instead of the actual client. The NAT editor approach can not work with IPSec NAT Traversal because the application layer data is encrypted by ESP while it passes through the NAT device.

Conclusion

NAT is a useful routing protocol that allows us to continue using the venerable IPv4 addressing scheme for hopefully another decade or two. While NAT can easily translate both the source IP address and port number, the translation process strikes at the heart of both the AH and ESP protocols. While there is not much hope for AH, the IPSec NAT Traversal Protocol will allow you to use ESP in tunnel mode to connect your VPN clients behind a NAT server to an IPSec VPN server on the Internet. Of course, if you want to make your life easier and almost equally secure, you can use PPTP and take advantage of the NAT editor that comes with the Windows 2000 RRAS to pass PPTP through the NAT and to the PPTP VPN server on the Internet.

Thanks!
Tom 
tshinder@windowsnetworking.com

=======================

Quote of the Month - "“The future, according to some scientists, will be exactly like the past, only far more expensive”. - John Sladek

======================

2. ISA Server 2006 Migration Guide - Order Today!

Dr. Tom Shinder's best selling books on ISA Server 2000 and 2004 were the "ISA Firewall Bibles" for thousands of ISA Firewall administrators. Dr. Tom and his illustrious team of ISA Firewall experts now present to you , ISA Server 2006 Migration Guide. This book leverages the over two years of experience Tom and his team of ISA Firewall experts have had with ISA 2006, from beta to RTM and all the versions and builds in between. They've logged literally 1000's of flight hours with ISA 2006 and they have shared the Good, the Great, the Bad and the Ugly of ISA 2006 with their no holds barred coverage of Microsoft's state of the art stateful packet and application layer inspection firewall..

Order your copy of ISA Server 2006 Migration Guide. You'll be glad you did.


   Click here to Order
   your copy today

Have your event logs monitored automatically

Let GFI EventsManager do the dirty work – Have event logs monitored automatically and get warned about critical events! Analysis of event logs including SNMP Traps, Windows Event logs, W3C logs and Syslog.

Download a free trial today

3. WindowsNetworking.com Articles of Interest

4. KB Articles of the Month

5. Windows Networking Tip of the Month

Have you noticed that some of your Vista machines lose their DHCP assigned IP addressing information even though they have a valid lease? This happens when the Vista client cannot communicate with a DHCP server. DHCP clients with unexpired leases should be able to keep their IP addressing information, even when there is no DHCP server. What's up with that?

You can add a Registry value to fix this problem. Try this out:

  1. Open Registry Editor. To do this, click Start, type regedit in the Start Search box, and then press ENTER.
  2. If you want to activate the setting for all adapters, locate the following registry subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
    Or, if you want to activate this setting for a specific adapter, locate the adapter-specific registry key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\
  3. On the Edit menu, point to New, and then click DWORD Value.
  4. Type DontPingGateway, and then press ENTER. 
  5. On the Edit menu, click Modify.
  6. In the Value data box, type 1, and then click OK
  7. Exit Registry Editor.
  8. Restart the computer

Have your event logs monitored automatically

Let GFI EventsManager do the dirty work – Have event logs monitored automatically and get warned about critical events! Analysis of event logs including SNMP Traps, Windows Event logs, W3C logs and Syslog.

Download a free trial today

6. WindowsNetworking Links of the Month

7. Ask Dr. Tom

QUESTION:

Hi Tom,

I noticed that when I ran the disk cleanup tool that my hibernation does not work anymore on my Vista computer. To make things worse, I can not find how to enable hibernation again! Can you help a guy out? Thanks! - Woody.

ANSWER:

Hey Woody,

This problem happens when the disk cleanup tool disables the hibernation file on your hark disk. The reason why you can not find an interface for configuring hibernation on your Vista computer is that it doesn't exist! Yes, they took that out. Why? I don’t know, I was not at that meeting :)

However, there is a fix. Try this out:

  1. Click Start , click All Programs, and then click Accessories.
  2. Right-click Command Prompt, and then click Run as administrator. If you are prompted for an administrator password or for confirmation, type the password, or click Continue.
  3. Type powercfg -h on, and then press ENTER

Your computer will now be able to take advantage of hibernation again.

Got a question for Dr. Tom? Send it to tshinder@windowsnetworking.com.

Have your event logs monitored automatically

Let GFI EventsManager do the dirty work – Have event logs monitored automatically and get warned about critical events! Analysis of event logs including SNMP Traps, Windows Event logs, W3C logs and Syslog.

Download a free trial today