Description

VPN is up, but traffic is not passing successfully over the tunnel when source NAT rules exist.

Symptoms

Traffic is not passing successfully over a VPN when a source NAT rule exists. Flow session output indicates that the SRX is setting up sessions and passing traffic, but the traffic is not returning.


Scenario: The client PC 192.168.2.10 in Sunnyvale is trying to reach 192.168.3.10 in New York across a VPN tunnel, but is unsuccessful.

alt
 

Solution

Verification:

Step 1.   Display the session, and confirm that NAT is being performed.  For example:

CLI:

root@Sunnyvale>show security flow session source-prefix 192.168.2.10

Session ID: 23692, Policy name: vpn-to-peer/7, Timeout: 20, Valid
In: 192.168.2.10/57950 --> 192.168.3.10/22;tcp, If: st0.0, Pkts: 1, Bytes: 64
Out: 192.168.3.10/22 --> 100.1.1.2/45127;tcp, If: ge-0/0/1.0, Pkts: 0, Bytes: 0
 J-Web :
 Navigate to Monitor > Security > Flow Session .
 Click on Application "ssh", Protocol "tcp" from the list.
 Enter Source IP/Prefix (example: 192.168.2.10) and Dest IP/Prefix (example: 192.168.3.10). Then click on Search .


In the output above:
The In : wing of the session indicates the session originated from 192.168.2.10 with destination as 192.168.3.10.
The Out : wing of the session indicates the expected reply traffic originating from 192.168.3.10.

Note that the destination address in the Out wing is 100.1.1.2 and not 192.168.2.10. The destination port is also not the original source port used by 192.168.2.10.
This output indicates that source-NAT with port translation is being applied because the destination IP address of the reply is not that of the source host.


Step 2.   Confirm the zones used in the security policy (specified in the flow session output) are correct. 

root@Sunnyvale# show security policies | display set| match vpn_to_peer
set security policies from-zone trust to-zone untrust policy vpn_to_peer match source-address local_net
set security policies from-zone trust to-zone untrust policy vpn_to_peer match destination-address remote_net
set security policies from-zone trust to-zone untrust policy vpn_to_peer match application any
set security policies from-zone trust to-zone untrust policy vpn_to_peer then permit tunnel ipsec-vpn CORP_VPN

The policy name in the security flow session output in Step 1 is 'vpn_to_peer'.  The above command output shows that zones trust and untrust are configured in the 'vpn_to_peer' security policy.


Step 3. Confirm the IP addresses used in the address-objects of the security policy (displayed in Step 2) are correct.

root@Sunnyvale# show security zones | display set | match local_net
set security zones security-zone trust address-book address local_net 192.168.2.0/24

root@Sunnyvale# show security zones | display set | match remote_net
set security zones security-zone untrust address-book address remote_net 192.168.3.0/24
 

Step 4.   Review the source NAT rules for the zones and IP addresses found in Step 2 and Step 3. 
root@Sunnyvale# show security nat
source {
    rule-set trust-to-untrust {
        from zone trust;
        to zone untrust;
        rule source-nat-rule {
            match {
                source-address 0.0.0.0/0;
            }
            then {
                source-nat {
                    interface;
                }
            }
        }
    }
}
The VPN traffic is being source NAT'd because the rule specifies a match of all (0.0.0.0/0) source addresses.
 

Fix: 

In this scenario, we don't want the VPN traffic to match the source NAT rule.  One way to correct this is to create a new NAT rule to disable NAT usage for traffic to be set into the VPN:
 
root@Sunnyvale# set security nat source rule-set trust-to-untrust rule no_nat match destination-address 192.168.3.0/24
root@Sunnyvale# set security nat source rule-set trust-to-untrust rule no_nat then source-nat off
root@Sunnyvale# insert security nat source rule-set trust-to-untrust rule no_nat before rule source-nat-rule
root@Sunnyvale# commit

root@Sunnyvale# show security nat
source {
    rule-set trust-to-untrust {
        from zone trust;
        to zone untrust;
        rule no_nat {
            match {
                destination-address 192.168.3.0/24;
            }
            then {
                source-nat {
                    off;
                }
            }
        }
        rule source-nat-rule {
            match {
               source-address 0.0.0.0/0;
            }
            then {
                source-nat {
                    interface;
                }
            }
        }
    }
}
  
 

Modification History

2020-03-26: Article reviewed for accuracy; it is valid and accurate