Both IPsec and NAT have been with us for some time, but making them play together has been hard work. To IP gurus, NAT (Network Address Translation) is an ugly kludge because it changes the way IP works at a fundamental level. To you, the network manager responsible for handling network-addressing issues, NAT is often your friend, regardless of whether you're at a large ISP or enterprise, or at an SME (small-to-medium enterprise). Why? Because NAT lets you hide networks and hosts in a variety of ways. Likewise, IPsec (IP security) is your friend because you can securely connect remote offices and users over the Internet.

However, the architecture of the IPsec protocol suite and the dearth of IPsec-aware NAT devices have created problems in getting the two to work together seamlessly. The simplest solution is to have a broadband router that performs NAT and VPN (virtual private networking) on the same device, so you don't have to muck around making IPsec and NAT play nice. But because you don't always have that luxury, you should know about some of the ways vendors are addressing the IPsec-NAT issue and its implications.

There are two primary NAT implementations. Dynamic address NAT assigns a temporary external IP address to a private IP address, translating only the IP address. Dynamic address NAT is used mostly in dial-up or in on-demand connections in which remote connections go up and down frequently (see ‘Dynamic Address NAT’ below). While the remote user is connected, he or she is assigned a single IP address; once that user disconnects, the IP address is released to be reused at a later time.

NAPT (Network Address Port Translation) is the form of translation with which most people are familiar. NAPT is used almost exclusively by access devices designed to hide small-to-medium-sized networks behind a single public IP address. NAPT works by translating the source IP address and the source port number on the public interface (see ‘NAPT’ graphic below).

NAPT is especially useful when cable or DSL access is deployed, because many service providers charge extra for multiple computers to be connected to the Internet (though how many addresses you get and for how much is locale-specific).

Next, a general background on IPsec: There are two modes of IPsec. Transport mode simply applies IPsec protocols to an IP packet and leaves the original IP headers visible. Transport mode can be used only in host-to-host IPsec VPN. Tunnel mode IPsec encapsulates the original IP packets into an IPsec packet with new IP headers. Tunnel mode effectively hides the original IP packets from view. Tunnel mode IPsec must be used in host-to-gateway IPsec, the common remote-access scenario.

There are two IPsec protocols with which we're concerned: AH (Authentication Header) and ESP (Encapsulation Security Payload). AH, rarely deployed, verifies that fields that are required to prove the identity of the sending device, such as source and destination IP addresses, have not been altered in route. If the packet fails the verification, it is dropped. Thus, AH provides data integrity and origin authentication. We'll see later that AH is broken by all forms of NAT. ESP, on the other hand, encrypts IP data. When used in tunnel mode, it provides data integrity and origin authentication services as well.

IPsec VPNs exchange information through logical connections called SAs (Security Associations). An SA is simply a definition of the protocols, algorithms and key validity time period used by endpoints. Each IPsec VPN has two SAs – one in each direction. SAs are identified by three identifiers. One of them is a unique number called the SPI (Security Parameter Index), which is assigned by destination to each SA. The other two identifiers are the destination address and the protocol. The uniqueness of the SPI is guaranteed because a destination endpoint may have a manually configured SPI defined that the originator would not know about.

Finally, the IKE (Internet Key Exchange) is a separate SA that is used to negotiate the other IPsec protocol parameters. IKE uses UDP Port 500 and as such can be passed through a NAT without any special handling, like any other TCP/UDP protocol. IKE is active during the entire lifetime of the lower-level SA.

Now here is where things get interesting. Let's look at some cases in which IPsec and NAT fail. NAT and AH IPsec will fail because,, by definition, NAT changes the IP addressing of the IP packet. Any change in the IP packet will be flagged as a violation by AH. Failure also occurs when there is a NAPT function between the two IPsec endpoints that doesn't know how to handle IPsec traffic.

