Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Lot's of TCP Floods, firewall crashing and slow transfer speeds

Hi all, recently my firewall is crashing and I've linked it to something in the above area.  I'm doing a large rsync transfer and the firewall keeps crashing during it which then seems to require a restart of the firewall.  I can stop it crashing by enabling the TCP flood flags in the DoS and Spoof protection section.  However this immediate slows down rsync transfer speeds from many Megbits to a measly 200kb,  Switching the TCP flood setting on or off makes the transfer speeds repeatedly normal / not normal.


I assume that I 'should' have this setting on, but that it is not working propertly or the defaults are not configured correctly for my case of something.  It's almost acting like a misconfigured QoS.


Any thoughts from anyone?


Thanks.



This thread was automatically locked due to age.
  • Hi,

    Which XG firewall model are you using? Did you check the hardware capability if it can handle the amount of traffic it is hit with.

    Thanks

  • Sorry, I forgot they're not all the grow your own variety.  I'm running on a desktop class machine, with the 'home use' licence of XG patched to the latest firmware.  It has been running largely OK accepting the quirks this particular distribution has.  The specs of CPU I don't have on me at the moment, however it's reasonble enough that I would be surprised to see this kind of performance impact.


    If you're saying this flag requires a lot of CPU, I'd been keen to understand that as it clearly needs a LOT of CPU if this is the symptom.

  • Hi, which NICs are you using?

    I had a system with an Intel 82573 NIC which would lock up under heavy load with UTM 9.3x. NIC errors would also appear in system.log (I'm not sure if XG has the same logs).

    Flood protection uses the Snort IPS, at least in UTM9; Snort tends to be very CPU-hungry and can be a bottleneck in many circumstances.

    Barry