For anyone who wants to permanently disable securexl in R80 versions

[the_rock]

Hello everyone,

I know this is not officially supported by CP, but if you want to PERMANENTLY disable securexl in R80.xx, all you have to do is this (if its a cluster, obviously do on both members and it does survive a reboot):

From expert mode -> cd /etc and then vi rc.local

Just add a single line at the bottom containing fwaccel off and save the file and thats it!

Cheers!

Andy

[PhoneBoy]

To be clear, this is only relevant for R80.20 and above where we removed the ability to disable SecureXL, which we generally do not recommend in currently supported versions of code.
If disabling it solves an issue you have, it should be brought through the TAC so we can find and fix the relevant bug.

[HristoGrigorov]

It is possible that content of /etc/rc.local is reset on upgrade. But if you look into its code you will notice there is a special file designated for user changes that will liekly be preserved between upgrades:

if [ -f /etc/rc.d/rc.local.user ]; then
. /etc/rc.d/rc.local.user
fi

[the_rock]

Hi Hristo,

I had bedn modifying that file from R60 and never an issue. In my experience, the content never got reset.

[the_rock]

All TAC can really do is open a task with R&D and those go on forever and ever without any solution :). I cannot count number of customers that I talked to who simply give up on CP support trying to give them logical sxl solution. I even personally know few escalation folks who are worried giving sxl degug, as it can cause firewall crash. I really wish CP would get their act together and fix secure xl problem once for all. Its something that has been happening consistently since probably R55.

[PhoneBoy]

Even so, disabling SecureXL is the thermonuclear option and will significantly decrease your overall performance.
Many issues are with specific flows, which can be disabled for those flows versus globally. 
Examples of specific SRs sent via PM/email will be helpful. 

[the_rock]

Dameon, you work for the company, you can see many cases about it, just ask R&D. Its CP escalation people telling customers to dosable sxl, as Im sure they are sick of dealing with it 🙂

[Dorit_Dor]

Historically, your claim is correct... but in the past few months this is no longer the case (with recent jumbo’s of r80.30/.40).
In fact we asked to be notified proactively in any case that someone at CP gave disable sxl as solution and we treat it as alarming case.

last, as we run the vast majority of GWs with SXL, we now start to see issues in cases ppl disables SXL that cause bad experiences beyond performance.

I welcome checkmates to share with me and Dameon recent tickets / cases that still represent this handling and we may have missed them.  We will take each case very seriously with minimal customer interference hoping to eliminate 100% of such cases. 

tnx
Dorit

[the_rock]

Dorit,

With all due respect, my claim is 100% true and there are soooo many examples of it, just search your internal R&D database with sxl tasks, Im sure you will get tired of seeing how many tasks there are about it. By the way, I recall back in R60, CP support kept saying sxl will be better in R65 (which it was NOT), then in R70 (which it was NOT), R75 (same thing), R76 (probably the worst ever), R77 (okay, little improvement) and now in R80, its  a HOT MESS. What I dont personally understand is why you guys keep pushing this lie that securexl is so wonderful and it works well, well its not true and check point knows that, but are you too proud to admit it does not work right? I mean, any honest person/business would admit a mistake and fix it (isnt that what any customer would expect anyway?), rather than making these jumbo hotfixes and saying that there are sxl fixes in them (another lie clearly). 

Its truly a shame, because you have a decent product, but this problem, in my opinion, will NEVER be fixed properly, because you guys had 15 yeats to fix it and it never happened. To say it works in R80.40, no it does NOT, because I dealt with dozens customers who had really bad traffic issues/slowness when sxl was on and even TAC told them to keep it disabled, because it would take long time for R&D to find a fix. Im sorry, but if your own employees know sxl is bad, I think I rest my case :).

[Dorit_Dor]

Your claims are correct on all historical cases.

So what changed between 15 years and the last year? 
Up until r80.20 the sxl code and the main flow were not exactly the same. In r80.20 as part of integration of many performance related items, we integrated the exact same code on the two flows (in fact we had initially few issues caused by the fact that we changed the sxl code to be exactly the same as the main flow).

To give a numeric example: by Q4 2019 we still had two cases that were “known” to require to disable SXL post R80.20 code. We correct them when we find them. 

You are also correct that there are still cases that CP employees (from multiple organizations) are disabling SXL as a way to diagnose (Under “fire“) but ttbomk they are driven by historical diagnostic issues and not by real rational. I assume it will take us very long to eliminate these practices. The fact its used doesnt prove that its the best approach. We are trying to improve The diagnosis practices as well. 

I am going to hold additional review internally of all known cases (we do that from time to time) and i will share more data in this thread in the coming weeks, to help convince the skeptics... and for transparency.  

But regardless, i do invite everyone that believe they need to run SXL disabled permanently (with recent R80.30 and R80.40 jumbo‘s), to share the case with us so that we can close the loop on any such cases. 
if there are cases that still require sxl off that will come to my knowledge, i will share them here as promised

[the_rock]

Thank you Dorit, transparency is always important. Just to comment, I am positive there are lots of customers out there that dont even report this issue any longer, because they simply feel its a waste of time (I even had customers tell me that). Dont you guys realize how frustrating it is waiting for a solution from R&D for months on end and getting fed lies and excuses just to delay the resolution? Please put yourself in a place like that, trust me, you would not like it either.

Anyway, I will leave it at that...I want to be positive that one day I will wake up and securexl will not be an issue, but the results and past experience tell a different reality.

Take care and be safe!!