Likewise, ESP IPsec and NAPT will fail, because in the case of transport mode, the port numbers are protected by ESP, and any change will be flagged as a violation.

In tunnel mode ESP, the TCP/UDP headers are not visible and can't be used to translate between inside and outside. In this discussion, we are assuming that there is only one NAT device in the network. If there are more, they all need to be IPsec-aware to pass traffic properly. Static NAT and ESP IPsec will work just fine, because only the IP addresses are translated, regardless of upper-layer protocols.

Cisco Systems' Cisco 3060 and its VPN client support remote users through NAT by encapsulating the IP packet into UDP before hitting the network. Because the outer UDP and associated IP header aren't protected in any way, they pass through NAT devices of all kinds without a problem. The receiving Cisco 3060 must de-encapsulate the incoming packet and process it. This works only with the Cisco 3000 line.

There are other proposals in the IETF to standardize the encapsulation of IPsec in UDP, notably IPsec NAT-Traversal in the Network Working Group and RSIP (Realm-Specific IP) for end-to-end IPsec in the Network Address Translators Group. SSH Communications Security is making its NAT Traversal Toolkit available later this quarter.

So that leaves us with one situation: ESP IPsec with NAPT. There are two ways that vendors are solving this problem. The simplest way, which allows only one IPsec VPN to pass through the NAPT, is to associate a single workstation that is running IKE with all IPsec packets.

This method is employed by vendors such as D-Link Systems, Linksys and Macsense Connectivity. You can expect to spend between $100 and $200 for an SME NAPT router.

Any IPsec packets that come into the NAPT device are forwarded by default to the designated host. This is accomplished because the client starts the negotiation by sending data to the other end on Port 500. That process signals the NAPT device to send all IPsec data back. Both ESP and AH are IP protocols and are assigned protocol Nos.50 and 51, respectively. While not the most robust implementation, it does work for single installations. But what happens in the case where there are multiple workstations wanting to use IPsec?

In that case, you should get a product like Nexland's ISB2LAN or Asante Technologies' FriendlyNet 10/100 cable/DSL router, which supports multiple IPsec clients behind a NAPT device. These more robust products run between $150 and $250, depending on the features.

To get NAPT to work, we have to rely on the uniqueness of the source port number to translate between the private and public networks. Thus, we can negotiate IKE without any special process because IKE is a UDP protocol using Port 500.

To pass IPsec traffic between hosts, we need something equally unique, and we find that in our friend the SPI. Remember, each IPsec SA is identified by the SPI, the destination IP address and the protocol number. When IKE is negotiated during VPN setup, the SPIs are being exchanged, and the NAPT device maps the pair of SPI numbers to the associated VPN endpoint behind the NAT

The only SPI that needs to be mapped to an internal IP address is the incoming SPI selected by the IPsec client, because the NAPT device needs to know where to send inbound traffic. Outbound traffic is passed without a problem, because the IPsec client's IP address will be changed by the NAPT device.

There are some caveats, however. First, this scenario will work only when the IPsec client behind the NAPT device is initiating the IPsec VPN. If the IPsec gateway tries to initiate the connection the NAPT device will block the negotiation, because it won't know where to send the UDP packets; it won't have a NAPT mapping. For the same reason, you cannot host a Web server behind a NAPT device without using port redirection, where all packets bound to a specific inbound port are by default sent to an internal IP address. Port redirection works only when preconfigured.

Second, for this to work, you will have to configure your IPsec gateway to negotiate IKE with the NAPT gateway at minimum or any IP address. ESP uses the SPI, destination IP address and protocol number to look up what SA an IPsec packet belongs to. Because the IPsec gateway knows the IPsec client only by the NAPT address, that is the address that will be used.

Finally, much of IKE authentication is still handled with a preshared secret, or password, which is associated with an IP address. Therefore, you have to tell the IPsec gateway to negotiate with the NAPT IP address. Because remote users often connect via dynamic IP addresses allocated from their ISPs, nearly all IPsec gateways can associate a shared secret with an address range.

