topic Re: Problem with Policy Based Routing in Firewall and Security Management

Problem with Policy Based Routing

VolkerM — Tue, 22 Dec 2020 17:23:26 GMT

Hello there,

I'm currently helping out a company and facing an issue with Policy Based Routing and/or possibly Threat Emulation.
I knew the configuration from about 2 years ago, when everything was on R77.30 and working without any problems.
About one year ago they migration from R77.30 to R80.20 and bought new firewall models.

After the migration they got trouble with Policy Based Routing.
They've got two internet uplinks. The primary/default link is a professional one with a professional router and static ip addresses.
There are using 5 static ips (released with the Proxy ARP feature). This professional uplink has a limited bandwidth and normally is
only used for different kind of server services and VPN.
The "client" internet connection is/should be released with the second uplink which has a non professional/consumer router with
dynamic ip addresses and a lot more bandwidth. There is a proxy (Squid) for these kind of connections.

I don't know what they changed or if anything related to this configration is unsupported in R80.20, but it is not working anymore.
They have trouble downloading larger files. The downloads start and at some point they simple go to 0 kbit/s and stay stalled.
I also recognized that the cluster, which is also using the proxy to download the latest threat prevention updates aso., is showing
a warning to check the internet connection.
I changed the Threat Emulation connection handling to background, but the issue is still there.
If I switch the translated source in the NAT rules to the first ISP everything is working fine again (which is the workaround since one year!).

Maybe I missed something, but I'm a bit out of Checkpoint administrative practice.

The configuration is as follows:

2 Gateways (Gaia / ClusterXL):

R80.20 Take 18 (GWs)
R80.20 Take 101 (Management)

Network objects:
WAN2 = 192.168.178.100
Proxy_DMZ = 192.168.160.80
SomeServer_DMZ = 192.168.160.111

Relevant interfaces:

-Interface eth2 (first ISP - DEFAULT Route)
linked to another ISP router

-Interface eth3 (second ISP - specific hosts should use):
Virtual IP: 192.168.178.100/24
Member IP GW1: 192.168.178.101/24
Member IP GW2: 192.168.178.102/24

-Interface eth4 (DMZ Network):
Virtual IP: 192.168.160.250
Member IP GW1: 192.168.160.251
Member IP GW2: 192.168.160.252

Policy Based Routing:

-Action Tables:
---------------------------------------------------
Table / Destination / Next Hop / Gateway
---------------------------------------------------
SomeServer_DMZ / Default / Normal / 192.168.178.1
Proxy_DMZ / Default / Normal / 192.168.178.1

-Policy Rules:
--------------------------------------------------
Priority / Action / Source
--------------------------------------------------
1 / Table x: SomeServer_DMZ / 192.168.160.111/32
2 / Table y: Proxy_DMZ / 192.168.160.80/32

NAT:

-NAT Rules (Manual NAT):
----------------------------------------------------------------------------------------------------------
Original Source / Original Destination / Translated Source / Translated Destination / Translated Services
----------------------------------------------------------------------------------------------------------
SomeServer_DMZ / Internet / WAN2 / Orginal / Original
Proxy_DMZ / Internet / WAN2 / Original / Original

Threat Emulation:

Scope: Proxy_DMZ
Inspect incoming files from the following interfaces: External and DMZ
Connection handling: tested hold and background (hold was set)

Maybe anyone has an idea of what is going wrong here.
Thanks a lot and happy holidays! Stay safe and healthy.

Best regards,

Volker

Re: Problem with Policy Based Routing

PhoneBoy — Wed, 23 Dec 2020 20:19:10 GMT

There’s a change in behavior from previous versions with respect to PBR routes that may be applicable here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk101562&partition=Advanced&product=Security
You’ll note this only applies up to R80.10.

Also it might be better to upgrade to a later release than R80.20 as we’ve added more functionality to PBR.
See: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk167135&partition=Advanced&product=Security

Re: Problem with Policy Based Routing

Timothy_Hall — Wed, 23 Dec 2020 20:51:14 GMT

Some great reading in sk167135, had no idea there was a "hidden" PBR feature that could match regular firewall policy rules and therefore apply PBR to specific applications, URL categories and users/groups.

Re: Problem with Policy Based Routing

PhoneBoy — Wed, 23 Dec 2020 21:09:39 GMT

Pretty sure we only tested it with Office 365 in particular but don’t see why it wouldn’t work for other apps as well.
Note that we are planning additional enhancements along these lines as well as removing some of the PBR-related limitations.

Re: Problem with Policy Based Routing

VolkerM — Thu, 24 Dec 2020 13:15:42 GMT

Thank you for providing the information regarding the SKs.

Just clarifiy again: there is an external proxy between the Clients and WAN2.

Clients -- Proxy_DMZ -- WAN2 (Interface eth3)

So connections originating from that proxy should use WAN2 and not the default path for internet traffic defined in the default routing table (WAN1 / Interface eth2).
"SomeServer_DMZ" is also there using WAN2, too (without the proxy in between):

SomeServer_DMZ -- WAN2 (Interface eth3) <-- this is currently active and working as far as I can see

So I need to send all internet facing connections from Proxy_DMZ and SomeServer_DMZ to WAN2.

PBR summary:

show pbr summary
PBR Summary

PBR has 2 tables
PBR table SomeServer_DMZ (ID=1) has 1 route
Default route, nexthop gateway
gateway 192.168.178.1
preference 3
PBR table Proxy (ID=2) has 1 route
Default route, nexthop gateway
gateway 192.168.178.1
preference 1

PBR has 1 rule
PBR rule 3 from 192.168.160.111/32 table 1

(rule for Proxy_DMZ removed because of the issues, but was configured like "PBR rule 3")

SK101562 states that one should use the original source address. You've pointed out that the described behavior is applicable till R80.10 so it must have been a problem in R77.30 too. The installed version is R80.20, so this limitation shouldn't be there anymore.
I don't get your point. May you please tell me more detailed what I can try?

I recommend them to update to R80.40, but they have to decide that. I think if I tell them that their setup is only working with R80.40 or R81 they would go for it.

And another question arised reading the SKs for Policy Based Routing:
in SK100500 I've just read that a couple of features/blades are unsupported with PBR (URL Filtering, IPS and HTTPS Inspection etc.).
They were definitly using these three features with R77.30 along with PBR. So are these new limitations of R80.x?

Thanks.

Re: Problem with Policy Based Routing

PhoneBoy — Thu, 24 Dec 2020 19:12:20 GMT

It may have worked in R77.30 but don’t believe PBR was ever formally supported with those blades.
There were some very significant changes to SecureXL in R80.20 that would definitely impact PBR (thus the SK I mention).
Since you’ve anonymized your IP addresses, I don’t know precisely what IPs you’re using in your routes, which is why I thought this might apply.

One thing that was added in R80.30 was the ability to use a default route for PBR routes (highly desirable for an Internet proxy, I would think).
Its achievable without this in R80.20 but it would require multiple routes to be defined.

I think your best bet here would be a TAC case.
That said, my recommendation to use a later release than R80.20 for this still stands.