SecureXL Process Details

SecureXL is a patented technology consisting of a software package with an API for the acceleration for multiple, intensive security operations. In addition to the IPS, SecureXL also accelerates operations carried out by a Stateful Inspection firewall from Check Point. Through the SecureXL API, this firewall can offload the handling of those operations to a special module, the “SecureXL device,” which is a performance-optimized software module.

In a SecureXL-enabled gateway, the firewall first uses the SecureXL API to query the SecureXL device and discover its capabilities. The firewall then implements a policy that determines which parts of what sessions are to be handled by the firewall, and which should be offloaded to the SecureXL device. When new sessions attempt to get established across the gateway, the first packet of each new session is inspected by the firewall to ensure that the connection is allowed by the security policy. As the packet is inspected, the firewall determines the required behavior for the session, and based on its policy it may then offload some or all of the session handling to the SecureXL device. Thereafter, the appropriate packets belonging to that session are inspected directly by the SecureXL device. The SecureXL device implements the security logic required for further analysis and handling of the traffic. If it identifies anomalies it then consults back with the firewall software and IPS engine. In addition, SecureXL provides a mode that allows for connection setup to be done entirely in the SecureXL device, thus providing extremely high session rate.

SecureXL in Multi-core CPU Minimizes Performance Hits to Integrated IPS

That is from Checkpoint “Solving the Performance Hurdle for Integrated IPS”

More explain from https://www.cpug.org/forums/miscellaneous/10418-securexl-templates-rulebase.html

“People like to get all confused over templates. I explain it thus (and btw, this is a long version of what Jim and PhoneBoy said):
First of all you have to understand that SecureXL is either a hardware or software layer that can forward packets faster than the firewall kernel, either because it’s optimised efficient code in the gateways operating system (i.e. perf pack, or Nokia IPSO) or because it’s a network processor based hardware card.
SXL templates accelerate TCP connection setup by reducing the time it takes to forward the initial SYN, SYN-ACK, ACK packets. This gives you higher connection establishment rates which is important if your taking a large number of HTTP connections. It can do this by creating a ‘template’ within the SecureXL module that matches the accept rule in the rulebase.
When a TCP connection comes in, there is no need to send the three way hand shake packets via ‘slow path’ to the firewall kernel. It gets sent ‘fast path’ through the SXL device and so you get fast TCP session establishment and high connection setup rates.
Any protection, such as security server, or syn defender, that requires the three way handshake to be inspected by the firewall kernel (F2F – forward 2 firewall) will disable templates, hence we worry here about syndefender.
Once the three way handshake is complete, templates no longer have any bearing on the performance of the connection. SXL, accelerates the rest of the packets, providing that there is no need for the firewall kernel to inspect them. There are are smartdefense protections which selectively disable SXL acceleration. Examples of this would be the ASCII ONLY HTTP RESPONSES which disables acceleration of the the server to client (S2C) side of the TCP connection. You then have one side of the connection being forward by the SXL device, and the other side being forwarded by the firewall kernel. It seems weird, but it’s normal.
Other protections are less specific, for example, TCP sequence verification. This protection requires that the firewall kernel inspect EVERY TCP packet, and so you have no SecureXL acceleration for ANY TCP connection (I should mention that I used that as an example, i believe that the TCP sequence verifier is implement in Performance Pack now as well).
So, to come back to your question, the list of supported features details the type of features that are compatible with regular SXL acceleration (that is forwarding the packets after connection setup).
The list of unsupported features lists those features that would disable SXL templates.
The only reason to make changes to your configuration to make templates work would be because you need a high connection setup rate.

Oh and for fun:
fwaccel ver
FireWall-1 version: NG with Application Intelligence (R55) HFA_08 for IPSO 3.8, Hotfix 833 – Build 004
Acceleration Device: Nokia IPSO
Accelerator Version 1.0
FireWall-1 API version: 2.12NG (16/10/2003)
Accelerator API version: 2.12NG (16/10/2003)
fwaccel stat
Accelerator Status : on
Templates : disabled by FireWall-1 starting from rule #855
Accelerator Features : Accounting, NAT, Cryptography, Routing,
HasClock, Templates, VirtualDefrag, GenerateIcmp,
IdleDetection, Sequencing, TcpStateDetect,
AutoExpire, DelayedNotif, McastRouting “