SecureXL on R80.10

[Viviana_Checa]

Hi everyone,

I want to ask you if it is recommended to have enabled secure XL R80.10, or what is the scenario in which it is beneficial to have activated this feature, which is enabled by default.

Could this feature be responsible for random connection issues between services that are connected on firewall interfaces?

I appreciate your valuable comments

Thanks

[AlekseiShelepov · Accepted solution]

I believe SecureXL is totally very much recommended on R80.10 (and previous versions). For commentaries and opinion from very experienced guys you can check these two comments from a recent thread:

1. Dameon Welch Abernathy 
2. Tim Hall 

SecureXL is a is a software acceleration product. It is a Fast Path (this term should be used among many firewall vendors) for traffic. Basically, if the most of traffic going this path, firewall will process it much faster, without checking each time all firewall rules.

When you have some additional blades enabled, traffic cannot always go via fast path.

A part from Admin Guide:

When SecureXL is enabled on a Security Gateway, some CPU intensive operations are processed by virtualized software instead of the Firewall kernel. The Firewall can inspect and process connections more efficiently and accelerate throughput and connection rates. These are the SecureXL traffic flows:

Slow path - Packets and connections that are inspected by the Firewall and are not processed by SecureXL.
Accelerated path - Packets and connections that are offloaded to SecureXL and are not processed by the Firewall.
Medium path - Packets that require deeper inspection cannot use the accelerated path. It is not necessary for the Firewall to inspect these packets, they can be offloaded and do not use the slow path. For example, packets that are inspected by IPS cannot use the accelerated path and can be offloaded to the IPS PSL (Passive Streaming Library). SecureXL processes these packets more quickly than packets on the slow path.

The goal of a SecureXL configuration is to minimize the connections that are processed on the slow path.

For a very detailed and technical description go to ATRG: SecureXL.

Some info can be also found in Best Practices - Security Gateway Performance and SecureXL Mechanism.

As for the second part, whether it is connected to random connection issues, it is really difficult to say without knowing more details about the situation. In general, I would say that SecureXL usually doesn't create issues with connectivity but it could be a reason of some in tricky or very specific situations.

[Viviana_Checa]

Thanks Aleksei for the information !

[Timothy_Hall]

You'll most definitely want SecureXL enabled; random connection issues can be caused by a lot of things. First step would probably be to enable TCP state logging to find out exactly why and how the connection(s) died: sk101221: TCP state logging.

If the problem seems to happen to a certain system's connections much more often than others, you can exonerate SecureXL as the cause of the problem by excluding all traffic to and from that system's IP address from being accelerated as described here: sk104468: How to disable SecureXL for specific IP addresses.   You may also see recommendations to just disable SecureXL completely with the fwaccel off command, but doing so can be risky on systems with more than 8 cores due to the potential performance impact.

Beyond that it will depend on the contents of the firewall logs and what blades you have enabled, output of the enabled_blades command run on the firewall would be helpful in that regard.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Kaspars_Zibarts]

https://community.checkpoint.com/people/thalld401179d-0d5b-369d-a0f2-387c3ef54533‌ - I've been looking / dreaming about tcp state log for years.. Have no idea how I missed this! Thanks heaps!

[Timothy_Hall]

Just noticed the SK has not been updated for R80+ Management; you can enable TCP state logging from the R80+ SmartConsole.  See this screenshot from my book:

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Pablo_Barriga]

Hello Tim do you think we need to tuning some configuration of Corexl or SecureXL

I used to take in consideration this SK .

Best Practices - Security Gateway Performance sk98348

Check Point solutions for improving the performance of Security Gateway:

• SecureXL - refer to sk98722 - ATRG: SecureXL
• CoreXL - refer to sk98737 - ATRG: CoreXL
• SMT (HyperThreading) - refer to sk93000 - SMT (HyperThreading) Feature Guide
• Multi-Queue - refer to Performance Tuning Administration Guide (R76, R77) and sk80940
• ClusterXL - refer to sk93306 - ATRG: ClusterXL R6x and R7x
• VPN - refer to sk105119 - Best Practices - VPN Performance and to sk104760 - ATRG: VPN Core

[Luis_Miguel_Mig]

Has TCP state logging any significant impact in performance with and without SecureXL?

Thanks

[Timothy_Hall]

TCP state logging does cause some extra logging overhead on the firewall, but I haven't seen it have a noticeable impact unless the new connections rate is very high.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Luis_Miguel_Mig]

Thank you very much Tim!

[Luis_Miguel_Mig]