If I knew, for example, that the NAPT device in translating IPsec would always come from an IP address on the 192.168.1.0 subnet, I would configure the IPsec gateway with one shared secret for the entire subnet. I would then have to configure each IPsec client behind that NAPT device with the same shared secret. As a result, this is really no different from how you go about typical IPsec remote access.

Many a network administrator has tried to set up a virtual private network (VPN) client from a workstation with a nonroutable (private) IP address only to find out—amid much frustration—that the network address translation (NAT) on the Internet router keeps the VPN client from making the connection. We’re going to look at the reasons behind this common problem and see what you can do about it.

First, here are four basic concepts you need to understand:

Encapsulation involves wrapping a header around a data unit, typically an IP packet. Encapsulation can also be referred to as tunneling. For instance, IP packets get encapsulated in a frame-relay header when they traverse a frame-relay WAN.

Encryption provides a way to secure sensitive data by translating it into private code. It can then be decrypted only by using a secret key or a password.

A VPN encapsulates and encrypts packets to send a private network’s data over a public network (such as the Internet) to another private network. Point-to-Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol (L2TP), and IP Security (IPSec) are the most popular protocols for securing VPN traffic.

Now we need to look at a few of the important differences between the two VPN tunneling methods:

These two open protocols are popular across multiple platforms. However, they usually encapsulate and encrypt the IP datagram, which contains the IP source and destination addresses. This can make them troublesome for NAT. IPSec can work in two different ways: transport and tunnel.

Transport mode is between a client and a server. Tunnel mode is between two IPSec tunneling gateways (for instance, two routers or servers). In transport mode, the application headers, TCP/UDP headers, and data are encrypted, leaving the IP headers exposed. The authentication data is calculated based on the values in the IP header (among other things). In tunnel mode, the entire packet (including the IP headers) is encrypted and new IP headers are appended.

This Microsoft propriety protocol does not encapsulate or encrypt the IP datagram, which makes this protocol compatible with NAT, or “NAT friendly.” Windows 2000 RRAS (Routing and Remote Access Services) uses this VPN protocol by default. If you are using NAT, choosing Windows 2000 VPN (RRAS) services with PPTP can greatly simplify your VPN-NAT issues.

NAT is supposed to be transparent to whatever applications it works with. Many NAT and VPN dilemmas are created by this assumption. NAT can break a VPN tunnel because NAT changes the Layer 3 network address of a packet (and checksum values), whereas the tunneling, used by an IPSec or L2TP VPN gateway, encapsulates/encrypts the Layer 3 network address of a packet with another Layer 3 network address, stripping it off on the other side.

In other words, after a packet goes through the NAT process, it has a different network address. But after a packet goes through the IPSec or L2TP VPN tunneling process, it has the same network address. This concept is invaluable when setting up and troubleshooting NAT and VPN together.

As I said, choosing PPTP can often eliminate the NAT-VPN issues created with IPSec and/or L2TP. However, if you are trying to create a tunnel through the Internet between two Cisco routers (or other non-Microsoft devices or operating systems), you will likely be using IPSec. If you are using IPSec with NAT on a Cisco router, you can get around the VPN-NAT issues by selecting the traffic that is to be NATed and making sure that that traffic is not NATed but encapsulated and encrypted in the IPSec header.

In other words, you want the traffic bound for true Internet destinations to be NATed, and you want the traffic destined to travel through the IPSec tunnel to be tunneled, not NATed. On Cisco equipment, this is accomplished using an access control list.

Let's return to our original scenario of the troubled network administrator who configures a workstation with a private IP address and tries to use a VPN client to go through a NAT-enabled router. We'll assume that the administrator is using an IPSec-based VPN client (not PPTP). Because this is from a client to a server, this means that the admin is using IPSec in transport mode.

