Sophos XG 18 MR3 DPI slow download

This is just the way it is.  Also you get the bonus of it breaking random sites with no idea why or what to do about it.

are there any new ideas on this topic?

I don't think that this is not happening to lot's of other people if this would be a bug?

We only have Windows clients in operation. I'm going to test Linux and try it.

@Bill Roland  It is exactly the same with us

Hi,

it happens on MAC clients, MBP, iPad, iPhones.

Mail - iMap/s and smtp/s fail with no error messages.

Ian

I have to admit, that I just testet DPI for HTTP(s) and as this was causing issues I did  not extend the coverage, so I can't talk about imap and smtp.

My current solution is just not to use DPI which is a petty because I would like to make use of it...

Just to confirm, if you use DPI, can you extend the speed of your Line with multiple sessions? For example Ookla uses different downloads at the same time. https://www.speedtest.net/ You can run multiple or single tests. 

Whats the performance with DPI on your appliances? 

right, this works. If i start several downloads I can max out my connection

The reason for the speed difference is because the underlying software on Sophos XG  - who does the DPI is heavily single-core, if you start a download with a single connection the DPI will only be able to use a single core to do almost everything, from the decryption/encryption to IPS and so on.

Meanwhile with multiple connections the DPI Engine is able to share the load with all available cores of your appliance.

The day Sophos updates Snort to 3.1, this issue will be (probably) solved.

Might be, but in my case my cores are not maxed out, there is lots of performance left on every single core and when using Linux instead of windows DPI works at full speed.

just to add, I tested this with a single client connected to a 230 Appliance which also was a fresh install with 18.4.

I just got a troughput between 1,6 to 2,5Mbit/s with disabled DPI I get 12Mbit/s and as you can imagine one client on a 230 should not max out the machine.

These are interesting facts:

- Linux and Windows differ in behaviour
- Multiple parallel connections max out the connection
- CPU is not fully loaded (I'd expect that a single connection will always go on a single thread/core). In bigger installation this should not be an issue as there will be plenty of connections.


There are still other parameters that might have an impact:

- fastpath on/off
- avanced-firewall tcp settings (https://docs.sophos.com/nsg/sophos-firewall/18.0/Help/en-us/webhelp/cli/PDF/sfos_cliguide.pdf)
- SSL/TLS decryption

If the proxy is on there are probably two connections. One going from the client to the sophos and one from sophos to the website.

When DPI is used I'd assume that the connection is more "direct". As the behavior of linux and windows is different with respect to throughput I'd think that there might be some "live translation" between client <-> sophos and sophos <-> website which fits in case of a linux client and does not fit in case of newer Windows versions.  Analysing such a connection low level in wireshark might help to find the reason for this different behaviour (window size, window scaling, selective acknoledgement, mtu & mms, fragmentation, ...).

I have seen some bad throughput of Windows Servers through WAN lines with high latency (SMB - never tested with HTTP(S)) so this might be an issue of Sophos firewall OR Windows Server. Multiple connections also helped in this case to increase throughput off the underlying connection.

Besides some basic testing (and probably using the old proxy afterwards) I won't participate in this. Simply not my task to invest time here. As a lot of people seem to be able to reproduce this it is really surprising that this is lingering around in this forum for months (or even longer) and still seems not to be deeply analysed, troubleshooted and resoved by Sophos.

These are interesting facts:

- Linux and Windows differ in behaviour
- Multiple parallel connections max out the connection
- CPU is not fully loaded (I'd expect that a single connection will always go on a single thread/core). In bigger installation this should not be an issue as there will be plenty of connections.


There are still other parameters that might have an impact:

- fastpath on/off
- avanced-firewall tcp settings (https://docs.sophos.com/nsg/sophos-firewall/18.0/Help/en-us/webhelp/cli/PDF/sfos_cliguide.pdf)
- SSL/TLS decryption

If the proxy is on there are probably two connections. One going from the client to the sophos and one from sophos to the website.

When DPI is used I'd assume that the connection is more "direct". As the behavior of linux and windows is different with respect to throughput I'd think that there might be some "live translation" between client <-> sophos and sophos <-> website which fits in case of a linux client and does not fit in case of newer Windows versions.  Analysing such a connection low level in wireshark might help to find the reason for this different behaviour (window size, window scaling, selective acknoledgement, mtu & mms, fragmentation, ...).

I have seen some bad throughput of Windows Servers through WAN lines with high latency (SMB - never tested with HTTP(S)) so this might be an issue of Sophos firewall OR Windows Server. Multiple connections also helped in this case to increase throughput off the underlying connection.

Besides some basic testing (and probably using the old proxy afterwards) I won't participate in this. Simply not my task to invest time here. As a lot of people seem to be able to reproduce this it is really surprising that this is lingering around in this forum for months (or even longer) and still seems not to be deeply analysed, troubleshooted and resoved by Sophos.