- Products
- Learn
- Local User Groups
- Partners
- More
Policy Insights and Policy Auditor in Action
19 November @ 5pm CET / 11am ET
Access Control and Threat Prevention Best Practices
Watch HereOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Hello everybody
I'm writing this post in the hope that someone has experienced the same issue. I'm trying to publish a service on the internet; the service is behind a site-to-site VPN that connects two Check Point clusters. The issue is that the request reaches the device, performs the destination NAT correctly, but the traffic is not being sent through the VPN.
In the following schema could understand better the connection that i need to realize. The external ip is static.
Based on this, i create the following in the Internet Firewall.
1. A Rule that allows communication between External IP and Public IP.
2. A NAT rule that converts the Public IP into Internal IP address.
3. In the VPN community (Both firewalls are check point managed by the same smart-1), i add the External IP address in the local domain of internet firewall.
4. And finally I have installed policy in the both firewalls, but the traffic doesnt go trough the VPN, that is currently working with other internal connections.
I have tried to perform a FW monitor and I only see the i packet, but in the smart monitor appears the initial connection from External IP to Public IP and the NATed Destination (Internal IP)
I think the issue is the internet firewall doesnt identify this traffic as VPN traffic
I dont know if i am making any mistake... any ideas?
Thank you in advance!
Did you make sure encryption domains are correct?
Andy
Yes, the VPN works correctly, I just have added the external IP in the VPN range of internet firewall with the objetive the firewall send this traffic through VPN but without successful.
The rest of connections in the same VPN works correctly 😞
Can you send the log of the traffic you are referring to? Just blur out any sensitive data.
Also, see if any of below cases may apply, as I have a gut feeling they might...specially case 3
Andy
https://support.checkpoint.com/results/sk/sk108600
In a domain-based VPN, the decision to encrypt is based on the source IP being included in the Encryption Domain.
Since I assume you have not included the entirety of the Internet in your encryption domain for this "Internet Gateway," it will not choose to encrypt the traffic to this external IP.
This is, therefore, expected behavior.
A route-based VPN would probably be a better use case for this.
Hi, The external ip is always the same, i dont include the entirety of internet but I include that external IP, so the traffic should be routed trought the VPN...
I see what Phoneboy is saying about route based VPN, makes sense to me. I checked this for few customer we did this for and works perfectly.
Andy
Yes, I know, but this VPN is part of a star community, and change this vpn mode have a high impact. If its possible i would like to solve it using the actual VPN community.
I thought people were connecting to an external IP that was translated to an internal IP.
Instead, it's a specific external IP that's connecting to an internal IP (via NAT)...got it.
If I recall correctly, we do not include host objects in the calculation for Encryption Domain.
Instead of creating a host object, try creating a Network object (with a /32 subnet mask) and use that in the Encryption Domain instead.
I havent heared about it, but I have tried and still not working :(.
Its any way to check the negotiated SA, not the ID... I want to check somehow if the external ip added in the encyption domain is really included.
You can do vpn tu list ike or vpn tu list ipsec (just type vpn tu lis (wrong spelling), but it will give all the options)
Did you verify 100% that IP is indeed included in the enc domain?
Andy
Probably best to debug: https://support.checkpoint.com/results/sk/sk180488
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 42 | |
| 18 | |
| 12 | |
| 11 | |
| 9 | |
| 7 | |
| 6 | |
| 5 | |
| 5 | |
| 5 |
Wed 19 Nov 2025 @ 11:00 AM (EST)
TechTalk: Improve Your Security Posture with Threat Prevention and Policy InsightsThu 20 Nov 2025 @ 05:00 PM (CET)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - AMERThu 20 Nov 2025 @ 10:00 AM (CST)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - EMEAWed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchWed 19 Nov 2025 @ 11:00 AM (EST)
TechTalk: Improve Your Security Posture with Threat Prevention and Policy InsightsThu 20 Nov 2025 @ 05:00 PM (CET)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - AMERThu 20 Nov 2025 @ 10:00 AM (CST)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - EMEAThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAWed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY