- Products
- Learn
- Local User Groups
- Partners
- More
Introduction to Lakera:
Securing the AI Frontier!
Quantum Spark Management Unleashed!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
hey mates,
I have come across one more issue in checkpoint...i have configured 2 vpn for one of our client for 2 different location with similar lan ips. they are able to connect through one tunnel, but when they try to connect through another tunnel iam getting this error " Wrong peer gateway for decrypted packet (VPN Error code 01)".
If there is an overlap through VPN domains, one side should be NAT-ed.
If there is an overlap through VPN domains, one side should be NAT-ed.
Yeah i have thought of the same.. thanks
Yep, use the handy command "vpn overlap_encdom communities -s" to get a concise list of any VPN domain overlaps, see sk40206: Is there a way to view potentially overlapping VPN Domains? for more details.
--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.
hi tim thanks ..i can see the overlapping encryption domain after executing this command ..but how to get rid of this as customer is using same lan ip range on both side of the vpn tunnel and has refused to nat his network
You can double-NAT on one side of the tunnel to avoid any NAT whatsoever on the other side when an IP overlap is present, but it is difficult to set up and will involve configuring policy-based routing (PBR) and messing around with antispoofing to make it work with NAT. Let me illustrate, let's assume you are Site A and it initiates connections to Site B through the VPN tunnel, here is the setup:
Site A:
internal network 192.168.1.0/24, interface eth0
external network (some ISP routable block), interface eth1
NAT overlay network: 172.16.1.0/24 (This is a made-up network that does not exist anywhere in Site A's internal network and does not conflict)
Site A FW VPN Domain setting: 192.168.1.0/24, 172.16.1.0/24
Site B FW Externally Managed Gateway/Interoperable Device VPN Domain setting: 172.17.1.0/24
Network Policy Rule:
Source: 192.168.1.0/24
Dest: 172.17.1.0/24
Service: whatever
Action: Accept
Manual Static NAT (mask lengths much match precisely between Original & Translated fields or you will get a NAT verification error):
Orig Source: 192.168.1.0/24
Orig Dest: 172.17.1.0/24
Orig Service: Any
Translated Source: 172.16.1.0/24 (Static)
Translated Destination: 192.168.1.0/24 (Static)
PBR Policy Rule on FWA:
Source: 192.168.1.0/24
and
Destination: 192.168.1.0/24
PBR Next Hop: Internet GW, interface eth1
To reach systems at Site B through the VPN tunnel, users at site A must attempt to connect to the host at Site B's overlay IP address. So if the Site B system to be reached is 192.168.1.222, user at site A must attempt the connection to a destination IP of 172.17.1.222.
Site B:
network 192.168.1.0/24
NAT overlay network: 172.17.1.0/24 (This is a made-up network that does not exist anywhere in Site B's internal network and does not conflict)
Site B must be expecting traffic to arrive in the tunnel from Site A sourced from 172.16.1.0/24
You will also probably have to define some antispoofing exceptions on the Site A firewall to make this work. SecureXL also sometimes doesn't play nice with PBR based on your firewall version, you may need to manually turn on PBR support in SecureXL:
sk109741: Packets are not routed correctly when PBR is configured and SecureXL is enabled
This is from memory so I may be off on a detail or two but hopefully you get the idea. Not simple.
--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.
The easiest solution to have one of the sites to perform the NAT, and configure only the NATed IP as encryption domain in your config.
Thanks
Thanks for the ideas. In my case, I had to remove the manually defined network from the old Interoperable device (the remote gw). Even though is wasn't being used, it was still being used! 🙂
Thanks Daniel. This morning I did the same thing and it fixed my issue. I just added a dummy vpn domain in the original community just to test and it worked on the community.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
15 | |
12 | |
8 | |
6 | |
6 | |
6 | |
5 | |
5 | |
4 | |
3 |
Tue 30 Sep 2025 @ 08:00 AM (EDT)
Tips and Tricks 2025 #13: Strategic Cyber Assessments: How to Strengthen Your Security PostureTue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFTue 30 Sep 2025 @ 08:00 AM (EDT)
Tips and Tricks 2025 #13: Strategic Cyber Assessments: How to Strengthen Your Security PostureThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY