topic Re: Understanding about NAT and VPN in Firewall and Security Management

Understanding about NAT and VPN

anaiyar — Fri, 22 Dec 2023 13:00:27 GMT

Guys,

I have a complicated situation and I needed to understand the concept. I will try to explain the scenario in the best way I can. So here it is....

We have a VPN between our org and the customer. Our side is checkpoint (vsx) and other end is Cisco ASA.

Taking the customer as source, we are hiding the customer original IP addresses and translating them to addresses routable in our network. So from my understanding and from customer point of view they are simply communicating based on original IP addresses and any translations that are happening are at our end.

So the question is whether we should have the NAT subnets in the customer encryption domain that we have mapped with the other end gateway or not. I just need to understand when the traffic hits with the original IPs and gets decrypted is it post that the translations happen or it happens while decryption process and enters our environment with the translated IP address?

Re: Understanding about NAT and VPN

PhoneBoy — Sat, 23 Dec 2023 00:57:58 GMT

Since you are doing the NAT on your end, I don't believe it is strictly required to do so.

Re: Understanding about NAT and VPN

Bob_Zimmerman — Sat, 23 Dec 2023 20:50:54 GMT

If you are translating the remote addresses and if you need to be able to initiate connections out to the peer, you should have both the real addresses and the translated addresses in the peer object's encryption domain.

The encryption domain is checked at two times: once to determine if the connection should be flagged for encryption in a given VPN community, and once to determine the actual negotiation to send to the peer. NAT happens between these two checks. A connection from a device in your environment to one of the translated addresses needs the translated address in the encryption domain for the traffic to be caught by the VPN community. After it is caught by the community, the address is translated so it now looks like your internal device is talking to their real address. When it is time to negotiate the VPN, it check the destination address, the VPN community's tunnel management setting, and the objects in the remote gateway's encryption domain to pick the identifier information to propose.

If you don't initiate connections to them, then you should only need their real addresses in the encryption domain.

Re: Understanding about NAT and VPN

JozkoMrkvicka — Sun, 24 Dec 2023 07:54:34 GMT

On Cisco you can setup the VPN tunnel as "initiator" or "responder" or "both". Depends what is config on their end and if there will be usecase when Cisco is responder (Check Point will be source of VPN communication).

If Cisco is only initiator, then you dont need to have NAT internal IPs in encryption domain.

If Check Point will be initiator, then NAT internal IPs must be part of local encryption domain AND ALSO on Cisco side as part of remote encryption domain (to match traffic selectors to be 1:1). Cisco has to be also configured not only as Initiator, but also responder (or both).

It is very important to have identical traffic selectors (encryption domains) on both ends.

Re: Understanding about NAT and VPN

the_rock — Sun, 24 Dec 2023 12:49:04 GMT

This is just me, but I would always include both original AND natted IPs in the enc domain. That seems to work fine and its worth saying that TAC most likely would suggest you do the same. As @PhoneBoy said, in your case it might not be necessarily needed, but I find it works best if both are.

Best,

Andy