[FYI….this is work in progress just stream of consciousnesses. I’ll remove this label when I think I’ve got it straight.]
[UPDATE: 2/14/2014] I have spent several months putting together how SecureXL/CoreXL works, creating labs, talking to developers and people much smarter than me. I am putting together a class on the topic . I have to update this blog to reflect reality when I get time. Its probably about 75% correct…..
——————————————————
Ya know, I wish I could explain how SecureXL works but everytime I think I get it…I’m wrong. I’ve had several different CP people try to explain it to me.. and parts are wrong. So I’m not sure what to tell you. This will be my worst blog ever, but my goal is to spend my golden years trying to figure out how SecureXL works and fix this blog as I go.
You can stop reading now….
I was sent this document that does a great job of explaining SecureXL. But if its accurate who knows.
SecureXL How it worksL
For example: there is a statement in the SecureXL document that says any non-TCP/UDP/GRE rules will turn off all SecureXL. Well so much for ICMP I guess. But I think its wrong…. Acceleration is still turned on.
The basics you should remember.
SecureXL does two things…..
1) Accept Templates: Some protocols like HTTP 1.0 create MULTIPLE concurrent connections from a client to a single port on a single server, port 80. The rate of of acceptance by SecureXL is increased by caching these connections into a “template” connection table. After the first connection – any future ‘similar’ connections to the common port from that client are NOT forwarded to the firewall kernel, but instead instantly accepted and forwarded.
2) Connection Accelerated: SecureXL increases throughput on connections that have already been setup and inserted into connection table between a client and server. The successive packets in a connection will not go through the kernel but will be handled by interrupt handlers (watch your SI on ‘top’ command).
The following diagram was done by 51sec …..
Unfortunately SecureXL sometimes it feels like it only works if there is a full moon and NAT, VPN, IPS, and 100 other services are not enabled. If you do a fwaccel stat you will start to get feel of what is enabled…but I’m still leary. Also remember that fwaccel stats (with an ‘s’) is a totally different command.
Before you read the documenation you have to understand two things:
1) Accept templates/Connection templates/Connection accelerated: is overloaded. They are referring the grouped mainly HTTP traffic that creates templates in order to accelerate similar connections from 1 source PC. It is a ‘template’ because it intends to accelerate ‘similar’ traffic, not an exact connection.
2) Throughput acceleration: Connection table acceleration. Is to accelerate the second and subsequent packets of a connection. These packet have to perfectly match the connection table.
If you don’t know the difference between these two, the documentation will turn you around…
Below you can see the two commands, stat and stats. The stat command will tell you if connection templates #1 above is turned on and at what rule connection templates (not acceleration) is disabled, in this case rule #1 (by the red arrow) disables the creation of connection templates. This is what I wish I could tell you what the magic is, but I can’t I get different versions of reality. I know ICMP impacts because SecureXL was mostly designed just for HTTP connections grabbing 30 different pages from one client. The numbers in green list how many connections from templates of all connections are created and how many connections are going through the firewall kernel (F2F) for processing. You can see here that because rule #1 disables templates that 0 connection templates are created.
The second part below in red shows throughput acceleration from #2 above. “accel packets” is packets that are not forwarded to the firewall kernel and F2F are packets that are forwarded to the firewall kernel for rule processing. These are NOT the same as Accept Templates which are related to accelerating HTTP requests from a single PC. Only accelerating the second and subsequent packets from a single connection.
Just a little more detail here. This is the ‘fwaccel stat’ and the ‘fwaccel stat -s’ command.
You can see how the % of accelerated packets is calculated. Take the current total
connections (TCP and non-TCP) and subtract the F2F connections (slow-path, the ones
that got forwarded through the kernel and not handled by interrupt processing).
Kasper has figured out (THANKS!!!) that PXL is really PSL, Packet Streaming Library which Check Point uses for its IPS engine. It re-assembles IP packets so the IPS engine can inspect them (I have to update this diagram). You can read about it here.
How secureXL computes its counts
Little bit more of a deep dive here:
Why am I telling you this? Well, if for whatever reason you are wary of SecureXL (or don’t have a license) and decide to turn it off you can look at the before and after. You can also do you own ‘acceleration’ by moving the most hits rules to the top of the policy so they get hit first. You might have to use Tufin to figure out what the connection counts are on a per rule basis. CP also has some magic software where if you do a ‘fw tab -t connections’, they can tell you what rules are getting hit the heaviest.
And of course don’t trust SmartMonitor to report the right #’s. CP official policy is SmartMonitor is broke when SecureXL is turned on.
So sad. Just sharing the love here.
dreez
This is the “Oh YEAH…Aside from the marketing rah-rah, this is what will blow it up list”
These services prevent ACCEPT TEMPLATES from being created (Throughput acceleration is not inhibited by the presence of rules with these properties.)
• Service with a port number range
• Service type “other” with a match expression
• Service type RPC, DCOM, or DCE-RPC
• Service with “enable reply from any port” checked
• Source or destination is a domain or a dynamic object
• Time object associated with the rule
• Client or session authentication involved with the rule
• SYN Defender (the entire 3-way handshake must be supervised by the FireWall-1 application, slightly reducing the effect of connection-rate acceleration – most significant performance impact on short duration connections)
The following rule properties present in the security policy will disable throughput and connection-rate acceleration for all traffic.
• Rules with action “encrypt” on an interface that does not support cryptography
• Rules where the source or destination of the rule is the gateway itself
• Rules where the service has an INSPECT handler (e.g. FTP control connection)
• Rules with Security Servers or services with resources
Firewall Connection Rate, IP1260
• Rules with user authentication
• Rules for non-TCP/UDP/GRE/ESP connections (NOTE ICMP disables accept templates!!!, and it won’t be throughput accelerated)
Traffic Limitations
The following traffic is not throughput or connection-rate accelerated by SecureXL.
• Multicast traffic
• Directed broadcast traffic
• Traffic across an Access Control List-enabled interface
• Traffic whose Protocol field in the IP header is not TCP or UDP (e.g. ICMP, IGRP, etc.)
• IPv6 traffic
• VPN encryption algorithms that are not supported by the hardware.
• IP compression enabled for VPN traffic.
The following traffic is not connection-rate accelerated by SecureXL.
• VPN
• Complex connections such as FTP, H.323…
• Non-TCP/UDP connections
Environment Limitations
The following environment disables connection rate acceleration for the traffic that the environment is applied to by SecureXL.
NAT
FTP
VPN traffic
MORE REFERENCES:
Good Explanation from CPUG
DreezSecurityBlog 