topic Re: performance optimization via "SecureXL Fast Accelerator" in Firewall and Security Management

performance optimization via "SecureXL Fast Accelerator"

Wolfgang — Thu, 13 Feb 2020 09:36:40 GMT

Hello CheckMates,

I want to get safe with my understanding of the

If I define a network, host, port or anything possible via the "fw ctl fast_accel" command, these matching packets are going straight the fastest path with no deep inspection ?

Meaning no AV, no AB, no IPS, no URLF, no APPCL, no service inspection, no TP etc. will be done for these packets regardless if these blades are enabled ?

Wolfgang

Re: performance optimization via "SecureXL Fast Accelerator"

_Val_ — Thu, 13 Feb 2020 10:48:53 GMT

Your understanding is correct. Here is the quote from SK: "The Fast Acceleration feature lets you define trusted connections to allow bypassing deep packet inspection".

If there is part of the traffic which can be trusted by definition, you can then bypass deep inspection for such traffic altogether.

Re: performance optimization via "SecureXL Fast Accelerator"

Timothy_Hall — Thu, 13 Feb 2020 13:20:37 GMT

What Val said. A warning from the third edition of my book about fast_accel:

While using the fast_accel feature ensures highly efficient handling of the
matched traffic in the SXL path, doing so ignores portions of your security policy and
can disable almost all firewall inspection of that traffic. As such a variety of bad things
can happen inside traffic streams that have been essentially whitelisted by this feature,
and a careful risk analysis is necessary before using it. It is NOT RECOMMENDED to
use fast_accel if one or both of the systems involved are not trusted and/or under your
organization’s direct administrative control.

As discussed in my CPX 2020 speech Big Game Hunting: Elephant Flows, typically fast_accel is used in the context of elephant flows (heavy connections) to make them go faster and keep from stomping on "mice" connections. Note that there is an alternative solution from R&D that allows the processing/handling of elephant flows to be "spread around" more than one worker core, thus allowing them to go faster without limiting inspection of them with fast_accel. See my preso for more details about this new feature and how to contact R&D to obtain it.

Re: performance optimization via "SecureXL Fast Accelerator"

Wolfgang — Thu, 13 Feb 2020 14:01:57 GMT

Thanks @Timothy_Hall and @_Val_ for your reply.

I'm aware of the risks. We want to use this for some hosts they did storage and database replications.

Wolfgang

Re: performance optimization via "SecureXL Fast Accelerator"

Timothy_Hall — Thu, 13 Feb 2020 14:38:36 GMT

I knew you were aware of the risks, but I feel duty-bound to bring them up whenever fast_accel is mentioned for those who might read this thread later.

Re: performance optimization via "SecureXL Fast Accelerator"

Wolfgang — Thu, 13 Feb 2020 14:45:52 GMT

@Timothy_Hall 👍😊

Re: performance optimization via "SecureXL Fast Accelerator"

lolith — Wed, 16 Mar 2022 19:33:37 GMT

Hi,

Just one query on this. If we put an exception for a particular traffic to bypass all deep inspection blades (AV, AB, IPS, URLF, APPCL,) in TP policy , would we still need to consider putting that traffic under fast_accel? Or after putting this exception, that traffic should always go accelerated path.

Reason: When doing fwaccel conns, we don't see that exception traffic as PXLSL. However, when we put that in fast_accel table, we see significant improvement of traffic flow.

Regards,

Lolith

Re: performance optimization via "SecureXL Fast Accelerator"

Timothy_Hall — Wed, 16 Mar 2022 23:32:06 GMT

It will depend heavily on which blades you have enabled.

While you can easily exclude all TP enforcement with a "null" TP profile in an explicit TP policy rule, guaranteeing this in an Access Control policy layer with APCL/URLF is much tougher. You cannot define an explicit rule in an APCL/URLF layer that is equivalent to a TP null profile rule. Essentially the traffic must "fall off" the end of the APCL/URLF layer/sub-layer and hit the implicit cleanup rule of Accept to help ensure it will be fully accelerated. fast_accel can make sure that this occurs for traffic that would otherwise go PXL/Medium Path, but always remember that traffic requiring CPAS or F2F handling cannot be forced into the fully-accelerated path with fast_accel.

Re: performance optimization via "SecureXL Fast Accelerator"

lolith — Thu, 17 Mar 2022 10:02:40 GMT

We only have IPS blade enabled and that was the whole confusion around this. How come the null profile is not making sure that the traffic is going through fast path. In my experiance the traffic flow improved after we put that explicity under fast_accel table.

Any explanation for this behaviour? Note, we are running R80.40 with latest jumbo take.

regards,

Lolith

Re: performance optimization via "SecureXL Fast Accelerator"

Timothy_Hall — Thu, 17 Mar 2022 16:10:12 GMT

Probably lots of CIFS/microsoft-ds traffic which will almost always go Medium Path unless forced into full acceleration. See here:

https://community.checkpoint.com/t5/General-Topics/First-impressions-R80-30-on-gateway-one-step-forward-one-or-two/m-p/72593