Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
rsingh-a2n
Participant
Jump to solution

Policy Routing on Traffic Hitting Firewall Interfaces

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?

0 Kudos
1 Solution

Accepted Solutions
rsingh-a2n
Participant

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

View solution in original post

12 Replies
the_rock
Legend
Legend

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

0 Kudos
rsingh-a2n
Participant

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.

 PBR_ExpressRoute.png

 

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.

InitialAttempt.png

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).

TACSugg.png

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

PhoneBoy
Admin
Admin

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

the_rock
Legend
Legend

Customer actually ONLY has route based VPNs and they are on R81.10 + jumbo 78

Andy

0 Kudos
PhoneBoy
Admin
Admin

I'm guessing this will need a TAC case to investigate.

0 Kudos
Chris_Atkinson
Employee Employee
Employee

It's not clear from the diagram which is the VPN.

Why PBR vs just normal more specific static routes to correct this?

CCSM R77/R80/ELITE
0 Kudos
the_rock
Legend
Legend

I believe we did try regular static route, but Rahul can confirm for sure. Either way, there is an ongoing TAC case.

Andy

0 Kudos
rsingh-a2n
Participant

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

0 Kudos
rsingh-a2n
Participant

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

0 Kudos
PhoneBoy
Admin
Admin

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 

0 Kudos
rsingh-a2n
Participant

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

the_rock
Legend
Legend

Good to know buddy! And as always, @PhoneBoy to the rescue 🙂

Cheers,

Andy

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events