Remember that in transport mode, the IP header is not encrypted but exposed. However, the authentication data is calculated based on the values in the IP header (among other things). When the packets arrive at the NAT router, the IP headers are modified (NATed). Upon arriving at the VPN server, the authentication data in the packet is invalid because the IP header information was modified by NAT. So the VPN server drops the packet, and the VPN client never gets connected.

To deal with this issue, VPN product vendors are beginning to build IPSec NAT traversal capabilities into their products. Different standards and vendor implementations are being used to make this work. Most rely on some kind of IPSec encapsulation into UDP packets. Because the IPSec packet is now encapsulated, NAT devices do not affect the packet’s IP header information, and the IPSec authentication data is still valid. Thus, a connection can be made.

Introduction

The first time I have dealt with a case where I had to pass IPSec traffic through a NAT device -a firewall-, and learned the difficulties, I thought that this is such a weird setup that I would never met another one. I was wrong. After meeting two more customers, all with reasonable reasons for such a setup, I decided this topic deserves more attention.

Network Address Translation (NAT) proposed a nice solution to the tight IPv4 address space by allowing use of unregistered IP addresses within the organization. Since it hides the local IP addresses from the outer world, only a small number of registered IP addresses would be enough. This means economy. Besides, NAT adds another security level by preventing access to the local hosts unless you explicitly allow it. Using NAT, when you change your ISP, you never have to renumber your hosts. NAT may also be a good method to translate between IPv4 and IPv6 addresses in the future.

IPSec, on the other hand, is the most widely used VPN standard and being part of IPv6, it will be so in the future. Everyday, more and more companies deploy IPSec to transfer their private information in a secure manner through Internet.

It's a pity but these two very important tools are hard to use together; because of their nature… Now a new approach called NAT Traversal offers a nice solution to the problem.

The de-facto Internet standard Internet Protocol (IP) is not secure. The reason is simple: in the early times of the Internet, the need for security was much less. All types of business conducted through Internet, raised the requirement for a secure protocol. IP Security Working Group of IETF has been working on IPSec (IP Security) protocols to protect the IP traffic on the packet level. The development for IPSec was part of the development efforts for IPv6, but since transition to IPv6 was slow and the need for secure IP communications were increasing, IPSec is modified to support IPv4.

IPSec provides 4 mandatory features for a secure data communication: confidentiality, integrity, authentication and non-repudiation. This is acquired by applying cryptographic algorithms on the IP packet. It employs well-known algorithms like Diffie-Hellman, DES, 3DES, MD5, SHA1, to perform required transformations on the packet. The flexible design of the IPSec architecture allows use of newly developed algorithms and standards without making changes in the protocol.

There are two main transformations that is applied to an IP packet: AH (Authentication Header) and ESP (Encapsulating Security Payload). AH inserts a header into the IP packet including a cryptographic checksum of the packet’s contents. AH is used only to authenticate the IP packet, and no change is applied to the payload. ESP is used for encrypting the packet payload as well as authenticating it. ESP also inserts a header into the IP packet. AH and ESP could be used together or separately, but using both of them simultaneously increases the overhead without providing a significant gain. But when confidentiality is not a concern, then AH could be used alone.

IPSec can process an IP packet in two different ways: Transport and Tunnel Modes. Transport Mode is used for direct Host-to-Host VPN’s, where Tunnel mode is used for Host-to-Gateway or Gateway-to-Gateway VPN’s. Transport and Tunnel Mode differ in the way they encapsulate the IP packet.

In Transport mode, only the Transport layer of the IP packet is transformed. This transformation means authentication or encryption, or both. When AH is used in Transport mode the whole packet is authenticated but nothing is done to provide confidentiality.

In Tunnel Mode, the whole packet is processed including the IP header. Original IP source and destination addresses and other header components are protected by AH or ESP, and a new IP header is inserted into the packet. The new IP source and destination addresses typically are those of the gateways. Based on the transformation method used, (AH or ESP), the whole packet is either authenticated, encrypted or both.

