- 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!
Hi,
I have many site behind a private ISP (Have no control here), all site is cluster, all running R81.20.
All site communicat to the Management server directly on the private ISP network, and all GW is member of a meshed VPN.
All the FW have no problem communicat to the Mgn, all cert and keys are update, so no problem here.
The VPN tunnel has no issue between the 192.168.x.x network, the problem starts when we need to communicate to the 10.161.100.x network, that is behind the FW1.
No problem with access from Com1 to Mgn, but Com2 or 3 can't talk with Mgn.
Mgn can't use the smtp mail server that is locate behind FW3, or ping any other network that belongs to the VPN network.
What I can see in the log, is that all Mgn request is route directly out on the external Interface on FW1.
Same happen to Com2 and 3, the request is going out on the local FW external interface.
All site proberly know that the 10.161.x.x is on the external network, so it just send it there.
I don't want any Mgn traffic with other Gateways stop working, but how can I trik the system to send local request to the Mgn server on the VPN network?
Hope you have the info you need... (Network pic is include)
/Steen
So this is traffic from the management server itself, correct?
By design, management traffic is NOT routed through VPN.
To fix this would involve hacking implied rules and such, which will make management traffic dependent on the VPN being active.
This is not recommended.
Read the following two (similar) threads on this topic:
Right, always forget about that. @Satto , below sk should help too.
Andy
Something outside of the encryption domain, yes.
What does zdebug show?
Andy
So this is traffic from the management server itself, correct?
By design, management traffic is NOT routed through VPN.
To fix this would involve hacking implied rules and such, which will make management traffic dependent on the VPN being active.
This is not recommended.
Read the following two (similar) threads on this topic:
Right, always forget about that. @Satto , below sk should help too.
Andy
Hi,
Thanks for all your answer, but Im not sure that we are on the right track.
I have 2 problems, if we look att the mail problem first, maybe i'll better understand the smartconsol/cli problem later.
So why does the FW1 send the mail trafic from the Mgn server out on the Internet interface, when it knows that the 192.168.4.0/24 network is behind the FW3 using VPN.
The network 10.161.100.0/24 is published by our Privat ISP and route to 10.161.1.11, it is used as a type DMZ.
@;15761032.89339;[vs_0];[tid_1];[fw4_1];fwuser_process_packet: Got packet dir 1, 10.161.100.100:31306 -> 192.168.4.200:0 IPP 1, with dir 0 ;
@;15761032.89348;[vs_0];[tid_1];[fw4_1];cpxl_chain_handler: <dir 0, 10.161.100.100:31306 -> 192.168.4.200:0 IPP 1> is not accelerated (EXFLAG set), returning;
10.161.100.100 -> 192.168.4.200 ICMP type 8, code 0 ;
10.161.100.100 -> 192.168.4.200 ICMP type 8, code 0 ;
/Steen
For that, did you try turn off sxl as a test?
Andy
Hi,
No difference in behavior when off.
/Steen
K, fair enough. I would double check with TAC via remote session, just to make sure possibly something simple is not missing here.
Andy
It's exactly what I said above: traffic from the management (ALL TRAFFIC not just that for managing gateways) is NOT sent over VPN.
This is by design.
Hi,
Okay, so if I want to send email using a server on another site, It need to connect on the outside of the GW on that site?
Thanks, is nice to understand why, so i don't need to trace the error anymore.
/Steen
Something outside of the encryption domain, yes.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
24 | |
15 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 | |
2 | |
2 |
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