SRX

what's the order of processing when policy based vpn and nat are implemented on a srx. which happens first ? I guess source nat happens first and then the ipsec, but am not 100 % sure 😞

Hi

Correct, S-NAT is done before IPSec encapsulation (and the same with D-NAT, AFAIK).

In order to have NAT and IPSEC VPN work together, you need route-based VPNs. Otherwise, the NAT and IPSEC proxy ids will get into an awful battle that neither will win. 🙂

Thanks tbehrens

I would agree with tbehrens that NAT is more adequate with route-based VPN (especially static NAT).

However S-NAT + Policy-based VPN will work. And because S-NAT is done after policy lookup in the first path of traffic flow, you are not going to have problems with proxy-id (at least in the simplest case with symmetric policies on both sides of VPN).

even with the route-based vpn's i am having to do a "source-nat off" under security nat. How does route-based vpn help when nat is configured on the srx ?

any documentation available on this ?

Hi

I know it's an old thread but hopefully it'll help someone else

The link below shows the sequence of nat processing

http://www.fir3net.com/Juniper-SRX-Series-Gateway/juniper-srx-nat.html

Now, to understand it clearly lets take a look at a sample code

[edit security nat destination]

destination {
pool pool-dst-nat {
address 5.5.5.5/32;
}
rule-set DST-NAT-RULE-SET {
from zone trust;  -----> note that this is from trust and not from untrust
rule rule1-dst-nat {
match {
destination-address 172.16.130.150/32;
}
then {
destination-nat pool pool-dst-nat;
}
}
}

So using above rule we are changing the dst of outgoing packet (Not that we will actually have to use it in a live environment but this is set up in a lab to illustrate a point)

[edit security nat source rule-set rs1]
sadm@SRX240# show
from zone trust;
to zone untrust;
rule 2 {
match {
source-address 172.19.22.50/32;
destination-address 5.5.5.5/32;---> note that I am using 5.5.5.5 and not 172.16.130.150 since at this point dst-nat has already happened
}
then {
source-nat {
off;
}
}
}
rule r1 {
match {
source-address 172.19.22.50/32;
}
then {
source-nat {
pool {
nat-pool;
}
}
}
}

Now when host behind this SRX (172.19.22.50) wants to initiate traffic over vpn, it'll try and ping 172.16.130.150(host across the tunnel)

As shown in the link above, dst nat will be the first step (since we aren't doing static nat). dst-nat will change the dst from 172.16.130.150 to 5.5.5.5. Route/zone lookup will happen followed by policy lookup.

Note that dst nat has happened already before policy lookup. So in the policy that you are defining you'll have to define it with 5.5.5.5 as dst address instead of 172.16.130.150 as dst

[edit security policies from-zone trust to-zone untrust]

policy outbound-11 {
match {
source-address internal_host; ---->172.19.22.50
destination-address remote-host;---->5.5.5.5
application any;
}
then {
permit {
tunnel {
ipsec-vpn IPSEC-Tunnel-To-Peer;
}
}
log {
session-init;
session-close;
}
}

Hope that helps

-Rohan