- Products
- Learn
- Local User Groups
- Partners
- More
Check Point Jump-Start Online Training
Now Available on CheckMates for Beginners!
Why do Hackers Love IoT Devices so Much?
Join our TechTalk on Aug 17, at 5PM CET | 11AM EST
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
ZTNA Buyer’s Guide
Zero Trust essentials for your most valuable assets
The SMB Cyber Master
Boost your knowledge on Quantum Spark SMB gateways!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
hi
we have two GWs which having site to site vpn.
they located in different geographic location, but they have Layer 2 line, so they basically see each other by arp.
so let's say 192.168.1.2/29 and 192.168.1.6/29 (and by these addresses they know each other as peers)
for some reason, instead of using ESP over proto:50, they are deciding to use NAT-T
i can't figure out why. and i was hoping to fix it, to save the double encapsulation. is there a way to understand what is behind this decision?
thanks
gws are single gws with r80.40 latest take. managed by the same mgmt, share the same vpn community.
ok
i found some sk165003
so i just tried to change the interface that facing the other gw to be configured as EXTERNAL, and it solved it. can't say i understand why it matters for now. and if it's must for the esp.
good night
Are you saying this worked fine before and it just happened with no change? It makes no sense for nat-t, if there is nothing in the middle...you may see that for vpn clients connection, but thats different.
ok
i found some sk165003
so i just tried to change the interface that facing the other gw to be configured as EXTERNAL, and it solved it. can't say i understand why it matters for now. and if it's must for the esp.
good night
k, good to know!
A few month ago we had the same issue (R80.40) without changing anything. We had a site2site VPN running for a long time without NAT-T. Suddenly, whenever our Check Point wants to initiate the tunnel, it used NAT-T and the remote site (Cisco ASA) rejected this attempt, because there was no NAT-T device in place.
One of our gateways crashed a few hours before the issue occurred for the first time, due to a memory error in the kernel. So we had TAC and R&D involved but nobody could find the cause for this NAT-T issue. The memory error got patched but still, our Check Point Gateways always tried to use NAT-T. So we ended up rebooting BOTH nodes at the same time, so no connection etc. could be synced back.
Turns out, this solved our issue. So the crash caused by the memory error, seemed to cause this NAT-T issue.
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY