Overcoming NAT Related Issues

NAT related issues arise with hide NAT devices that do not support packet fragmentation.

When a remote access client attempts to create a VPN tunnel with its peer Security GatewayClosed Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources., the IKE or IPsec packets may be larger than the Maximum Transmission Unit (MTU) value. If the resulting packets are greater than the MTU, the packets are fragmented at the Data Link layer of the Operating System's TCP/IP stack.

Problems arise when the remote access client is behind a hide NAT device that does not support this kind of packet fragmentation:






Security Gateway






Remote Client

Hide NAT not only changes the IP header but also the port information contained in the UDP header. For example, if the UDP packet is too long, the remote client fragments the packet. The first fragment consists of the IP header plus the UDP header and some portion of the data. The second fragment consists of only the IP header and the second data fragment. The NATing device does not know how to wait for all the fragments, reassemble and NAT them.

When the first fragment arrives, the NAT device successfully translates the address information in the IP header, and port information in the UDP header and forwards the packet. When the second fragment arrives, the NATing device cannot translate the port information because the second packet does not contain a UDP header; the packet is dropped. The IKE negotiation fails.

During IKE phase I

To understand why large UDP packets arise, we need to take a closer look at the first phase of IKE. During IKE phase I, the remote access client and Security Gateway attempt to authenticate each other. One way of authenticating is through the use of certificates. If the certificate or Certificate Revocation List (CRL) is long, large UDP packets result, which are then fragmented by the operating system of the remote client.

Note - If the VPN peers authenticate each other using pre-shared secrets, large UDP packets are not created; however, certificates are more secure, and thus recommended.


IKE over TCP solves the problem of large UDP packets created during IKE phase I. The IKE negotiation is performed using TCP packets. TCP packets are not fragmented; in the IP header of a TCP packet, the DF flag ("do not fragment") is turned on. A full TCP session is opened between the peers for the IKE negotiation during phase I.

During IKE phase II

A remote access client does not have a policy regarding methods of encryption and integrity. Remote access clients negotiate methods for encryption and integrity via a series of proposals, and need to negotiate all possible combinations with the Security Gateway. This can lead to large UDP packets which are once again fragmented by the remote client's OS before sending. The NAT device in front of the remote client drops the packet that has no UDP header (containing port information). Again, the IKE negotiation fails.

Why not use IKE over TCP again, as in phase I?

IKE over TCP solves the fragmentation problem of long packets, but in phase II there are times when the Security Gateway needs to initiate the connection to the remote client. (Only the remote client initiates phase I, but either side can identify the need for a phase II renewal of keys; if the Security Gateway identifies the need, the Security Gateway initiates the connection.)

If the Security Gateway initiates the connection, the Security Gateway knows the IP address of the NATing device, but cannot supply a port number that translates to the remote client behind the NATing device. (The port number used during previous connections is only temporary, and can quickly change.) The NATing device cannot forward the connection correctly for the remote client; the connection initiated by the Security Gateway fails.

It is possible to use IKE over TCP, but this demands a TCP connection to be always open; the open session reserves the socket on the Security Gateway, taking up valuable system resources. The more reasonable solution is to keep open the port on the NATing device by sending UDP "keep alive" packets to the Security Gateway, and then performing IKE phase II in the usual way. However, there is still a need to shorten the UDP packets to prevent possible fragmentation.

Small IKE Phase II Proposals

Both Security Gateway and remote peer start the IKE negotiation by proposing a small number of methods for encryption and integrity. The more common methods are included in the small proposals.

If proposals match between the remote client and the Security Gateway, the proposed methods are used; if no match is found, a greater number of proposals are made. Usually a match is found with the small proposals, and fragmentation is no longer an issue. However, there are cases where a match is not found, and a larger number of proposals need to be made. (This will most likely happen in instances where the remote Security Gateway uses AES-128 for encryption, and AES-128 is not included in the small proposals.)

A greater number of proposals can result in larger UDP packets. These larger packets are once again fragmented at the Data Link Layer of the TCP/IP stack on the client, and then discarded by the hide NAT device that does not support fragmentation. In the case of AES-128, this method of encryption can be included in the small proposals by defining AES-128 as the preferred method.