One important part of IPSec is key management process. In order to establish a secure communication channel between IPSec peers, keys should be exchanged in a secure way. There are two main ways to accomplish this: manual key exchange and IKE (Internet Key Exchange). Manual key exchange involves manually typed parameters, which makes life easier for a few peers, but management gets harder as the number of IPSec points increased. IKE is a widely used standard for scalable VPN architectures. IKE provides an automated way to negotiate and establish SA’s (Security Associations), which contain parameters like encryption and hash algorithms, keys, and encapsulation methods. IKE also enables communicating parties to verify the identities of each other; and to exchange keys. IKE communicates over UDP port 500.

IKE negotiation takes place in two phases: Phase 1 and Phase 2. Phase 1 is the initial negotiation and an SA is established for IKE, so that the peers agree on a common ground for securely exchanging IKE data. In phase 2, another SA is established for IPSec communication. Phase 1 can employ one of the two modes: Main mode or Aggressive mode. In main mode besides all of the other parameter exchange, the identities of the peers are verified. In aggressive mode the identities are not verified, which makes it a faster method. Phase 2 is accomplished using Quick Mode.

Network Address Translation is basically a conversion applied to the source and destination IP addresses of an IP packet. Generally registered -or routable- IP addresses are replaced by unregistered IP addresses and vice versa. The reason is obvious: the scarce IPv4 space. NAT is generally implemented on gateway devices like routers, broadband routers, firewalls and the like. Thus a whole private network with unregistered IP addresses can access to Internet since the source IP addresses of the outbound packets are replaced by the NAT device with a registered address, such that the modified packets can be routed properly. Similarly, the destination IP address of inbound packets is replaced by the address of the ultimate destination.

There are 2 main types of NAT: Static NAT, and Port Address Translation (PAT). The latter is sometimes referred as Network Address Port Translation (NAPT). Static NAT is simple one-to-one conversion, where each unregistered IP address is mapped to a registered IP address. NAPT provides a mapping from multiple IP addresses to a single registered IP address. The source port of the outgoing packet is mapped dynamically to an available value. Thus a whole network is hidden behind a single IP address. Some vendors also employ a third method called Pooled NAT. In this method the internal IP addresses are mapped to an allocated pool IP addresses. NAT device keeps a translation table where it records the source IP address and the source port of an outbound packet. Then it replaces these with the new ones, and these values are also recorded. The return packet is compared to this table to find the matching entry, and the destination IP address and port number is replaced accordingly.

Remember that one of the main objectives of IPSec is to protect an IP packet’s INTEGRITY. This means that IPSec tries to prevent any modifications to the packet. Remember how NAT works: It modifies the IP header! When do you face such a setup? Many times: When you are a traveling employee, and you want to reach your Enterprise network through VPN, with your notebook attached to one of your customer’s network. Or when you are a telecommuter trying to reach your corporate servers from behind an ISDN router with NAT enabled.

Either in Transport or in Tunnel mode, AH authenticates the whole IP datagram. Contrary to ESP authentication, AH also authenticates the IP header that precedes itself. When NAT modifies the IP header, IPSec evaluates this as a violation of integrity and discards the packet. Thus AH and IPSec can never work together. Then we are left with two possibilities: ESP in Transport mode or ESP in Tunnel mode.

ESP in Transport mode protects the TCP/UDP header, but does not care about the source and destination IP addresses. Thus, modification of the IP address does not violate the integrity check. But if the packet is a TCP or UDP packet, NAT should modify the checksum that is protected by ESP, which in turn causes the integrity check to fail.

This leaves us with only one working solution: ESP in Tunnel mode. But there may be other problems regarding IKE. If you are using IKE in Main Mode, and if IKE authentication employs pre-shared keys, then you are in trouble. Since Main Mode requires peer authentication, and pre-shared key IKE authentication includes the host IP addresses, a NAT device in the middle would cause IKE authentication to fail.

