SecureXL Fast Accelerator - Need to clarify packet flow

[CheckPointerXL]

Hi all,

taking a look to this packet flow:

From the diagram I understand that if i put a rule in the fast accelaration table, not explicitally permitted in the rulebase, it is accepted.

Well, I just did a test, allowing A->B in the fast accel table, but it was dropped by clean up in the rulebase.

Only allowing connection in rule base, let it hit the Fast Accel Table

Anyone can clarify this? So first connection have to be checked in rulebase like traditional secureXL ?

thank you

[genisis__]

A rule would still be required in the FW blade, but if you have additional security blades enabled (example IPS/AV/ABOT), these would be by-passed; in the logs you would simply see a entry indicating the traffic was fastaccel.

It's one of the reason only trusted traffic should be added, and keep in mind there is a limited number of rules you can add to fastaccel table.

The above is my understanding, happy to be corrected.

[CheckPointerXL]

hi Genesis,

Thank you for your reply. 

Of course i Agree the way you described which correspond with the result of my lab test.

What i can't understand is that diagram (and the ones found in sk156672 too). Waching them I think is clear that Fast accel table is something with no relation and to an upper level from the rulebase.

Definitively, it seems both are not pertinent with how FW works.

Any speech is appreciated

[Timothy_Hall]

Starting in R80.20, the first packet of every new connection goes to a worker instance for an Accept Template check and if there is no matching template, a Firewall/Network Layer rulebase lookup happens next.  If the connection is accepted by the template/rulebase and fast_accel is present for that connection's attributes, the connection is usually reinjected back into SecureXL for subsequent handling in the accelerated path.  This reinjection can also happen for a non-fast_accel'ed connection that does not require any deep inspection handling; fast_accel just makes this much more likely.

Note that if there is an inspection condition present that requires use of the F2F/slowpath handling for that connection, the fast_accel will not be applied even if present and the connection will still go F2F on a Firewall Worker.

[PhoneBoy]

Keep in mind that diagram is not an official diagram.

“Fast Accel” specifically impacts the decision to send something to PXL/Medium Path.
Anything that matches a Fast Accel rule that would normally go to the PSL/Medium Path instead goes to the Accelerated Path.
Traffic can still hit the F2F/Slow Path for other reasons.
And, in all cases, you still need to have an Access Policy rule that permits the traffic.
And, as noted elsewhere, you should only Fast Accel trusted connection flows.

[HeikoAnkenbrand · Accepted solution]

Hi @CheckPointerXL 

It is not possible to create a packet flow overview with all paths. You are right. "Fast Acceleration Rules" only work for allow packets. This is a schematic overview in my article R80.x - Performance Tuning Tip - SecureXL Fast Accelerator  (R80.20 JHF103+)

It is also important whether it is the first package or a subsequent package. "Fast Acceleration Rules" only work for subsequence packets which are normally sent to PSLXL path (medium path). If "Fast Acceleration Rules" are used, the packets are sent to the acceleration path and not to the PSLXL path.

[HeikoAnkenbrand]

I have corrected it in the following articles:
- R8x - Security Gateway Architecture (Logical Packet Flow)
- R8x - Security Gateway Architecture (Logical Packet Flow) - Update R80.20+
- R8x - Performance Tuning Tip - SecureXL Fast Accelerator  (R80.20 JHF103+)

[CheckPointerXL]

Hi @HeikoAnkenbrand @PhoneBoy @Timothy_Hall ,

thank you for your precious feedback. 

I think now is more difficult to mislead who is approaching 'fast accel' in detail.

Best regards