topic Re: SecureXL on R80.10 in General Topics

SecureXL on R80.10

Viviana_Checa — Mon, 29 Jan 2018 22:17:20 GMT

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

Re: SecureXL on R80.10

AlekseiShelepov — Mon, 29 Jan 2018 22:48:56 GMT

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:

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.

Re: SecureXL on R80.10

Timothy_Hall — Mon, 29 Jan 2018 23:35:23 GMT

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

Re: SecureXL on R80.10

Kaspars_Zibarts — Tue, 30 Jan 2018 10:06:50 GMT

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!

Re: SecureXL on R80.10

Timothy_Hall — Tue, 30 Jan 2018 13:24:28 GMT

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

Re: SecureXL on R80.10

Pablo_Barriga — Tue, 30 Jan 2018 14:01:59 GMT

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

Re: SecureXL on R80.10

Luis_Miguel_Mig — Tue, 30 Jan 2018 15:59:11 GMT

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

Thanks

Re: SecureXL on R80.10

Viviana_Checa — Tue, 30 Jan 2018 16:20:12 GMT

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!

Re: SecureXL on R80.10

Viviana_Checa — Tue, 30 Jan 2018 16:20:45 GMT

Thanks Aleksei for the information !

Re: SecureXL on R80.10

Timothy_Hall — Tue, 30 Jan 2018 17:19:27 GMT

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

Re: SecureXL on R80.10

Vincent_Bacher — Tue, 30 Jan 2018 21:53:08 GMT

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

Re: SecureXL on R80.10

Timothy_Hall — Wed, 31 Jan 2018 00:20:45 GMT

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

Re: SecureXL on R80.10

Vincent_Bacher — Wed, 31 Jan 2018 06:11:08 GMT

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!

Re: SecureXL on R80.10

Gaurav_Pandya — Wed, 31 Jan 2018 14:41:36 GMT

Hi Tim,

Really great information you have provided specially for R80.10

Re: SecureXL on R80.10

Luis_Miguel_Mig — Wed, 31 Jan 2018 14:58:16 GMT

Thank you very much Tim!

Re: SecureXL on R80.10

Timothy_Hall — Wed, 31 Jan 2018 14:59:49 GMT

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

Re: SecureXL on R80.10

Luis_Miguel_Mig — Wed, 31 Jan 2018 15:44:31 GMT

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.

Re: SecureXL on R80.10

Timothy_Hall — Wed, 31 Jan 2018 15:52:22 GMT

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:

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

Re: SecureXL on R80.10

Luis_Miguel_Mig — Wed, 31 Jan 2018 16:00:23 GMT

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.

Re: SecureXL on R80.10

Craig_Dods — Thu, 01 Feb 2018 20:54:32 GMT

@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)?