There may be some workarounds and interim solutions for the problem, but we will discuss the most promising solution: NAT Traversal.

NAT Traversal is a draft proposed to IETF by two different groups. One is prepared by SSH Communications, and the other is a result of a joint workshop of vendors like F-Secure, Microsoft, Cisco and Nortel. Two proposals are merged to form a single standard after a meeting in March 2001, since they had many common points. Although this is a new concept, major VPN vendors started using NAT Traversal in their products.

NAT Traversal is designed as a simple solution, which does not require any changes in the middle devices and existing protocols. Only requirement is the support for NAT Traversal at the edge devices. It also provides an automated way to accomplish NAT Traversal procedures, which minimizes the user intervention. The first step of NAT Traversal operation is determining whether the communicating parties support NAT Traversal or not. This is done in the first phase of IKE negotiation, by sending a special vendor ID string (MD5 hash of “draft-ietf-ipsec-nat-t-ike-00” - [“4485152d 18b6bbcd 0be8a846 9579ddcc”]) to the other side. Successful exchange of vendor strings indicates that both sides support NAT Traversal.

Upon verifying both parties support NAT Traversal, the second step is to discover if there is a NAT device in between. NAT discovery is also used to discover which peer is behind NAT, so that only that side sends the keep-alive messages. NAT discovery is a procedure to determine if the IP addresses or the ports change along the path. To accomplish this both sides calculates and sends the hashes of IP addresses and ports of both the source and destination to each other. Peers compare these values and judges that there is a NAT device on the path if they cannot find a match. These hashes are sent in NAT Discovery (NAT-D) payloads. NAT-D payloads are inserted in the third and forth messages in main mode, and second and third messages in aggressive mode.

When a NAT device is discovered on the path, NAT-T negotiation and decision to use NAT-T takes place in quick mode. NAT-T negotiation decides what encapsulation mode is going to be used for NAT-T. These are UDP-Encapsulated-Tunnel and UDP-Encapsulated-Transport to replace normal tunnel and transport modes. Peers also send their original IP addresses if needed. In transport mode, peers should send their original IP addresses and ports whereas in tunnel mode peers should not, since they are included in the ESP payload. AH is supported in the draft because of the requirements of the standards but it is not expected to be implemented.

If there is a NAT device on the path, something must be done to pass IPSec traffic through this device. This is the heart of the solution: the IPSec traffic between the hosts is encapsulated in UDP using the IKE port. Thus the encapsulated packets follow the same route as IKE packets. This avoids further modifications in the firewalls and assures that the NAT device modifies the NAT-T (NAT Traversal) packets, the same way it modifies the IKE packets.

Encapsulating is done by inserting a UDP header right after the “minimal” IPv4 header, which contains the source and the perceived destination IP addresses. UDP source port is 500 (IKE port). This UDP header overwrites the 8 bites of IKE-initiator-cookie-field by all zeros, which is not allowed normally. This provides the ability to differentiate normal IKE traffic and NAT-T traffic. Original IP header length and protocol type is stored in NAT-T header. Finally the IP Header length is set to 20 bytes and the protocol is set to UDP.

Decapsulation is done the reverse way, and it takes place before further processing. The incoming packet is checked to see whether it is a NAT-T packet or not. This is done by looking for the following conditions: protocol type is UDP, destination port is IKE (500) and IKE-initiator-cookie field is all zeros. The IP ports of the incoming packet is compared to the IKE/IPSec data to find a match, in order to confirm that this packet is part of a previously negotiated SA. The IP addresses are replaced by that of the IPSec peers, other IP header information is extracted from the NAT-T headers, and the UDP and NAT-T information is removed from the packet.