During IPsec

NAT Traversal (UDP Encapsulation for Firewalls and Proxies)

Having successfully negotiated IKE phases I and II, we move into the IPsec stage. Data payloads encrypted with AES and SHA, for example, are placed within an IPsec packet. However, this IPsec packet no longer contains a TCP or UDP header. A hide NAT device needs to translate the port information inside the header. The TCP/UDP header has been encrypted along with the data payload and can no longer be read by the NATing device.

A port number needs to be added. UDP Encapsulation is a process that adds a special UDP header that contains readable port information to the IPsec packet.

IPsec Path Maximum Transmission Units

IPsec Path MTU is a way of dealing with IPsec packet fragmentation. The Data Link layer imposes an upper limit on the size of the packets that can be sent across the physical network, the Maximum Transmission Unit, or MTU. Before sending a packet, the TCP/IP stack of the operating system queries the local interface to obtain its MTU. The IP layer of the TCP/IP stack compares the MTU of the local interface with the size of the packet and fragments the packet if necessary.

When a remote client is communicating across multiple routers with a Security Gateway, it is the smallest MTU of all the routers that is important; this is the path MTU (PMTU), and for remote access clients there is a special IPsec PMTU discovery mechanism to prevent the OS of the client from fragmenting the IPsec packet if the IPsec packet is too large.

However, the PMTU between the remote client and the Security Gateway will not remain constant, since routing across the Internet is dynamic. The route from Security Gateway to client may not be the same in both directions, hence each direction may have its own PMTU. VPN handles this in two ways:

  • Active IPsec PMTU

  • Passive IPsec PMTU

Active IPsec PMTU

After IKE phase II but before the IPsec stage, the remote access client sends special discovery IPsec packets of various sizes to the Security Gateway. The DF (do not fragment) bit on the packet is set. If a packet is longer than any router's MTU, the router drops the packet and sends an ICMP error message to the remote client. From the largest packet not fragmented, the remote client resolves an appropriate PMTU. This PMTU is not conveyed directly to the OS. Unknown to the operating system, during the TCP three-way handshake, the Maximum Segment Size (MSS) on the SYN and SYN-ACK packets are changed to reflect the PMTU. This is known as Active IPsec PMTU.

Passive IPsec PMTU

Passive IPsec PMTU solves the problem of dynamic Internet routing. Passive IPsec PTMU is a process that occurs when either side receives an ICMP error message resulting from a change in the routing path. Since routes change dynamically on the Internet, if a different router needs to fragment the packet that has the DF bit set, the router discards the packet and generates an ICMP "cannot fragment" error message. The error message is sent to the VPN peer that sent the packet. When the peer receives this error message, the peer decreases the PMTU and retransmits.

Note - From the system administrator perspective, there is nothing to configure for PMTU; the IPsec PMTU discovery mechanism, both active and passive, runs automatically.

NAT and Back Connections from Security Gateway to Client

In the following figure, the remote client is behind a NATing device and connecting to a Security Gateway or clusterClosed Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing.:






Internal Switch


Security Gateway or cluster


External Switch




NATing Device


Remote Access client

This is also true if the NATing is performed on the Security Gateway side.

Usually to communicate with hosts behind a Security Gateway, remote access VPN client must initialize a connection to the VPN Security Gateway. However, once a remote access VPN client has opened a connection, the hosts behind the VPN Security Gateway can open a return or back connection to the remote access VPN client. For a back connection to succeed, the remote access client's details must be maintained on all the devices between the remote access VPN client and the VPN Security Gateway, and on the VPN Security Gateway itself.

  1. In SmartConsoleClosed Check Point GUI application used to manage a Check Point environment - configure Security Policies, configure devices, monitor products and events, install updates, and so on., click Menu > Global properties.

  2. Select the Remote Access page.

  3. Click Remote Access > In the Additional Properties section, select Enable Back Connections (from gateway to client).

  4. Click OK.

  5. Install the Access Control Policy on the VPN Security Gateway.