- CheckMates
- :
- Products
- :
- General Topics
- :
- 2 VPN's Same Remote Encryption Domain
- 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
2 VPN's Same Remote Encryption Domain
I have been tasked with creating two VPN connections to a new vendor, a backup and a primary. Each has a different peer IP but the catch is the encryption domain will be the same on both.
I am not clear yet if both VPN connections will be up all of the time or not (I don't know if they are using probing, or DPD, or something that will keep phase 1 and 2 up).
To meet this requirement is it valid for me to configure one VPN star community and have both of the vendor's Satellite Gateways in the community like in the screen shot? Everything except the peer IP's is the same, encryption, lifetimes, etc.
The production traffic traversing the VPN will always be initiated from the remote end.
Will Check Point be able to route through the appropriate VPN by knowing which one received the traffic?
Thank you in advance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Configuration seems valid.
Checkpoint GW knows to return the traffic to the vpn peer the original conn was received through.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My understanding is that you can't have identical encryption domains for 2 different peers. Does putting them in a star VPN topology get around that? I would be under the impression that NAT would need to be involved for this scenario.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You mean same enc. domain for different interoperable objects? If so, definitely you can, I did that in the lab many times and worked fine.
Best,
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Correct. Interesting... just trying to wrap my head around how that works.
- Interoperable Object 1 - 1.1.1.1 with the encryption domain of 192.168.4.0/24
- Interoperable Object 2 - 2.2.2.2 with the encryption domain of 192.168.4.0/24
Both peers have a webserver using the IP 192.168.4.25. How does my device get to the proper webserver?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I see now what you meant @CaseyB . For instance like that, yea, sounds like NAT would be needed.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
putting identical enc domain on the two or more vpn peers or what called implicit MEP indeed require static nat usually in case both VPN peers forwarding the traffic to the same network and it needs to know from which gw to return.
in this case the one of the vpn peers only initiate the traffic to the other side, and in this case it doesn't require a nat, and the CP GW knows to return the return traffic to the original vpn peer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In my scenario there will be two VPN's to two different peers and the same server IP at the end of each, however only 1 VPN will have the active server at a time. Traffic to / from the server IP will not traverse both VPN's at the same time. Does this still require MEP?
It's a primary and backup VPN.
Unfortunately I don't think NAT is an option in my scenario.
I built out the scenario in my lab yesterday and it seems to work. Moving the server from behind VPN 1 to behind VPN 2 on the fly is a little rough, it's like a timeout needs to occur.
I will test more before trying in production.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
implicit MEP is the description of having the same enc domain on multiple vpn peers. it doesn't mean that you need to explicitly configure MEP in the VPN community (which called explicit MEP).
in case you need to initiate traffic from your side to the server IP located behind each of the remote GWs (and the server have two paths to reach your network via both GWs), how would the server know through which it should return to keep the symmetry? (assuming they care about symmetry on the other side) you will need to configure source NAT (hide behind IP or GW) on the remote GWs, so the server will get the packet from the GW address, and since it needs to reply to this IP, the symmetry will be kept. if you have other trick to keep the symmetry for return, you don't need SNAT.
read more here: https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_SitetoSiteVPN_AdminGuide/Topics-VP...
in case all the traffic only initiated from the remote server side, then you don't need NAT at all. the server will go from one of the GWs to your GW, and your GW will return it to the same original VPN peer (related to that connection).
moving existing connection on the fly may probably die because of stateful inspection on the remote side GWs or that the connection is registered under Peer1 on your local GW.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Correct me if Im mistaken when I say this @AmirArama , but I believe from smart console in vpn community, mep setting there ONLY applies to explicit mep, not implicit?
Andy
At least thats what it looks like from below link...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How would I do the static NAT. I need the same remote IP presented to the server inside my network?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That makes sense, thank you for clarifying!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I agree with @AmirArama , seems right to me as well.
Andy