Since NAT devices can clear port assignments after a period of inactivity, a still open NAT-T session may be broken. The reason is obvious. When a new packet arrives after a certain period of inactivity, NAT device may assign a new dynamic source port for the packet, which cause the check in decapsulation phase fail. To avoid such a problem, keep alive packets should be sent from the peer, which is behind the NAT device. In SSH Communication’s proposal the period for keep alive packets is 9 seconds. If no keep alive packet is received from the corresponding peer for a certain period of time, the SA is killed prematurely. The keep alive packet’s payload is of no importance.

Of course all of these does have an overhead. This is about 200 bytes for the Phase 1 IKE negotiation and 20 bytes for each packet. The processing time can also be an issue. In addition to these, there is the overhead of the timeout packets, which is sent every 9 seconds. But as compared to the simplicity and functionality NAT-T provides, this overhead may be regarded as negligible, or at least as tolerable unless the network is too slow.

Another issue needs resolution: Since the unregistered IP addresses are used in the local networks, there is a possibility that a server has two clients with the same IP addresses, from two distant networks. This may cause a problem since the clients are mapped based on IP address, port and protocol. In the Internet Draft, Built-in-NAT is offered as a solution to the problem. This technique relies on another NAT conversion, which is applied to the incoming packet after IPSec process. The configuration may need careful network redesign though.

There may be some security issues with the solution. NAT-T negotiation does not authenticate hosts and is open to everybody. It may also leave the IPSec server prone to DoS attacks since one host can start negotiation from 65535 ports, which may easily overflow the server. Finally an attacker can achieve internal IP address information since the hashes of the IP addresses are negotiated and since it is not a significant job to scan the whole address range.

NAT-T cannot cope with protocols like FTP, and LDAP. These and some other protocols include IP addresses of the peers embedded in the application level of the packet. Normally this part of the payload is encrypted and there is no way that NAT-T modifies the contents. Precautions should be taken to avoid these type of problems.

This relationship can be pretty confusing because there are more than a couple of “gotchas” hiding in amongst the acronyms. The two main gotchas are that the two main IPSec protocols have issues with most technologies that attempt to modify fields in the layer 3 and layer 4 headers. Specifically, Authentication Header (AH) doesn't work with Network Address Translation (NAT) or Port Address Translation (PAT) and that Encapsulating Security Payload (ESP) is also incompatible with PAT. Although some workarounds were discussed in the last tip about transparent tunneling, some readers may be interested in more information about why it's broken in the first place.

To understand this, it's helpful to begin by recognizing that AH's goal is to ensure that packets arrive at their destination exactly the same as they left and it uses a checksum to accomplish this. It is important to note that this checksum is applied to the entire packet, including IP headers.

Although NAT isn't the malicious attacker that AH was designed to thwart, it remains largely thwarted. As packets travel through a NAT process, NAT changes the IP address in the source or destination field and sends the packet on its way. When it arrives, the checksum is calculated on the packet by AH again, and of course, it doesn't match the existing one that was sent with the packet. Thus, the packet is rejected.

ESP's goal is quite different, and actually much more common. ESP encrypts the data in the packet so that it cannot easily be viewed as it crosses the network. Encrypting the IP headers isn't practical, because if they were encrypted, no router in the network would be able to tell where the packet was coming from or going to. Thus, ESP headers are inserted between the layer 3 and 4 headers and only the payload of the IP packet (which includes the TCP or UDP headers, if applicable) are encrypted.

This means that if NAT fudges an IP address, it's really no big deal, because unlike AH, there's no checksum guarding the IP headers. However, if an encrypted packet travels through a PAT process, not only the IP address is changed, but also the TCP or UDP port numbers. These, unfortunately, are encrypted. The PAT process can't see them or change them. In fact, it doesn't even recognize that TCP or UDP are in use because the IP protocol field will be listed as Protocol 50, which is ESP, instead of 6 or 17, which are TCP and UDP respectively.

— David Gonzalez 2021/03/30 14:50