Impact of disabling secureXL with fwaccel off command on a Virtual System

[KostasGR]

Hello Community

What is the impact of disabling secureXL with fwaccel off command on a Virtual System?

We want to disable it as a workaround until we will install a JHF for r81.10.

BR,
Kostas

[PhoneBoy]

You're better off doing something like: https://support.checkpoint.com/results/sk/sk104468
Or even use fw fast_accel: https://support.checkpoint.com/results/sk/sk156672

Note that sometimes SecureXL does cause issues with certain flows .
Preventing that traffic from being templated can be useful as a workaround/troubleshooting step.
You can't really disable SecureXL anymore, fwaccel off only globally disables templating new connections.

[Fabz]

sorry jump in @PhoneBoy im also looking for the answer about fwaccell off.

may i know what you mean about this: "You can't really disable SecureXL anymore, fwaccel off only globally disables templating new connections"?
Thanks!

[HeikoAnkenbrand]

Take a look at the following articles from me, where I have described everything in more detail:
- R8x - Security Gateway Architecture (Logical Packet Flow)
- R8x - Security Gateway Architecture (Logical Packet Flow) - Update R80.20+
- R8x - Security Gateway Architecture (Content Inspection)

The SecureXL driver is no longer deactivated with "fwaccel off" from R80.20 and higher.

Permanent disabling of "fwaccel off" is not supported according to Check Point.
I was told this several times by support.

[Fabz]

Im studying SecureXL and Core XL.

just curious, may i know the reason why CP disabled "fwaccel off"? for security purposes or more in performance? a few weeks ago i disabled secureXL for tshoot purposes and the performance suddenly increase.

edit : will open a new discussion. sorry for jump into other user thread

[Timothy_Hall]

SecureXL was significantly revamped in R80.20, which accounts for the behavioral changes of fwaccel off.  The big change is that in R80.20+ the first new packet of every connection ALWAYS goes to a worker/instance core.  This did not used to be the case prior to R80.20, where matching an Accept template in sim/SecureXL itself could authorize the connection and it would never touch a worker/instance core if it could be handled in fastpath.

When the new connection's first packet passes through sim/SecureXL and hits the worker core, it first checks if the connection matches a previously-created Accept template; if not it performs a full firewall/network rulebase lookup in slowpath/F2F.  If the connection is allowed, an Accept template  is created to potentially match future substantially significant connections.  Next the worker core looks at what level of inspection will be required for this connection, and determines which path the connection should use for the rest of its duration: offload into fastpath, offload into medium path, or remain in F2F/slowpath.  In my Gateway Performance Optimization Class we run a special debug to observe precisely why the worker core selected a certain path; very useful to determine exactly why certain connections seem to always be doomed to the F2F/slowpath.

With all that said, when you run fwaccel off here is what happens in R80.20+:

• Accept templates are not checked nor created
• Full firewall/network policy lookup is always performed on the worker cores
• Offload decision for all NEW connections is always remain F2F/slowpath
• Existing connections stay in whatever path they were in before, and do not suddenly start going F2F/slowpath like they used to prior to R80.20

Performance should not improve when you run fwaccel off, unless you have an insufficient number of SND cores which are choking on a large amount of fastpath traffic; when fwaccel off is run all new connections will go F2F/slowpath which the Dynamic Dispatcher will evenly distribute among multiple worker/instance cores.