- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
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 Checkpoint Community,
We have this unusual behavior in our client's instance wherein traffic is suddenly encrypted through VPN when it shouldn't.
We honestly don't know why this happened, as there were no changes performed.
Does anyone have any experience in this and could give us some insight.
Thanks!
Hi,
The VPN log mentions tcp-high-ports as the service and the non-VPN log mentions TCP-9001 as the service. Can you check on what rule the VPN is hit? And check on what rule it should hit?
Did you changed 'Match for Any' in the mentioned services so traffic is hitting another rule than expected?
Maybe you can take a look at the Audit log to see what was changed after September 6th.
Regards,
Martijn
I actually found a reason as to why this happened. There's overlapping internal domains in both of my clusters, and unfortunately this traffic is being routed towards the other Firewall (NGFW Pair 1) instead. The correct behavior should be that it's going to be routed to its own Firewall (NGFW Pair 2). This has been now addressed.
Anyways, I created a policy to address this, and everything works smoothly now. I might have created a not-so-specific policy and that's why for some reason it keeps on routing the traffic to NGFW Pair 1.
Do you have a route-based VPN (with VTIs) configured here?
You'd probably need to dig into the log entries (the full log cards) to see why the rulebase logic changed.
When opening the log cards, it just says that it's encrypted. But yeah I do think I have a route-based VPN.
I do noticed that in the log card, the traffic is routed to an IPsec VPN peer for some reason, which shouldn't be the case since I didn't define any routes that would do such action.
Is it all static routes or are dynamic routes used?
Either way, it appears that routing changed somewhere.
This would probably require investigation from the TAC: https://help.checkpoint.com
Hi,
The VPN log mentions tcp-high-ports as the service and the non-VPN log mentions TCP-9001 as the service. Can you check on what rule the VPN is hit? And check on what rule it should hit?
Did you changed 'Match for Any' in the mentioned services so traffic is hitting another rule than expected?
Maybe you can take a look at the Audit log to see what was changed after September 6th.
Regards,
Martijn
I will check this as soon as I'm on site tomorrow. But I do remember its "Match Any".
There's no changes to the rule as well.
I see the point @Martijn is making, I would definitely check into that as well.
Andy
You can also follow sk25675 and sk98241 to exclude traffic from being encrypted.
Definitely good SKs.
Hello Everyone,
To add, I just found a blocked rule regarding this which is unusual. It shouldn't be communicating to my other NGFW pair but it seems it is (via VPN)
I'm currently checking the SKs provided by @Zolocofxp, while checking @Martijn's suggestion
Will update you guys once there's improvements. Thank you so much for the help.
Yea...so that message packet should not have been decrypted really means it SHOULD have been encrypted, ie firewall "thinks" it should go through VPN.
Andy
I actually found a reason as to why this happened. There's overlapping internal domains in both of my clusters, and unfortunately this traffic is being routed towards the other Firewall (NGFW Pair 1) instead. The correct behavior should be that it's going to be routed to its own Firewall (NGFW Pair 2). This has been now addressed.
Anyways, I created a policy to address this, and everything works smoothly now. I might have created a not-so-specific policy and that's why for some reason it keeps on routing the traffic to NGFW Pair 1.
Good job!
Thank you guys, I was able to troubleshoot it with the help of your inputs. Everything's working as intended now.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
14 | |
12 | |
11 | |
9 | |
9 | |
7 | |
5 | |
5 | |
5 | |
5 |
Tue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFThu 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!Thu 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