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

Sophos XG 18 MR3 DPI slow download

Hi all,

after going from decrypting HTTPS traffic by proxy to the dpi engine my download performance dropped massivly.

I am on a SG 230 hardware where the XG 18 MR3 is installed on.

Taking the same side downloading an ISO file via HTTPS with proxy and SSL decryption a get 100mbit/s troughput which is the max of my internet connection.

switching to DPI I get arround 16mbit/s. If a start a second, third download an so on I can max out my internet connection.

switching back and forth between proxy and dpi I can always reproduce this.

this happens only to HTTPS sessions with DPI turned on.

The load on the FW is never higher than 20% while testing.

Could there be an issue that DPI is somehow limiing the throughput within a session? No QoS is defined...

I tried different DPI policies and nothing changed the behavior.

Thanks for your help

best



This thread was automatically locked due to age.

Top Replies

  • Thanks to everyone who has provided data points and feedback here.

    We have identified a couple of areas where DPI mode was preventing traffic running as fast as it otherwise would, due to issues with the TCP receive window. This problem is less obvious on low-latency, local network connections, but can get quite significant as network latency increases.

    The problem is not caused by overloading of the firewall, but by the server not sending data quickly enough on a given connection. This is why many of you observed that parallel connections would all max out at the same level and increase the overall bandwidth consumption, even though the throughput seemed to be limited on each connection individually.

    The reason the server doesn't send data quickly enough is that there are issues with the way the firewall is calculating the TCP receive window size that it advertises to the server in packet headers. The TCP receive window value tells the server how much data it should send before pausing to wait for confirmation that the data arrived safely. If that value is too small, the server will spend a lot of time waiting for confirmation and the overall flow of data will be slow. The time spent waiting increases with connection latency, so overall flow seems even lower on longer-distance connections.

    We are working on a fix for this problem and are making plans to release it in an upcoming maintenance release. It will be included in 18.0 MR6. It is also addressed in the 18.5 GA version, for early adopters of XGS-series hardware.

    Jump to answer
Parents
  • Hello Strandundmeer,

    Thank you for contacting the Sophos Community!

    If you create a SSL/TLS inspection rule for the Source IP, set to "Do not decrypt" does the issue is the same when you select Decrypt HTTPS during web proxy filtering in the Firewall rule for this Source IP?

    Does the ips.log show you any error?

    Regards,


     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support VideosProduct Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
  • Hi I would like to take this topic back to life.

    After updating to MR-4 I did some additional tests and realized that slow downloads just happen to my windows 10 clients.

    I tested this on 4 different Windows 10 Clients, all of them have a significant reduced download speed with DPI enabled.

    Using a MacBookPro with the same policy works without problems and utilizes my connection to the max!

    If I boot up linux instead of windows 10 I don't have this problem, too.

    I ended up reinstalling Windows 10, patched it to the latest version and just installed Firefox and Chrome + my Firewall CA Certificate to get DPI to work. Nothing else is installed but the speed drops even with no other software installed. Back to Linux on the same machine without chaning the policy and the speed is at max again.

    It would be great if we could find a solution for this because I don't think that I am the only one with this issue.

    Thanks

    Strandundmeer

  • Do you have any kind of Windows Endpoint Protection installed, which could eventually inspect this traffic? 

    I am not able to reproduce this at all. But it might be an issue with the Interfaces? Check all your XG Interfaces, if direct attached to the windows, if the TCP window handling causes this issue. 

    __________________________________________________________________________________________________________________

Reply
  • Do you have any kind of Windows Endpoint Protection installed, which could eventually inspect this traffic? 

    I am not able to reproduce this at all. But it might be an issue with the Interfaces? Check all your XG Interfaces, if direct attached to the windows, if the TCP window handling causes this issue. 

    __________________________________________________________________________________________________________________

Children