fir3net
PPS-Firenetbanner-780.5x190-30-03-17

Juniper SRX - The Static NAT / Policy based VPN Problem

Purpose

The purpose of this document is to explain the issues and problems surrounding the use of static NAT when using policy based VPN on a Juniper SRX Firewall.

Background

The issue, when using static NAT with a policy based VPN centres around how NAT is processed by the SRX, in that the Proxy ID`s are created before the NAT is processed, in turn causing Proxy ID mismatches during the Phase 2 process.

NAT Process

The SRX processes static NAT prior to source NAT. Unfortunately within static NAT there is no option to define what networks to which your static NAT should apply to.
Below shows (in more detail) how NAT is processed by the flow module. Here you can see that the Reverse Static NAT is processed prior to source NAT.


 

VPN Methods

With relation to this article the following highlights the main differences between the 2 VPN methods:

  • Route Based VPN - In essence no encryption domain (Proxy ID`s) are defined. Instead a tunnel interface is created (within a new zone), any traffic routed to this interface is subsequently encrypted.
  • Policy Based VPN - The encryption domain (Proxy ID`s) are defined by the policy. The policy references the source and destination zone which is typically Trust and Untrust.

In terms of the policy based VPN, the proxy ID`s are created before the source NAT process.
This means that when a static NAT is in place and a policy VPN is configured at the point that the packet is sent out towards the tunnel the Proxy ID`s will be formed and the packet translated based on the Reverse static NAT. Resulting in traffic with a Local Proxy ID and source IP that mismatch, being sent down the tunnel.

Problem

As we previously mentioned as the reverse static NAT is processed before source NAT, and that there is no NAT exempt in static NAT, traffic is source NAT`d before being sent down the tunnel.

 

 

Based on the fact that the proxy IDs are built from the security policy statements this also means that the Proxy ID`s that are created will be different to what is sent down the VPN tunnel. This results in Proxy ID mismatch errors.

Workaround

In terms of workaround the main method is to split  you static entries. This involves removing the existing static NAT entry and replacing it with a separate source and destination NAT rule. This then allows you to add a NAT rule that NAT exempts traffic when traffic is destined to a the encryption domain.

Tags: VPN, SRX

About the Author

RDonato

R Donato

Rick Donato is the Founder and Chief Editor of Fir3net.com. He currently works as a Principal Network Security Engineer and has a keen interest in automation and the cloud.

You can find Rick on Twitter @f3lix001