Disabling SecureXL on SMB Appliance (R80.20.5)?

[Martin_Seeger]

Hi,

how can I exclude IP addresses or ranges from SecureXL on the SMB appliances with R80.20.5?

My management is R80.40.

I followed sk104468 and edited "table.def" but when I check according to the SK on the gateway I get the following result:

# fw tab -t f2f_addresses
localhost:
 Table f2f_addresses not loaded: Invalid argument

My best guess is that I got hold of the wrong "table.def" as there are several available:

/opt/CPsuite-R80.40/fw1/lib/table.def
/opt/CPR7520CMP-R80.40/lib/table.def
/opt/CPR7540CMP-R80.40/lib/table.def
/opt/CPR76CMP-R80.40/lib/table.def
/opt/CPSFWR77CMP-R80.40/lib/table.def
/opt/CPSFWR80CMP-R80.40/lib/table.def
/opt/CPR77CMP-R80.40/lib/table.def
/opt/CPR75CMP-R80.40/lib/table.def
/opt/CPNGXCMP-R80.40/lib/table.def
/opt/CPSG80CMP-R80.40/lib/table.def
/opt/CPR71CMP-R80.40/lib/table.def
/opt/CPSG80R75CMP-R80.40/lib/table.def

I used the first one as it seemed the obvious choice for R80 policy targets. Unluckily sk98339 is not updated to include R80.40 as management or R80.20 SMB as target yet.

Yours, Martin

P.S. If the question is "Why the hell do I want to disable SecureXL?" In my setup some services are not working properly. When I disable SecureXL to debug the connections, they start working. Unluckily I have not found a way to disable SecureXL permanently. When I do "fwaccel off" it turns itself "on" again after a few hours (I have no idea how or why).

P.P.S. Migrated from a 1470 with R77.20 to a 1550 with R80.20.5 about a week ago. This has been a lot more painful than expected. But I want to play with Layered Policies, so I have to go that way.

[PhoneBoy]

Believe the correct one for SMB devices running R80 is: /opt/CPSFWR80CMP-R80.40/lib/table.def

And yes, with the redesign of SecureXL IN R80.20, we don't allow permanent disabling of SecureXL any longer (applies to regular gateways too).
We consider things solved by disabling SecureXL to be bugs that need to be fixed.

[Martin_Seeger]

Hi,

yes, I would agree that those are things that are needed to be fixed. But I don't want to open two many SRs in parallel, so I was looking for a quick fix.

I take a look what happens when I use that table.de and will report here.

Thank you!

Yours, Martin

[Chris_Atkinson]

It may also be worthwhile testing with the latest Build 992001169 (refer sk164912).

[Martin_Seeger]

Thank you! 

I hadn't seen that a new version is out.

Unluckily the RSS-Feeds from SecureKnowledge is currently broken (SR 6-0001991921 is already open):  https://validator.w3.org/feed/check.cgi?url=https%3A%2F%2Fsupportcenter.checkpoint.com%2Fsupportcent...

Through the RSS feed I usually see every new version coming out (every changed SK generates an entry).

[G_W_Albrecht]

I would suggest the easy way from https://community.checkpoint.com/t5/SMB-Appliances-and-SMP/SecureXL-amp-CoreXL-on-SMB-devices/td-p/3...

[Martin_Seeger]

Yep, I had a similar "fix". But that felt very "hacky" to me. Furthermore with R80.20.05 SecureXL re-enables itself after a few hours, so I had to start a background process that would disable it automagically again.

At that point I created this thread, as wrestling for control with your own system is never a good idea ;-).

[PhoneBoy]

It's better to use table.def to disable SecureXL acceleration for traffic from a problematic host than disable it globally. 🙂

[Martin_Seeger]

Yes, that was the correct table.def

[Martin_Seeger]

Brute force approach at the moment:

# fw tab -t f2f_addresses
localhost:
-------- f2f_addresses --------
static, id 250
<00000000, ffffffff>

Will report on the effect later tonight.

[Martin_Seeger]

With the correct table.def my workaround is functional. SecureXL is "enabled" but my services are working. Managed to squeeze in a reboot to update to the newest firmware.

The hard part will be to remove the exceptions for SecureXL step by step and locate the real problems.