Fast_Accel on Virtualized Firewalls

[JenniferYado]

Hello everyone,

I'm working on a network lab environment virtualized on ESXi, where I have two SGs (sg1 and sg2) connected via a route-based S2S VPN. 

Both firewalls are running R81.20 JHF 76.

I have connectivity between both servers.

These are the static routes on sg1 on the left and sg2 on the right.

One of the goals of the lab is to test the fast_accel feature. According to the official documentation, this feature should be effective for connections accelerated by SecureXL, and the connections should appear in the fwaccel conns command.

To test this, I have created two rules with fast_accel on both firewalls (sg1 and sg2), as my research suggests that this should be sufficient for the rules to match the traffic between ubuntu1 and ubuntu2.

 "I created the rules with the following commands on both firewalls:

• fw ctl fast_accel add 192.168.22.20 192.168.21.20 any any
• fw ctl fast_accel add 192.168.21.20 192.168.22.20 any any

However, even though I'm generating traffic between the two servers using iperf3, I don't see any hits on the accelerated connections.

Can anyone provide guidance on what might be going wrong or if there's something additional I need to configure for the fast_accel rules to be applied correctly?

Thanks!

[Timothy_Hall · Accepted solution]

Whether the gateway is virtualized or on "bare-metal" non-virtualized hardware will not affect how fast_accel operates.

Based on your fwaccel conns outputs the connection is already in the fastpath because the "S" flag (streaming) is not present.  If the connection was F2F/slowpath it would not show up in the output of fwaccel conns at all.

Because the connection would have been offloaded to the fastpath regardless of your fast_accel rule, the hit count is not incremented.  If the connection was originally destined for the Medium Path but the fast_accel rule had forced it into the fastpath, then the hit count would have been incremented and you would see an "F" flag for your connection in fwaccel conns.  See sk180496: No match on SecureXL Fast Accelerator (fw fast_accel).  F2F/slowpath connections cannot be forced into the fastpath by fast_accel.

All this and much more is covered in my Gateway Performance Optimization course; you can preview the Table of Contents for free and this topic was covered on pages 149-151.