cancel
Showing results for 
Search instead for 
Did you mean: 
Create a Post
Darren_Fine
Nickel

PBR and SecureXL issues in R80.20

Hi Guys,

Has anyone had any issues with PBR on R80.20 ?

I have tried an upgrade from a working R80.10 to R80.20 twice now and found that the PBR is an issue once upgraded to R80.20.

This is on JHF 33 and now JHF 73 .

One of the troubleshooting steps after seeing sk109741 was to switch off SecureXL - once we did that all worked as it did on R80.10 .

<also tried the PBR route lookup option - it made no difference)

We have opened a TAC case and have had the environment running succesfully without SecureXL for the entire day - but obviously we want to enable SecureXL ultimately .

 

Just thought I would post in case anyone else is having PBR issues on R80.20 ?

(also if you have any ideas on how to fix this - before TAC gets back to me - let me know)

0 Kudos
6 Replies
Darren_Fine
Nickel

Re: PBR and SecureXL issues in R80.20

Hi

 

Just an update on this - We still are experiencing this issue even though TAC has confirmed its a known issue and they did give us a hotfix (to go on top of JHF 47).

 

However this hotfix did not have the desired effect and the issue remains.

 

Is no one else experiencing this issue?

 

Thanks

0 Kudos

Re: PBR and SecureXL issues in R80.20

I'm also seeing PBR routing issues in R80.20 with JHF Take 87 after upgrading from R80.10.

What I'm seeing in my scenario is that the first 3 to 5 SYN packets for a new TCP connection get incorrectly routed out the interface that has the default route before the gateway figures out which is the correct interface to route the packets to.

The fourth or fifth SYN packet gets routed to the correct interface and then the rest of the TCP session is routed correctly. 

Switching SecureXL off in R80.20 fixes it.

0 Kudos

Re: PBR and SecureXL issues in R80.20

Hi Paul

 

Did you see the issue when you were on take 47?

We have similar issue. take 87 should fix the secure XL. however, we encounter a peformance issue.

Weird thing is that when we rollback to take 47, we don't see the performance issue anymore. 

 

So you applied take 87 and turn off secure XL and that fixes the issue?

 

Regards

Alex

0 Kudos

Re: PBR and SecureXL issues in R80.20

Take 87 was applied during the upgrade to R80.20 so I never had a chance to run see if the problem exists in Take 47.

Turning off SecureXL on R80.20 Take 87 fixed the issue in our environment. Fortunately our gateways are not under heavy load (< 40%) and the performance impact of running without SecureXL is negligible (about 5 to 10% higher CPU load).

According to our support partner Check Point are aware of the PBR routing problem and are working on a fix.

0 Kudos

Re: PBR and SecureXL issues in R80.20

Hi Team,


We also face the same issue with PBR after upgrade to R80.20.

Still, we are not install any hotfix because when we try to install take_47 and after installing the HotFix when we run "fw unloadlocal" then suddenly gateway goes reboot so we uninstall the HotFix.

Can you confirm that take_87 resolve the issue with SecureXL enabled ?

We have 21400 appliances with both CoreXl and SecureXL enable.

I had installed take_47 on multiple different appliance but the first time I face an issue with this take_47 with 21400 R80.20 with fresh setup.

So If I disable SecureXL and then install the take_87 the does this resolve this issue because we already face an issue with Take_47.

Thank You


Regards
@Cinmaya NaiK

0 Kudos

Re: PBR and SecureXL issues in R80.20

Hi all,

I started getting reports about services using PBR not working the day after upgrading to R80.20 Take 87 from R77.30.  Disabling SecureXL for individual IP addresses having issues resolves their issues, but I don't consider this to be a permanent solution.  I have created a Service Request with Check Point Support for further investigation.  In our case, PBR is not entirely broken, however the routing seems to get messed up during a conversation, not necessarily at the start of a connection.  I was requested to try the solution in sk109741, but that did not resolve our issues.  I will update when I get further information.

Thanks,

 

Jonne.

0 Kudos