Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[ScreenOS] NAT Traversal overview



Article ID: KB4741 KB Last Updated: 10 Oct 2016Version: 10.0

This article provides an overview of NAT Transversal. It is applicable to ScreenOS 5.0 or later. However, NAT-T draft 2 is not supported until ScreenOS 5.1.


Traditionally, IPSec does not work when traversing across a device doing NAT.  To circumvent this problem, NAT-T or NAT Traversal was developed.  NAT-T is an IKE phase 1 algorithm that is used when trying to establish a VPN between two gateways devices where a NAT device exists in front of one of the devices, in this case a Juniper Firewall device.  By enabling this option, IPSec traffic can pass through a NAT device. 

To create a VPN from behind a NAT device, the IPSec gateway behind the NAT device and the gateway in the non-NAT environment must support NAT-T, i.e. both VPN end-points must support NAT-T.     NAT-T IPSec peers first detect if there is a NAT device between them. This is done in the key negotiation process, and it requires additional messages to be sent.

With pre-shared keys, the network behind the NAT device needs to initiate the IPSec negotiations. The responder (non-NAT device), checks if the remote identity matches one of the locally configured interface addresses and IKE UDP port number (responder NAT check). The responder also checks if the local identity matches the source IP address and UDP port in the receiving packet (initiator NAT check). If both of these two conditions are not met, the responder then knows NAT-T is required.

After two IPSec peers agree that NAT-T is needed, IPSec packets between them will be encapsulated by one new and two extra headers such that even if the IP packet on the wire is altered by NAT device(s), there is enough information in the extra headers and SPI to recover the original IPSec packet.

The following shows the original and NAT-T encapsulated IPSec packets :

Original IPsec packet

Original outer IP header ESP header Original inner IP header IP data ESP trailer ESP auth

NAT-T encapsulated IPsec packet

New IP header UDP header NAT-T header ESP header Original inner IP header IP data ESP trailer ESP auth

The new IP header is the same as the original IPSec outer header except the protocol is changed from AH/ESP to UDP.  The UDP header has a source port of  500 and the destination port equals the public IKE port of the peer. This makes the peer think this is an IKE packet.  NAT-T works only if the NAT devices along the route between the two IPSec gateways maintain the same address mapping since the last IKE negotiation.  The keepalive is sent to keep the NAT devices from removing the mapping entries.

Beginning in Screen OS 5.1, NAT-T draft 2 is supported. For more information about NAT-T (v2), refer to KB8119 - What is NAT-T draft 2 and how does the Firewall detect it?"

An overview of NAT Traversal is also discussed in more detail in the Concepts and Examples ScreenOS Reference Guide Volume 5: Virtual Private Networks
Chapter 7 -- Advanced Virtual Private Network Features

For more information, refer to KB8120 - How do I configure support for UDP 4500 (NAT-T Draft 2)?  

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search