Sophos XG 18 MR3 DPI slow download

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.

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.

Thank you for the detailed explanation of what is failing and the potential fixes.

a question, will the fixed version also included UDP scanning?

another question, will the fix include scanning smtps, Imaps?
ian

Hi Ian, its a Fix, not a feature release. 

Hi Toni,

if I don’t ask I don’t get to know whether it is a fix or feature that is faulty/missing.

ian

No. This issue and the fixes are purely related to handling TCP TLS streams.

Hi Rich,

Is there any work being done to update Snort to 3.1 in the near future ?

Thanks!

Hi Rich - I presume this hasn't made it into MR5? Regards

No unfortunately it was too late to include it in MR5 with the appropriate level of testing. It will be in MR6.