FW_ACCEL traffic not acceleration

[Elbis]

Hey guys!

I need help.
I have been trying to add this traffic to fast_accel, it is backup transfer traffic.
See below:

I don't understand what this connection would be (........................) without any flag marked.
I created a rule to run a test with iperf3 and it worked perfectly.

[the_rock]

Whats src/dst?

Andy

[Elbis]

Are you asking what type of solution or application is at the source and target?

If so, on the source Spectrum Protect Plus (IBM) and on the target Storage Dell.

[the_rock]

Hey,

Apologies, should have clarified. I meant what is source IP and what is destination IP?

Andy

[Lesley]

You should see the F flag:

• In the output of the SecureXL command "fwaccel conns", connections that are accelerated based on a Fast Acceleration rules are labeled with the "F" flag (R81 and higher).

Now it shows the L flag:

L - Shows connections, for which SecureXL created internal links.

That is why it is not passed via fast accel 

[the_rock]

Good point.

[Lesley]

Follow this SK btw for fastaccel:

https://support.checkpoint.com/results/sk/sk156672

• Fast Accel enforces only rulebase 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.

Maybe if you did the exclusion from inspection blades correct, it is still stuck in secureXL.

You could turn off and on fwaccel off -> fwaccel on

[Elbis]

Ok, I got it.
I had read this SK several times.
I made an exception rule in the IPS policy, it is the only blade we have enabled. But she's not at the top of the table, I don't know if that could influence her.
In any case, outside of firewall production hours I will execute the command fwaccel off -> fwaccel on.

I'll bring you new news later.

[the_rock]

I dont believe order matters.

Andy

[Lesley]

For test change your IPS rule. The one where you defined the profile.

Now you should have something like this:

source

dest

services (any)

profile

Change services to ALL (any) BUT 9020. Right click on it to make exclusion (red cross).

Test with that then for 100% sure it will bypass IPS inspection. 

[Elbis]

I'm not sure I understand 100%.

see my rule is like this:

Thank you very much for the help!!

 

[Lesley]

put tcp 9020 in the services and right click on it to exclude it

Rule will hit ALL services BUT 9020

[the_rock]

You may need to make similar rule for inspection settings as well, but most people never change it from default, so its possible may not even apply in your case.

Andy

[Timothy_Hall]

The fact that the connection appears in the output of fwaccel conns and there is not an "S" flag shown indicates that the connection is fastpath already.  Because the original offload decision for the connection was to the fastpath anyway, the hit count on your fast_accel rule will not be incremented, nor will an "F" appear in the flags.  See sk180496: No match on SecureXL Fast Accelerator (fw fast_accel).  

Keep in mind that only traffic in the Medium Path (either passive or active streaming) can be successfully forced to the fastpath with fast_accel.  Traffic originally destined for the F2F/slowpath will still be processed there and the fast_accel will not work for that traffic.  Connections that are F2F/slowpath do not show up at all in the output of fwaccel conns so that is not the case here.

[Elbis]

Firstly thanks for the help.

My case is a little complicated.

I have a much lower than expected rate in this communication. The entire infrastructure has 10Gb interfaces.

When I ran the test with iperf3 before the "fast_accel" rules with servers on the same networks where the backup transfers are made, I obtained a rate of 700Mb. After following the fast_accel rules and carrying out another test with iperf, my rate went to 3.5Gb.
Backup traffic continues at 700Mb and appears as such in the fw conns table. Only the test with iperf made the hit count on the rule, and the servers are on the same network as the rule created.

 

 

[Timothy_Hall]

Are the connections shown in your last screenshot of the actual port 9020 backup connections (and not iperf3)?  If so they are in the fastpath already and will not cause the fast_accel hit counter to go up.  The blade-based exception you created for IPS and port 9020 has probably made this traffic eligible for the fastpath already.  

When the backup is running, do any of your gateway's  SND cores hit 100%?  If they don't something else other than the firewall is slowing down that backup traffic (possibly fragmentation), for the gateway please provide the output of netstat -ni for the relevant interfaces the backup traffic is traversing to look for network problems. 

Just because the server being backed up has a 10Gbit NIC doesn't mean the backup software can actually push traffic at 10Gbit, you may want to look at resource utilization on the server being backed up and see if the backup software is running out of CPU at 700Mbit.  Not impossible if it is encrypting the backup traffic but is limited to a single thread/CPU.  Also look at your backup server while this backup is running and make sure it has plenty of resources and is not throttling the inbound backup traffic.

[Lesley]

Sounds to me that the traffic hits one CPU core and that it is the limit of speed it can reach. 

700Mbit is very decent for one CPU core.