I have just activated tcp state logging ( fwconn_tcp_state_logging set to 1)  in the standby member of a clusterXL high availability cluster and I have started to see loads of logs with SYN_SENT for mostly any session through our cluster.

I have checked the arp  and mac tables on clients, switches and fw and everything is okay, the cluster VIP is linked with mac of the active fw gateway and the switches and clients learn it well.

So why does the standby firewall log this? May this be a cosmetic issue related with the cluster session sync? Because I don't think the standby firewall is receiving those SYN packets through the network.

[Timothy_Hall]

Known issue, look a bit further down in sk101221: TCP state logging:

ClusterXL High Availability mode

In ClusterXL, by default, all members will send TCP state logs.

If you wish to configure Standby members in ClusterXL High Availability mode not to send TCP state logs, then a hotfix has to be installed on all cluster members.
This hotfix adds a new kernel parameter - fwha_only_active_send_logs - that controls which cluster member will send TCP state logs:

Parameter's Value	Explanation
fwha_only_active_send_logs=0	Default. All members (Active and Standby) send TCP state logs.
fwha_only_active_send_logs=1	Only Active member sends TCP state logs.

Follow these steps:

1. Contact Check Point Support to get a Hotfix that will add the required kernel parameters.
   A Support Engineer will make sure the Hotfix is compatible with your environment before providing the Hotfix.
   For faster resolution and verification, please collect CPinfo files from the Security Management Server and all cluster members involved in the case.

   This fix is already included in:

   • Check Point R80.10
   • Jumbo Hotfix Accumulator for R77.30 - since Take_15

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Luis_Miguel_Mig]

Thanks,

sorry I read it but I misunderstood it. I thought that you needed the hotfix if you wanted to sends only logs from the active gateway,  not that logs from the standby were confusing.

Thanks for the clarification.

[Viviana_Checa]

Thanks Tim for your help.. I will read the information listed on the post, and figure out what is the issue about  random connections losses!

[Vincent_Bacher]

I remember a time where in many support tickets the first suggestion from cp was to disable SecureXL

I think very interesting are the conditions that lead SecureXL to stop accelerating beginning at a rule with that conditions (sk32578).

Analyzing rulebases and modifying them according to this sk is very annoying

[Timothy_Hall]

Vincent you are referring to the rule base session rate acceleration (templating) portion of SecureXL, which was substantially improved in R80.10.  In this release the only rulebase conditions that stop templating are use of DCE/RPC services, certain rare complex services (i.e. http_mapped), and legacy authentication actions (i.e. User Auth, Client Auth).  However even if templating does get stopped by one of these conditions it does not impact the other portion of SecureXL which is throughput acceleration via the SXL and PXL paths.  In R80.10 the output of the fwaccel stat command now actually states this explicitly since this was such a common source of confusion.  See screenshot below from my book:

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Vincent_Bacher]

Hi Tim,

thanks a lot for your explanation. As i didn't dealt with SecureXL deeper in R80.10, this is really useful news.

And indeed good improvement!

[Timothy_Hall]

It is a great enhancement to SecureXL, however optimizing your policy for SecureXL templating isn't quite as important as it was in earlier releases due to the advent of Column-based Matching in R80.10 which in itself is quite an improvement in regards to policy evaluation.  The tl;dr recommendation to get the best gains from this feature is to avoid using "Any" in the Destination column in all your policy layers as much as possible, and secondarily avoiding "Any" in the Source and Service columns as well if you can.  More info: Unified Policy Column-based Rule Matching

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Craig_Dods]

@Tim

