- 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!
Hi,
I'm trying to investigate if it's possible to stop the VPN routes propagation with Domain-Based VPN in a order to control the routing with BGP.
Migrating to Route-Based is an option but has it's limitations when running a mixture of Route-Based VPN with Domain-Based VPN (as per sk109340).
Is this a valid solution to disable "reroute_encrypted_packets" on the relevant gateways using GuiDBedit?
Any other ideas how it can be achieved?
Thanks.
It's not an issue of the routes propagating to BGP, it's an issue of the gateway preferring VPN routes, which are basically happening in the kernel.
Got it
Having read the SK you referenced, I would come to the same conclusion: change the reroute_encrypted_packets setting.
I also see you have a TAC case and that we're checking on this.
Are you saying the routes from the VPN propagate to BGP or vice versa?
Perhaps you can filter with routemaps: How to configure Routemaps in Gaia Clish
If I use BGP on top of a domain-based VPN, the gateway always prefers the VPN routes. I am trying to find a way to stop the VPN routes to be propagated automatically so Gaia routing can be used instead.
Due to the amount of existing VPN communities this is a bit painful to transition to route-based VPN.
It's not an issue of the routes propagating to BGP, it's an issue of the gateway preferring VPN routes, which are basically happening in the kernel.
Got it
Having read the SK you referenced, I would come to the same conclusion: change the reroute_encrypted_packets setting.
I also see you have a TAC case and that we're checking on this.
Thanks Dameon Welch-Abernathy, I just needed an assurance that this is a valid solution and will be supported by the TAC in case of any issues.
I didn't raise a TAC case (yet) but ran it passed our local SE, so perhaps he opened one on my behalf.
Misspoke on the TAC case, but your SE is definitely asking around
Just an update, I tested this scenario in the lab and disabling reroute_encrypted_packets works like a charm. The kernel VPN routes are still there but not being used to forward traffic, OS routing is being used instead.
Glad it works.
I'm curious what your exact use case is here (i.e. why you want to override the VPN routes with BGP).
Our customer got 2 sites with on-premise clusters running VPNs to bunch of CloudGaurd clusters hosted on Azure/AWS.
My predecessor chose to configure MEP for fail-over between the on-premise clusters.
However, in a fail-over scenario all the users are still routed (static routing being to date) through the primary site and causing asymmetric routing.
My goal is run dynamic routing to fail-over automatically the public clouds connectivity.
The issue currently is the domain-based VPN which always prefers VPN kernel routes and the idea is to control how traffic is routed to the public cloud using BGP (CORE switches <--BGP--> On-Premise clusters <--BGP--> Public Cloud Clusters).
Route-based VPN will resolve it as well but will introduce another challenges like narrowing down the encryption domains while we have another Domain-Based VPNs with 3rd parties.
I guess we'll have some healthy debates after xmas whether to go ahead with disabling reroute_encrypted_packets or converting everything to Route-based VPN.
Cheers!
I have just stumbled across this post, and am curious to know the final outcome as i´m in a similar situation. Was disabling reroute_encrypted_packets a valid option? Or did you choose to migrate to route-based vpn?
Sorry about the late response, just saw it now.
After many delays we're migrating to route-based VPN very soon.
I did some further testing and couldn't achieve the desired outcome with domain-based VPN, with route-based VPN it's a very painful migration but we'll get there.
Np. Ok, thx for the feedback.
Once you are done, I would appreciate the opportunity to hear how your migration to route based VPN went (pitfalls, unexpected limitations, etc.) . Personally, when I compare route based VPN to domain based VPN, I do not see any (technical) pro points for domain based VPN. Domain based VPNs are way to inflexible.
When all the limitations for route based VPNs are lifted in R80.xx I am curious to know how many migrations to route based VPN will takes place
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
13 | |
12 | |
11 | |
10 | |
9 | |
8 | |
7 | |
6 | |
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