Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Wolfgang
Authority
Authority

performance optimization via "SecureXL Fast Accelerator"

Hello CheckMates,

I want to get safe with my understanding of the 

SecureXL Fast Accelerator 

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

0 Kudos
9 Replies
_Val_
Admin
Admin

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. 

lolith
Participant

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

0 Kudos
Timothy_Hall
Legend Legend
Legend

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
lolith
Participant

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

0 Kudos
Timothy_Hall
Legend Legend
Legend

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-forw...

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Timothy_Hall
Legend Legend
Legend

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

bang.jpgWhile 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.

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Wolfgang
Authority
Authority

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

0 Kudos
Timothy_Hall
Legend Legend
Legend

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.

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Wolfgang
Authority
Authority

@Timothy_Hall  👍😊

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events