asynchronous routing under PBR

[degrotef]

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

[PhoneBoy]

Probably best to get the TAC involved here

[degrotef]

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.

[PhoneBoy]

As I've said in other places on the forum: if disabling SecureXL "solves" an issue, get the TAC involved.

[degrotef]

Yes, TAC is involeved... 

[degrotef]

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

[PhoneBoy]

You probably mean turning SecureXL off, and that's definitely worthy of a TAC case.

Just to clarify the situation a little, URLF won't work with PBR because of where it happens in relation to the PBR code.
Believe there is a plan to fix this.
IPS should still work in some configurations.
An SK is planned on this (or the existing one will be updated).

[LarsG]

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:

• IPS
• URL Filtering
• Anti-Spam blade

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?

[PhoneBoy]

Any way you could simulate the issue without the unsupported software blades active in the lab?
That would at least make the case that this is not due to an unsupported configuration.

Addressing the underlying limitation with the aforementioned blades is probably an RFE as the various blades, routing, and SecureXL all interact in some way.

[degrotef]

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.

[PhoneBoy]

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?