Table of Contents
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.
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.
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.
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.
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.
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.
- How to Configure a BIND Server on Ubuntu - March 15, 2018
- What is a BGP Confederation? - March 6, 2018
- Cisco – What is BGP ORF (Outbound Route Filtering)? - March 5, 2018
Want to become an IT Security expert?
Here is our hand-picked selection of the best courses you can find online:
Internet Security Deep Dive course
Complete Cyber Security Course – Hackers Exposed
CompTIA Security+ (SY0-601) Certification Complete course
and our recommended certification practice exams:
AlphaPrep Practice Tests - Free Trial