VPN - SNAT and Interesting traffic

[Juan_]

Hi Checkmates!


Setting up a S2S vpn I've run into the following curious situation.

A VPN required me to hide the Lan behind a public IP on our range;

So I set up the VPN and instead of using the local gateway's encryption domain I select user-defined, and create a group with just the public IP that will be my local encryption domain.


I check all my settings, access rules, nat rules, and after being sure i start generating traffic.

But the traffic never matches the VPN ruleo, it goes straight to clean-up.

Meaning of this I assume is that the gateway is not considering the traffic as interesting for the VPN.

 I change the encryption domain on the community back to the local gateway (which also includes the Net Range of the LAN) and the rule starts matching and VPN forms.

My question(s) are: 

Does the match for interesting traffic on VPN occur pre-nat?

Could be a bug with user-defined enc-dom?


Using R80.40 JHF120.

Juan
Thanks!

[Bob_Zimmerman]

NAT with VPNs is complicated. This happens because the Encryption Domain of a firewall is used for two things which are related, but subtly different.

First, when the firewall receives traffic, before it processes firewall rules or NAT rules, it checks the source to see if it's in an encryption domain and the destination to see if it's in an encryption domain. If so, and if the endpoints with those encryption domains share a VPN community, this is used to flag the traffic as "interesting" for the VPN between them.

Second, when the traffic is about to be encrypted (after access rules, routing and all NAT!), the VPN community is used to pick the exact IDs which will be sent in the IPSec negotiation. If you translate a single IP address, but the encryption domain contains a /28 network covering that IP, the /28 network will be proposed rather than the single IP.

This is expected behavior, and a side-effect of consulting the encryption domain for different purposes at different times relative to NAT and rule decisions. You need to include the untranslated addresses for the matching logic, and the translated addresses for the negotiation logic.

[Juan_]

Thanks for the explanation.

I think it makes sense. 

The only weird thing: vpn started matching and IDs negotiated WITHOUT the translated address being in the encryption domain at all! That puzzled me.

I added it after realizing it wasn't there but the VPN was working anyway. 🙂