R80.x - Performance Tuning Tip - SecureXL Fast Accelerator (fw ctl fast_accel)

[HeikoAnkenbrand]

The Fast Acceleration (picture 1 green) feature lets you define trusted connections to allow bypassing deep packet inspection on R80.20 JHF103 and above gateways. This feature significantly improves throughput for these trusted high volume connections and reduces CPU consumption.

The CLI of the gateway can be used to create rules that allow you to bypass the SecureXL PSLXL path to route all connections through the fast path.

Tip 1

Use this function to exclude IP's or networks from deep inspection.

Picture 1

Here you can see the complete packet flow in detail : R80.x - Security Gateway Architecture (Logical Packet Flow)
I will update the document  to this new function in the next few days.

Feature Attributes:

• Configured from the gateway's CLI.
• Can be turned On / Off, Off is the default.
• Rules can be added / deleted by demand.
• Configuration (State / rules) survive reboot.
• Maintain rule hit count (does not survive reboot).
• Every configuration change done by the user is logged in $FWDIR/log/fw_fast_accel.log file.

Feature Usage:

fw ctl fast_accel <option>

Option	Explanation
add	Add a connection
delete	Delete a connection
enable	Set feature state to on
disable	Set feature state to off
show_table	Display the rules configured by the user
show_state	Display the current feature state
reset_stats	Reset the statistics collected by the feature
--help/-h	Display help message

To create fast_accel rules, read more in this sk156672 - SecureXL Fast Accelerator (fw fast_accel) for R80.20 and above.

[Kaspars_Zibarts]

I just wondered if it would be possible to arrange a webbinar regarding fast acceleration feature 🙂 by someone who understands it inside out 🙂

[_Val_]

Got it. Let me see what we can do here

[genisis__]

That would be a really good idea.

[haomeister]

Hi community,

Does the command take destination port range or "any" as parameter?

Thanks in advance.

[Wolfgang]

"any" is possible and a list of ports like "443,4434,445". I'm not sure if a range like "400-450", never tried

SecureXL Fast Accelerator (fw fast_accel) for R80.20 and above 

[HeikoAnkenbrand]

As far as I know, no range is possible.

[Timothy_Hall]

Just checked this on R81.10 Jumbo HFA Take 30, and ranges are not possible with any parameter including port number.  You also can't specify more than one destination port or IP address in a single add operation with a comma or any other character from what I can see.

[HeikoAnkenbrand]

For logs see:

sk173324 - Drop log for connection that is accelerated by fast_accel

[Václav_Brožík]

How do you understand these statements from the Introduction section of sk156672 - SecureXL Fast Accelerator (fw fast_accel) for R80.20 and above?

• Fast Accel enforces only rule base that does not require deep packet inspection (For example: Application Control, URL Filtering and content-awareness are not included).
  For the other cases: Fast accel rules are prioritized over the access rule base.

Do you think that the writers of the SK meant that fast_accel makes the firewall to skip deep packet inspection listed (For example: Application Control, URL Filtering and content-awareness)?

What could they mean by "the other cases"?

I guess "Fast accel rules are prioritized over the access rule base." could mean that fast_accel overrides the deep packet inspection by skipping it.

Unfortunately I do not have a good experience with the "Give us feedback" function in the SK.

* Sometimes they give some additional information by email but they do not modify the SK.

* Once they even asked me what they should put into the article when I needed Check Point's opinion.

[_Val_]

You said: "I guess "Fast accel rules are prioritized over the access rule base." could mean that fast_accel overrides the deep packet inspection by skipping it."

This guess is correct, fast_accell allows bypassing medium path, accelerating specific traffic through SecureXL only even if the policy requires any kind of deeper inspection.

[Timothy_Hall]

Traffic that would otherwise be processed in the Medium Path (both passive & active streaming) can be forced into the accelerated path with fast_accel.  Traffic that would normally go F2F cannot be forcibly accelerated in this way.

[aeronl12]

Hi,

Since the fast_accel traffic is bypassing the deep packet inspection. Does it mean, that when its policy is using for example Application Control, URL filtering or Anti-Virus. It will not filter by the following blades that requires deep packet inspection?

How do you determine the rule base which does not need deep packet inspection.

Thank you.

[Timothy_Hall]

Correct, even if the policy is calling for some form of deep inspection via APCL/URLF/AV if that traffic is fast_accel'd it won't occur.  As such fast_accel should only be used between somewhat trusted systems, and should most definitely NOT be used for traffic communicating with untrusted areas such as the Internet.

[Dale_Lobb]

I thought it was the other way around, that the connection had to already be excluded from IPS, HTTPS and other types of inspection or fast_accel would not work on it.  At least, that seems to match my recollection for setting it up on R80.40 a couple of years ago: We had to write exception rules for IPS and HTTPS inspection to exclude the connections, along with the fast_accel rules, or they would not be accelerated.

[Timothy_Hall]

What you are remembering is that F2F/slowpath traffic cannot be forced fathpath with fast_accel.  You can configure it but it simply will not work.  Traffic that would otherwise go Medium Path Active Streaming (HTTPS Inspection mainly) and Medium Path Passive Streaming (most blades) can most definitely be forced to the fastpath with fast_accel.