- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Understanding about NAT and VPN
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Understanding about NAT and VPN
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Since you are doing the NAT on your end, I don't believe it is strictly required to do so.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Jozko Mrkvicka
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
