- Products
- Learn
- Local User Groups
- Partners
- More
Quantum Spark Management Unleashed!
Introducing Check Point Quantum Spark 2500:
Smarter Security, Faster Connectivity, and Simpler MSP Management!
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!
Hello colleagues
I set up a site-to-site vpn in my lab environment, this vpn worked perfectly, pinging side to side both ways. Then I tried to NAT the encryption domains of both sites and I couldn't get the traffic to tunnel.
As you can see in the image below (FW monitor) it is Natting and it takes it out through the public (eth0). But if I run a wireshark on the host pc, I see that the traffic is coming from those IPs napped but not tunneled
In the logs I see that the NAT is working fine, but then the traffic does not go through the tunnel (attached image)
I have a mgmt running 81.10 with both members of the vpn ( a cluster running 81.10 and a standalone running 80.40).
Anyone know what can it be?
Thanks
Hey Bruno,
What is the other side of the vpn tunnel? Based on the pictures you attached, it appears nat does take place properly in the logs.
Andy
Hi Andy,
Both sides are checkpoint VMs. One side is the cluster i mentioned and the other side is the Standalone, both devices are in my lab environment
Thanks, Bruno
Ok, so when you check the logs for the other side of the tunnel, do you see natted IP come in?
Andy
No, in the other side of the tunnel i don´t see anything, because the traffic never enters the tunnel.
Ok, so just to make sure...tunnel does show as UP on the other side as well? If so, but you dont see traffic, then I would try do basic vpn debug and see what we get:
vpn debug trunc
vpn debug ikeon
generate traffic
then run vpn debug ikeoff
Review ike.elg and vpnd.elg* files from $FWDIR/log dir
What precise configuration did you do for the NAT?
Did you include the NAT addresses in the encryption domain?
Hello PhoneBoy,
To better explanation, In one side, I have a cluster with a LAN (192.168.1.0/24), Inside this LAN I have a kali linux machine with the IP 192.168.1.100. In the other side I have a standalone FW with the same LAN (192.168.1.0/24) and inside this LAN a windows machine with the IP 192.168.1.100. I configure that the encryption domain for the cluster is 172.16.100.0/24 and the encryption domain for the standalone is 172.16.200.0/24 (a bit confusing, my apologies).
On the NAT table i said that if the cluster LAN want to go to the standalone LAN, go with the IP 172.16.100.X(Attached image). And if the Standalone LAN want to go to the cluster LAN, go with the IP 172.16.200.X
I hope I have explained myself as well as possible.
Thanks
Hello Aaron
Yes, both 172.16.X.X are included in the VPN encryption domains
@BrunoCiongoli , are you managing both gateways from the same management server? If so and if your NAT policy is identical on both sides, shown NAT rules translate 192.168.1.0 to the same 172.16.100.0 network on both sides. If you have different NAT rules configured on each side, please show both.
While the names of the networks look good, check each network object's actual network definitions to confirm that they are inline with the names.
For encryption domains in each side, create an empty group and add to it local cluster/gateway and the 172.X.X.X.
Install the policy.
Drop existing tunnels using vpn tu command.
Try pinging again.
Hey @Vladimir
Yes, I´m managing both gateways from the same SMS. I apologize, i forgot submit the another NAT rules table, it is different (attach here)
I checked each network object and everything´s fine.
I had created the group you mentioned but without the respective cluster/gateway. I added it, installed the policies, and it still doesn't work.
According to the fwmonitor and the log (attached images) the NAT is working correctly, but the traffic does not go through the tunnel
Thanks for your time and response!
Are you using mesh or star community for this setup?
I'd suggest checking that in Community | Tunnel Management | Advanced, Disabel NAT inside VPN community is not checked.
If it is, uncheck it.
...and, if it is not, changing Community | Tunnel Management | VPN Tunnel Sharing to One VPN per Gateway pair.
I would also suggest installing ccc script on active cluster member and a single gateway to check VPN routing using VPN Troubleshooting | Show VPN routing option to see if 172.X.X.X is included on each side.
Hello @Vladimir
I´m using a Star community.
Disabel NAT inside VPN community is not (and was not) checked.
I changed the community option to "VPN Tunnel Sharing to One VPN per Gateway pair."
I installed the ccc script on both ends (cluster and gateway). Please look the attached image for the VPN routing information.
As you can see, the 172.16.x.x is correctly listed in the encryption domain, but for some reason, all the other participating subnets are listed too. It´s like the vpn config is not recognizing the encryption domain object that I specified.
Active cluster member:
Standalone GW:
Both sides shows the same ED
On the other hand, I wonder why do I need to add the gateway´s local segments in the encryption domain. Probably I was not clear enought with my first post, but what i´m trying to test is to hide overlaping networks on VPN. For that I´m using the same LAN (192.168.1.0/24) IPs on both sides, so I´m not sure of what would be the behavior if the same IP address segment is set in both EDs.
Thanks in advance for your time and help
Adding gateways to the groups representing encryption domains was done to make use of per-gateway pair tunnel.
You can try removing them from the groups, changing tunnel properties in community back to one per subnet pair and testing it again, checking with ccc how your EDs look like in desired configuration.
P.S. It does not look like sk116097 "Destination NAT traffic not encrypted when the original destination included in the NATting gateway encryption domain", so it should work in theory.
I would also suggest changing the community topology to mesh, if it does not break the intended configuration, and give it another shot.
And you can use "Set VPN domain for VPN communities" feature:
To see if it'll limit EDs to 172.16.X.0/24 networks, thus avoiding collision EDs preventing NAT for VPN.
I already use "Set VPN domain for VPN communities" feature
About sk116097 "Destination NAT traffic not encrypted when the original destination included in the NATting gateway encryption domain", it doesn´t the same scenario but the cause applies %100 to my problem. So I´ll try with these solution and changing the community topology to mesh.
I´ll keep you informed, thank you very much for the info.
Hello, insert in your enc domain preNAT and postNAT IPs
on remote side only the postNAT ip
Hey @CheckPointerXL
I tried with this solution and it works, but I'm not sure about the behavior it will have according to overlapping, because the devices on each LAN have the same IP
Look for anything in Guidbedit that contains supernet and largest_possible_subnets and set all to false.
Hello PhoneBoy,
I understand this is an old post, I have a similar problem in a production environment. Except that my site is nating trafic to a single IP, to send to the remote site. The natted IP is the only IP configured in the encryption domain. If I add the hidden subnets to the encryption domain, the tunnel doesnt comes up, with the remote site rejecting my encryption domain.
The encryption domain MUST contain the hosts that will traverse the VPN.
You might try setting “one tunnel per pair of hosts” setting in the Tunnel Management section of the relevant VPN community.
Or you might have to do something like: https://support.checkpoint.com/results/sk/sk39679
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
17 | |
12 | |
7 | |
6 | |
5 | |
5 | |
4 | |
4 | |
3 | |
3 |
Wed 10 Sep 2025 @ 11:00 AM (CEST)
Effortless Web Application & API Security with AI-Powered WAF, an intro to CloudGuard WAFWed 10 Sep 2025 @ 11:00 AM (EDT)
Quantum Spark Management Unleashed: Hands-On TechTalk for MSPs Managing SMB NetworksFri 12 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live Netherlands - Sessie 38: Harmony Email & CollaborationWed 10 Sep 2025 @ 11:00 AM (EDT)
Quantum Spark Management Unleashed: Hands-On TechTalk for MSPs Managing SMB NetworksFri 12 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live Netherlands - Sessie 38: Harmony Email & CollaborationAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY