Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Teddy_Brewski
Contributor

NAT and encryption domain

Hello,

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

fwCapture.PNG

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.

0 Kudos
9 Replies
Gareth_somers
Contributor

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.

0 Kudos
RamGuy239
Advisor
Advisor

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.

Certifications: CCSA, CCSE, CCSM, CCSM ELITE, CCTA, CCTE, CCVS, CCME
0 Kudos
PhoneBoy
Admin
Admin

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 

0 Kudos
the_rock
Legend
Legend

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.

0 Kudos
PhoneBoy
Admin
Admin

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

0 Kudos
johnnyringo
Advisor

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.  

0 Kudos
PhoneBoy
Admin
Admin

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. 

0 Kudos
johnnyringo
Advisor

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.  

0 Kudos
PhoneBoy
Admin
Admin

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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Wed 01 May 2024 @ 02:00 PM (EDT)

    South US: HTTPS Inspection Best Practices

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Wed 01 May 2024 @ 02:00 PM (EDT)

    South US: HTTPS Inspection Best Practices

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82
    CheckMates Events