- Products
- Learn
- Local User Groups
- Partners
- More
Check Point Jump-Start Online Training
Now Available on CheckMates for Beginners!
Why do Hackers Love IoT Devices so Much?
Join our TechTalk on Aug 17, at 5PM CET | 11AM EST
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
ZTNA Buyer’s Guide
Zero Trust essentials for your most valuable assets
The SMB Cyber Master
Boost your knowledge on Quantum Spark SMB gateways!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
Hello,
we experience strange routing behavoiur which I identified accedently, so I dont know since when it occurs.
We need a bunch of PBR rules, because our Internet breakout is not the standard route due to historical developments.
Standardroute is set to address a.a.a.a which leads to interface a. Clienttraffic on ports 80 and 443 is routed to address b.b.b.b on interface b with PBR. Now an initiated client connection (telnet 8.8.4.4 443) should be routed to b with NAT and return on b and back to the client.
But most of the connections are routed to a with a NAT of b, which means the incomiung traffic returns n interface b and back to te client, which is asynchronous. And this chnges randomley as I tested a few minutes ago. Sometimes its a, sometimes b.
I found sk163252 which describes this behavoiur, but the Hotfix solving this is already installed. We have two 5600 running R80.30 take 155 installed.
sk100500 says, that there are limitations wiith PBR when some other blades are active, but thats hard to believe as discussed in this thread: https://community.checkpoint.com/t5/Enterprise-Appliances-and-Gaia/PBR-limitations/m-p/64639/highlig...
So any help is appreciated, because randomely asynchronous routing is not a basis for a stable enterprise network...
Thank you,
Frank
It has to do with SecureXL. If I deactivate it with "fwaccel off" no new connections are routed wrong, and the asynchronous ones become fewer.
Yes, TAC is involeved...
So TAC won´t help me, because they refer to sk100500, saying PBR is unsupported with several Features activated.
On saturday I deactivated IPS and URLF and routing was still asyncronous. The only thing to make packtes oing the right route is to deactivate Cluster XL with "fwaccel off". ...
Last updates from TAC regarding the issue, as well as cluster flapping due to routed-pnote:
After reviewing the provided files, I can see the following:
From sk100500 limitation, PBR is not supported with:
So the PRB is not supported in the environment, this can cause such behavior.
And after insisting on support:
Thank you for the update.
I understand what you are throwing to, however, those are the limitations.
It might be there is no correlation between the issue and the limitation, however, to investigate the issue we need to run a supported version.
Do you have any ideas how to proceed?
There is a new sk167135 describing PBR and new ABR very detailed, but the most annoying fact, that it is meant to be unsuported with IPS, NAT, etc is still there. The simple statement "PBR will not work" in my opinion is not accepptable. What about NAT? Tere is a sample network configuration in the sk with two different Internetconnections, separated by PBR. And when you connect clients to the internet NAT is needed. Or do I have to use public addresses for internal use only to get PBR working?
My problem is asynchronous routing. I deactivated IPS and URLF, but routing issue was the same. Clients are only taking the right way if SecureXL is disabled.
When a connection is accelerated, the in/out interfaces are sort of hard-wired.
If a packet for a flow comes in or is supposed to go out a different interface than the initial interfaces...you will have issues.
What is causing the asymmetricness here?
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY