Check Point uses various technologies to enhance performance of their firewalls. Two important techonologies are SecureXL and CoreXL. SecureXL provides packet acceleration, which ensures that not every passing packet has to be inspected by the CPU. CoreXL divides the firewall load across multiple processing cores. In this article, both technologies will be explained.
In this article the Check Point technologies SecureXL and CoreXL will be discussed.
To see if SecureXL is even enabled you can run the fwaccel stat command:
# fwaccel stat Accelerator Status : on Accept Templates : enabled Drop Templates : disabled NAT Templates : disabled by user NMR Templates : enabled NMT Templates : enabled Accelerator Features : Accounting, NAT, Cryptography, Routing, HasClock, Templates, Synchronous, IdleDetection, Sequencing, TcpStateDetect, AutoExpire, DelayedNotif, TcpStateDetectV2, CPLS, McastRouting, WireMode, DropTemplates, NatTemplates, Streaming, MultiFW, AntiSpoofing, Nac, ViolationStats, AsychronicNotif, ERDOS, McastRoutingV2, NMR, NMT, NAT64, GTPAcceleration, SCTPAcceleration Cryptography Features : Tunnel, UDPEncapsulation, MD5, SHA1, NULL, 3DES, DES, CAST, CAST-40, AES-128, AES-256, ESP, LinkSelection, DynamicVPN, NatTraversal, EncRouting, AES-XCBC, SHA256
The first line is important here. It will say enabled if acceleration is active. Often, a certain feature (blade) disables acceleration, such as IPS or Application Control & URL Filtering. In that case, the output of the above mentioned command could look like:
# fwaccel stat Accelerator Status : on Accept Templates : disabled by firewall Layer firewalllayer Security disables template offload from rule #238 Throughput acceleration still enabled. Drop Templates : disabled ...
Often, rules with specific services such as X11 or AD cannot be accelerated, causing this message.
CoreXL is a fancy name for multicore processing by Check Point. It is usefull for enhancing performance on Security Gateways or VSX gateways with multiple CPU cores.
Note that CoreXL only works for packets taking the slow or medium path, fully accelerated packets are NOT handled by an CoreXL firewall instance.
The basis CoreXL architecture is straighforward. There are two roles:
- The Secure Network Distributor (SND) is the 'captain', the SND core processes traffic from the interface and distributes packets to CoreXL FW kernels. The exception is traffic that can be accelerated by SecureXL, which is handled by the SND itself.
- The CoreXL FW instances are the 'workers'. These cores handle traffic that they get from the SND (Slow and Medium Path).
In R77.20 and lower versions, the distribution of traffic happens statically based on packet properties such as Source/Destination IP and IP protocol type. This can lead to an inbalance in load among the cores. Newer versions therefore use dynamic distribution based on the load of the worker cores. Note that only from R80.10 onwards, dynamic distribution is enabled by default. Also, for VSX dynamic distribution is not supported at all.
The command to check which cores are SND cores and which are workers is fw ctl affinity -l. When using VSX, this command must be executed from the VS0 context. For example:
[Expert@fw1:3]# vsenv 0 Context is set to Virtual Device fw1 (ID 0). [Expert@fw1:0]# fw ctl affinity -l -r CPU 0: Mgmt eth3-01 eth4-01 CPU 1: Sync eth4-02 CPU 2: CPU 3: CPU 4: CPU 5: CPU 6: CPU 7: All:
This is a 8 core machine with two SND cores running on processor #0 and #1. All other cores can assume the role of firewall worker. As this is VSX, these are divided among the virtual systems. In newer versions, the number of worker cores can be specified in the GUI. In VSX, firewall worker cores run in user space and not system space.