VSX & SecureXL

[Sander_Zumbrink]

Hello,

I'm investigating some performance issues where a VSX firewall is in between.

The gateway is running R80.10 with JHF112.

The VS is using IPS, Antibot and application control.

But we've made some exceptions for specific traffic to bypass IPS, Antibot and not log in ApplControl.

Stats: 19% SXL, 59% PXL, 21% F2F.

fwk process uses approx. 50% of available CPU's.

Downloads where 1Mbyte/s through this VS.

When I disabled SecureXL (fwaccel off) the speed was 6 Mbyte/s.

This traffic was also using a F5 BIGIP loadbalancer.

When I make some connections without the loadbalancer, the speed was higher.

With SecureXL enabled it was 10 Mbyte/s and without secureXL it was 20 Mbyte/s.

Has anybody seen the same? Higher speeds with SecureXL disabled?

And did you find the cause of it?

Kind Regards,

Sander Zumbrink

[PhoneBoy]

What kind of traffic?

Is it multiple flows or only a single flow?

[Sander_Zumbrink]

Dameon,

They are doing RSYNC over SSH on port 80.

I've excluded IPS/appl. control/TP.

And made a single port 80 service with application None.

It is a single flow.

[Sander_Zumbrink]

The first problem has been resolved.

SecureXL was not working correctly due to fragmentation.

Changing the routing and MTU changed the behaviour of SecureXL.

Now SecureXL is fast for the connection with problems.

But...

When the customer does a single connection through the firewall. It gets 100 Mbit/s (limited by the other side).

After 6-7 minutes, the speed drops to 20 Mbit/s and cpu of VSX (fwk) goes up.

I think I'm htting a limit at the other side (no Check Point).

No drops at the Check Point.

Any tips?

[Timothy_Hall]

Well one thing I found out in Israel this week is that fragmented packets are no longer doomed to the slowpath on R80.20 gateways so there is that.

As far as the speed decrease that occurs after 6-7 minutes that sounds pretty odd, when troubleshooting a strange performance issue like that the main determination you need to make early is whether packet latency or loss is causing the slowdown.  Easiest way to do that is run a continuous ping between the hosts during the transfer and see if the values being reported by ping change when the slowdown starts.  This is not foolproof though as ICMP traffic is handled quite differently depending on the situation, the most common example I can think of is that ICMP is never accelerated by SecureXL whereas TCP and UDP can potentially be accelerated.  The only definitive way to determine latency vs. loss as the cause is looking at a packet capture in Wireshark.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Sander_Zumbrink]

It looks like an issue on the customer side. The gateway (not checkpoint) there was limiting the traffic.

I assume that I'm receiving zero-window packets, but the dumps being provided are not complete.

For now the customer is letting the issue go and doing the backups another way.

Thanks for the replies.