Explicit NAT exclusion statements when defining a VPN domain?

[crescentwire]

Hi everyone,

We have two locations--a corporate HQ and a remote datacenter--connected by a private fiber link, presently. We have a pair of 13800s in active/standby ClusterXL mode in the data center. Our policy for the 13800s has various NAT exclusions, keeping the original source address the same as traffic leaves the gateway and heads for other destination networks at the corporate HQ. We have a pair of Cisco ASAs in our corporate HQ, just to keep things interesting  

We will soon be moving to a VPN tunnel between these sites, delivered over the open Internet, and will therefore be defining a VPN domain on each gateway within the VPN community (for us, that will be just the center gateway in the data center and the satellite gateway at the corporate HQ site).

My question is whether or not we need to keep these existing NAT exclusion statements within our NAT policy even if we are defining nearly the same networks within the VPN domain on each gateway object.

I've been using the following SK for help on this: How to set up a Site-to-Site VPN with a 3rd-party remote gateway. The guide doesn't require NAT exclusion statements along with the VPN domains defined, so I'm thinking I do not need them, but I wanted to ask anyone out there who has been through this already. (On a different note, these VPN domains must match between those defined on the Check Point environment and those defined within the Cisco ASAs--otherwise, IKE phase 2 will not establish.)

Any help you can provide is greatly appreciated. Thank you very much in advance.

[Alisson_Lima]

Hello,

Since that you have defined the same networks on both encryption domains, you cannot create a vpn tunnel. I recomended you change the network on in somewhere to avoid overlapping.and a good way for it is creating NAT rules to translate the packet, if isn't possible change the networks.

Could you send me the encryption domain from both sides?

Regards,

Alisson Lima

[crescentwire]

Alisson Lima I think I probably made my explanation more complicated than I meant to ... sorry. The issue isn't that we have RFC1918 network overlap at all (otherwise, your answer would make sense). Let me try to explain again:

Suppose at our corporate HQ office we have the network 10.1.0.0/16 (behind the Cisco ASA), and at the data center, we have 10.2.0.0/16 (behind the Check Point 13800 cluster). Currently, across our private link between these locations, we are NAT-excluding 10.2.0.0/16 as traffic heads to 10.1.0.0/16, as we would expect and desire. (Otherwise, all privately-addressed source traffic from the data center would be NAT'ed to whatever we would have defined.)

With our new/planned VPN tunnel, traffic destined for 10.1.0.0/16 (from 10.2.0.0/16) still needs to be NAT-excluded. What I'm not sure of is how that exclusion happens: does it happen because of the VPN domain networks I assign to each "side" of the VPN community (i.e. the 13800 cluster being the hub gateway and the Cisco ASA, as an interoperable device, being the satellite gateway)? Or, does the NAT exclusion happen within the manual rules I have defined under Policy > NAT? Or still yet, do I need both?

I've never built a site-to-site tunnel between Check Point gateways, let alone to a Cisco ASA as a third-party peer. All I need to know is if the manual NAT entries I have in place (without a VPN tunnel) need to remain for NAT exclusion to work over a VPN tunnel, or if I can remove them and instead rely on the NAT exclusion that (I think?) occurs as a result of the VPN domain-defined group of networks within the gateway objects in SMS.

Let me know if that's clearer. Thanks to you all below (Vladimir Yakovlev, Maarten Sjouw, and Chris Atkinson) who also answered.

[Vladimir]

It would help if you can provide a simple topology diagram of the desired state with sample IPs.

[Maarten_Sjouw]

To answer your question, what we normally do in these type of situations is set a RFC1918 to RFC1918 networks NoNAT rule in the top of the NAT rules, to prevent anything that comes from a RFC1918 network and goes to a RFC1918 network, to keep all addresses original.

I presume that you know how to setup the encryption domains and you could also use those groups in a NoNAT rule when you have address ranges that are not in the RFC1918 networks

[Chris_Atkinson]

In addition you also have the ability (via a checkbox config) to disable NAT for a given community if that is your preference / requirement.