Error due to SecureXL

[Matlu]

Hello, everyone.

One question, is it advisable to disable SecureXL?

We have a problem in which our CCTV server cannot 'visualize' the IP cameras it has hooked.

The only way to solve the error, and have video of the IP cameras is if we disable SecureXL.

Is this something 'expected' in CP equipment? I am referring to the fact that SecureXL is often the cause of problems with certain types of traffic.

What would be the right way to fix this error permanently?
I currently have version R81.20.

Regards.

[emmap]

The software is coded and tested with the assumption that SXL is enabled. It is not recommended to leave it off. Highly recommended to tackle this one with TAC so that we can fix it properly.

[Matlu]

Disabling SecureXL for certain connections is not a solution that can be considered as 'permanent'?

[Chris_Atkinson]

No, if you have to disable SecureXL it's a bug or misconfiguration that should be taken with TAC.

[Matlu]

Our CP is in R82 version, managed by a Smar-1 Cloud.
Then the TAC has to give us a solution, since it is not recommended to have the SXL off right?

[the_rock]

I would follow sk @Tal_Paz-Fridman provided. What is the exact issue when sxl is enabled? Yes, it can be disabled permanently, but I would NOT do that.

Andy

[G_W_Albrecht]

It may be the constant workaround - disabling SecureXL completely is no way to go. But a TAC case might be the proper process - but try to exclude the traffic now quickly so you can turn SecureXL on again.

[Tal_Paz-Fridman]

I also suggest contacting TAC to resolve the issue.

A workaround could be to exclude specific traffic from SecureXL:

https://support.checkpoint.com/results/sk/sk104468

[AkosBakos]

Hi @Matlu 

Maybe fast_accel worths a try

https://support.checkpoint.com/results/sk/sk156672

[the_rock]

Thats a good idea.

Andy

[Matlu]

Hello,

Is there any way to “validate” if the SXL is “dumping” traffic, when it is active?

It seems that tshoot commands like tcpdump or fw ctl zdebug, don't exactly “see” traffic that may be being dropped by the SXL.

So, what commands can help you, to validate if SXL is being the problem for a particular traffic?

[Timothy_Hall]

You need to use the command fw ctl zdebug + drop to also see any drops occurring in SecureXL, although they are usually much more rare than drops in the main INSPECT code.

The best way to determine if SecureXL is the source of your problem is to leave the questionable connections in the slowpath (no offloading to the Medium or Fast paths allowed) and see if the situation improves.  sk104468: How to exclude traffic from SecureXL

[Matlu]

It's a little weird.

I used the command you recommend, my destination was an IP camera.

When we have the SXL enabled on the CP, the CCTV server cannot see the video from the camera, but the command

fw ctl zdebug + drop | grep <IP CAMERA> ... at that time it shows me nothing.

It is as if for the FW everything is working fine.

Then, when we disable the SXL, immediately the CCTV server retrieves the video from the camera.

Only the “fw ctl zdebug + drop” is the command that helps to detect if it is the SXL that is giving problems?

[the_rock]

When sxl is on, you probably would need to do sxl debugs.

Andy

[the_rock]

@Matlu 

FYI

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_PerformanceTuning_AdminGuide/Topic...

[Timothy_Hall]

If you see nothing in the fw ctl zdebug + drop that means no Check Point code (SecureXL/INSPECT) is dropping that traffic. 

Also I have to ask, are you on a Quantum Force 9000/19000/29000 or Lightspeed appliance?

Is this traffic multicast?  It could be getting dropped in the Gaia OS itself due to some kind of problematic interaction with SecureXL.  Only way to know for sure is set up a fw monitor -F with SecureXL enabled and see if the problematic traffic is hitting inspection points iI but failing to re-enter at o.  There have been issues in the past with SecureXL and multicast.

[genisis__]

Tim - valid point about mcast, we had issues in the past where the Checkpoint was a RP and after engaging TAC it was determined this was a bug, but we never had issues with mcast being passed through the appliances, assuming correct policy is in place.

[the_rock]

Hey bro,

Any luck with this or still same issue?

Andy

[genisis__]

Here's a good place to start:

SecureXL Debug Procedure

However as everyone has suggested, best to engage TAC, ensure your running latest recommended Jumbo etc as this will be a first step suggestion from TAC.

Last time I had an issue with SecureXL it was on R7x.x and the issue was resolve by upgrading to the latest version at the time.