NAT and encryption domain

[Teddy_Brewski]

Hello,

I have a question about NAT and encryption domain.  My setup is as per below:

There is a VPN tunnel between FW_EXTERNAL and EXTERNAL.  192.168.0.1 is in the encryption domain and it accesses 172.26.0.1.  I also perform NAT and translate the source to 10.20.20.1.  Everything works fine.

Now I'd like to allow 10.10.10.1 to access 172.26.0.1.  Is there any way to achieve that without adding 10.10.10.1 in the encryption domain on FW_EXTERNAL?

Thank you.

[Gareth_somers]

As far as I'm aware, the firewall needs to tag the packets for encryption and this is based on the real IP (pre-NAT), then to actually route it in the tunnel, the NATed IP should be defined. So you need both the real and the NATed IPs in your encryption domain. 

So short of NATing the source on FW_Internal, you will need to add the real to the encryption domain on FW_External. R80.40+ allows you to specify Encryption domains per VPN community (not just RA) if you're worried about overlap.

[RamGuy239]

This is mostly a result of how Check Point handles domain-based VPN. The VPN routing logic is basing itself on the encryption domains. NAT is happening later in the firewall chain so the packets being tagged for VPN routing has already been taking place.

But if you happen to utilise VTI instead of domain-based routing the negotiated encryption domain doesn't take any part in the actual VPN routing. 0.0.0.0/0 will be used as the encryption domain and whatever traffic you are routing through the virtual interface (VTI) determine what is going to be sent over the VPN tunnel so this should make it possible without having to deal with the encryption domains.

But setting up VTI on Check Point is rather different and less normal than configuring domain-based VPN so this will most likely just become more confusing compared to simply adding the address to the encryption domain.

[PhoneBoy]

The Encryption Domain must include everything that needs to talk on the VPN.
That obviously has implications when negotiating a VPN with a third party.
See: https://community.checkpoint.com/t5/Security-Gateways/NAT-Before-VPN/m-p/122828#M17586 

[the_rock]

I agree with phoneboy as well...I am pretty sure vpn domain must include 10.10.10.1 IP. I dont know, maybe there is some convoluted way of doing this otherwise, but Im not aware of it if it has to go through VPN tunnel.

[PhoneBoy]

That point was proven out in the thread I linked to. 🙂

[johnnyringo]

I just ran in to this yesterday.  We're doing NAT for both incoming and outbound traffic on a policy-based VPN (aka "one tunnel per subnet" in CheckPoint speak) and found the VPN needed to include the NAT IPs for incoming traffic but true IPs for outgoing.  This is consistent with how firewall rules must be configured, but counter-intuitive because you'd think the CheckPoint would NAT the traffic first prior to encrypting it to be send across the tunnel.  

I've yet to find an official CheckPoint document that explains this requirement.  With other vendors (Cisco, Palo Alto, etc) there is no such requirement to have the true IP address in the encryption domain.  

[PhoneBoy]

We need to know what traffic is "interesting" as far as encryption goes, particularly when using domain-based VPNs (versus route-based).
This is done by way of defining the encryption domain to include the real IPs. 
In a route-based VPN, this isn't necessary, since traffic will only be "interesting" if it is routed out the relevant VTI. 

[johnnyringo]

Well, that still doesn't explain the requirement, because the SAs (traffic selectors / crypto maps / proxy ids / whatever you want to call them) get built using the NAT IP addresses.   This is what shows up when running vpn tu tlist on the gateway.  

Thus, the "interesting" traffic has already been defined.  

[PhoneBoy]

Yes, but the decision to encrypt or not is made before SAs are negotiated.