Just curious (haven't tested it myself yet) - if templating still functions when an L7 service is defined, does it act as the equivalent of cache (new applications will still match the original template, assuming 4-tuple is identical)?

[Timothy_Hall]

Hi Craig,

A great question, and I wasn't sure of the answer until I set it up and tried it.  Based on my preliminary findings it looks like the answer to your question is no, using a L7 service (like facebook or twitter) in your first policy layer appears to prevent SecureXL templating from being used at all.

I'd speculate this is because when allowing a connection by application instead of just by IP addresses and ports (as you would in a pure Network Access Policy Layer or the "Firewall" tab in R77.30), the firewall has to let the connection start (TCP 3-way handshake completion), and wait for actual data to begin flowing before an application determination can be made.  Pretty sure that SecureXL does not have the ability to do this, so the connection must be punted up into the Medium Path (PXL).  Dameon Welch Abernathy alluded to this behavior briefly here:  Unified policy - how is that connection really handled?  As a result SecureXL and its templating mechanism cannot make the final determination of whether to allow based just on IPs and ports, and I'd guess it simply does not attempt templating at all in that case.

After digging in some more however, it appears that the only situation that SecureXL can perform connection templating in R80.10 is if the first Network policy layer only has the "Firewall" checkbox set and nothing else.  After an upgrade from R77.30 all layers would start as ordered, and that first Network policy layer would only have the "Firewall" checkbox set as shown here:

In this case SecureXL templating will function assuming there is not something else precluding its use.  However it appears based on my lab test that once you check anything other than "Firewall" in this first policy layer, such as "Applications & URL Filtering" which allows you to potentially start selecting L7 applications in that layer, all SecureXL templating stops on the firewall, even if you are still only using service ports in that layer.

All of this is based on my preliminary and limited testing, but frankly I don't see a lot of reason for concern here because:

1) The entire point of SecureXL templating was to avoid laborious top-down, first-fit lookups in the Firewall rule base.  The new Column-based Matching helps avoid this (and it can be used in just about every policy layer type, not just the Network layer) and as such the use/optimization of SecureXL templating is just not nearly as important in R80.10 as it used to be in my opinion.

2) Everything mentioned above is only referring to SecureXL templating (connection rate acceleration) and NOT throughput acceleration (SXL,PXL,F2F paths).  Most everything ends up in at least PXL these days anyway as shown by fwaccel stats -s, and very little traffic can get completely handled inside SecureXL anymore with the typical blades enabled by a customer.

Perhaps Dameon Welch Abernathy‌ can chime in here with something a bit more official as this is all speculation on my part.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[PhoneBoy]

Observations from my own R80.10 gateway:

• I'm using inline layers (none of them shared) with FW + APCL/URLF + Threat Prevention selected in the top-level layer (some sublayers have FW-only selected)
• fwaccel stats shows Accept templates "enabled" with nothing disabling templates.
• There are plenty of SecureXL templates, but to Tim's point, every single one is marked with the following flags: Accounting (A) and Streaming (S), with practically all of my traffic being in Medium Path and almost nothing in the Accelerated path.

Unless you've got only Firewall blade turned on, I would expect nothing to appear purely in the Accelerated path anymore.

Of course, you should still be mindful of services that disable SecureXL Templates (Anything RPC-related comes to mind), but the number of things that disable SecureXL templates is much smaller in R80.10 than in past versions.

Further: you can put rules with those services in inline layers to minimize the impact on SecureXL Templates. 

[Timothy_Hall]

Right, what I'm seeing though is that once you enable anything other than "Firewall" in that first policy layer such as "Applications & URL filtering" fwaccel stat still reports Accept Templates: enabled BUT the templating rate (Accelerated conns/Total conns) reported by fwaccel stats -s just stubbornly sits at zero forever.  Perhaps I have something else going on in my Max Power lab setup here causing this behavior but I don't think so.  Also as noted in my book any traffic subject to Anti-bot in the Threat Prevention policy cannot be templated by SecureXL either, due to IP address reputation checks that have to occur in the Medium Path (PXL).  Anti-bot is disabled in my lab but I'm still seeing the zero templating behavior, SecureXL throughput acceleration via SXL/PXL/F2F is still fine though.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[PhoneBoy]

For me, the number of Accelerated conns/Total conns is also zero.

Which is probably a result of using the various blades, as you mention.

[Gaurav_Pandya]

Hi Tim,

Really great information you have provided specially for R80.10

[TheRealDiZ]

Hi guys,

Anyone know how to disable Throughput Acceleration?

I know there are some specific parameters that are currently disabling SecureXL per SecureXL Mechanism sk.

Actually I got issue with Azure VPN.

When I disable SecureXL putting for example RPC in the policy this change disable templating and the issue persists.

When I disable SecureXL with fwaccel off command the VPN is working fine.

Starting from this test I assume that throughput acceleration is causing the issue.

Obv for customer I cannot leave firewall with SecureXL completely disable.

What can I do?

That's why I'm asking if there is a way to disable throughput accel for a specific traffic flow.

BR

DIZ

[Timothy_Hall]

You can selectively disable SecureXL Throughput Acceleration for certain IP addresses, see sk104468: How to disable SecureXL for specific IP addresses

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Kamiar_Sh]

so as a result does anyone know why SecureXL blocks FTP trrafic on my R80.20 clusters? i fixed that issue when i installed hotfix but the issue came back since i have failover on clusters recently ?

i had to disable secureXL temporary