- 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 All,
We were trying to influence routing via PBR to not use an Express Route interface. We essentially have Microsoft Cloud PCs that we want to get connected to remote access VPN.
fw monitor shows traffic coming in the Public WAN interfaces and return traffic being sent via Express Route. We wanted to change this behaviour without messing with link selection or route redistribution as the Cloud PC external IP falls under BGP learned ranges.
When trying with PBR to set the table action to use the Public WAN GW as next hop, and matching source to the FW interface range with destination of the cloud PC the traffic still went out the Express Route interface. TAC suggested to change the matching logic to match the interface and use the Microsoft IP as the source instead which also didn't solve the asymmetry.
Do PBRs not apply for traffic related to initiating remote access VPN connections?
Just finished up a call with TAC, and he said it was limitation 10. We were testing with just checking the connectivity to the IP over port 443 via powershell script instead of using the endpoint connect software.
So that solves that - limitation with PBR which we'll have to keep in mind for the future.
Thanks all
Rahul
Just to update on this quick, @rsingh-a2n and I had a look together at customer's config and he showed me what was initially configured and what TAC suggested, but neither method worked. I asked him to upload some screenshots to this post.
I could be mistaken when I say this, but Im fairly positive that PBR takes precedence over regular static route, but still does not work.
Anyway, lets see if someone can clear any confusion.
Cheers,
Andy
Thanks Andy.
To get a sense of the environment, here is the Cloud PC going out over public WAN and the pre-existing express route going over the private cloud/private WAN.
In the Checkpoint WebUI I tried a couple thing. The first attempt with PBR was using a matching rule of traffic coming from src Eth1 and with destination a.a.a.a, use table action 1. I also tried to put in the Eth1 subnet itself in the source column but fw monitor and tcpdump showed that even if traffic came in on Eth1, it would go out Eth3.
TAC recommended to change the action table to be a Default Destination using the same GW and set the matching logic to
Interface = Eth1 and Source = a.a.a.a (Cloud PC).
This also didn't work (confirmed via fw monitor). I've tried enabling the advanced PBR option and pushing policy but no luck so I thought I'd make the community post.
Best,
Rahul
To use PBR, you will need to be on R80.40 above and use Route-based VPNs.
See: https://support.checkpoint.com/results/sk/sk167135
Customer actually ONLY has route based VPNs and they are on R81.10 + jumbo 78
Andy
I'm guessing this will need a TAC case to investigate.
It's not clear from the diagram which is the VPN.
Why PBR vs just normal more specific static routes to correct this?
I believe we did try regular static route, but Rahul can confirm for sure. Either way, there is an ongoing TAC case.
Andy
Hi Chris,
The traffic from the Cloud PC to the Gateway over Public WAN is where the Remote VPN connection is attempting to establish. The return traffic is sent over the private cloud instead of back the way it came.
Static routes would work yes, but we don't want to run into an event where we are negatively impacting traffic that goes over the private wan link, that's why I wanted to use policy routes in the first place.
Rahul
Thanks for the link PhoneBoy,
I guess limitation 10 applies here, since the Remote Access VPN reply traffic is treated as locally generated, it won't bother with PBR.
Rahul
I actually assume Remote Access would fall under Limitation 9, since Remote Access is basically domain-based VPN.
To confirm this 100%, I recommend a TAC case: https://help.checkpoint.com
Just finished up a call with TAC, and he said it was limitation 10. We were testing with just checking the connectivity to the IP over port 443 via powershell script instead of using the endpoint connect software.
So that solves that - limitation with PBR which we'll have to keep in mind for the future.
Thanks all
Rahul
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
18 | |
12 | |
6 | |
6 | |
6 | |
5 | |
4 | |
4 | |
3 | |
3 |
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