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:
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)
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 “