This article explains how to configure a Juniper Firewall to allow VPN pass through traffic when interface NAT or source NAT is enabled.
A customer has multiple VPN clients on the Trust side and needs to access a VPN gateway on the Untrust side. The VPN gateway does not understand IPSEC NAT and expects the ESP packets to be sent without port translation.
A user on the inside (Trust) side of a Juniper Firewall has an IPSec VPN Client and needs to establish a VPN to a peer on the public (Untrust) side, but the tunnel is not establishing.
When IPSec traffic passes thru the Juniper Firewall with NAT enabled and no IKE ALG is used, the IKE UDP 500 and ESP packet would be translated. However, this can cause a problem if the peer is an older device; some older devices that does not support NAT-T and they cannot encapsulate the ESP packet in the UDP header and expect the ESP packet information to be sent as is with out any modification. If the source port info in the ESP packet is translated, this causes the peer to not recognize the packet. So, there needs to be a way to allow this IPSec traffic through without translating the port information in the ESP packet.
ScreenOS 5.2 and higher
Starting with version 5.2,ScreenOS has an ALG to allow IPSEC pass thru packets without port translation and without using a MIP (which was the work-around with ScreenOS 5.1 and below).
To enable the IPSEC pass thru without a MIP, use the predefined service "IKE-NAT" in the policy. This will trigger the ALG for IPSEC pass thru and all the IKE packets will be translated to the Untrust IP without the ESP port being translated.
Suppose you have a client on the Trust side which needs to connect to the VPN gateway on the Untrust side. Enable a Trust to Untrust policy with IKE-NAT as the service. Make sure that you position this policy at the top:
set policy from trust to untrust any any IKE-NAT permit set policy from trust to untrust any any ESP permit
Once the SA is established and the traffic is initiated from behind the gateway VPN devices, the ESP pass through tunnel session will be created with the IKE-NAT ALG function. Then all of the corresponding bi-directional ESP packets will be passed by creating a ESP session which eventually uses the ALG ESP session as the parent session as tunnel pass through to pass the ESP traffic. The IKE ALG will only translate the header IP's for the ESP packets and leave the port information intact which are derived from the SPI numbers in there respective directions
As long as the parent ESP session is present, the ESP traffic can be passed from either direction from trust to untrust and vice versa without a ESP policy from untrust to trust. The only way to trigger the ESP parent session is from the trust and untrust side in which direction the IKE-NAT and ESP policies are configured. In the event the parent ESP session is not existing, then the ESP packet from the Untrust side will be dropped as there is no ESP pass through tunnel session existing.
Note that this only works if the source and destination ports are UDP 500 for the IKE packets. If the source or destination is not UDP 500, then the IKE-NAT service will not be matched and the only workaround is to use a MIP as stated below.