Policy Routing on Traffic Hitting Firewall Interfaces

[rsingh-a2n]

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?

[the_rock]

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

[rsingh-a2n]

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

[PhoneBoy]

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]

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

Andy

[PhoneBoy]

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

[Chris_Atkinson]

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

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

[the_rock]

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

Andy

[rsingh-a2n]

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

[rsingh-a2n]

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

[PhoneBoy]

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 

[rsingh-a2n · Accepted solution]

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]

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

Cheers,

Andy