We'd love to hear about it! Click here to go to the product suggestion community
we have a WiFi running for our smartphones mainly to update Android and apps. WiFi is offered through an AP55. Only smartphones can connect based on their MAC address. There is an own firewall rule for these connections with the following options active: HTTP scanning, block Google QUIC, detect zero day malware with Sandstorm, Scan FTP.
Unfortunately downloads are very slow. App updates take a long time and Android updates are canceled at a certain point by the smartphone itself.
As all updates are done over secure socket layer protocol and HTTPS scanning is not active I wonder what could be the reason. I checked the IP addresses that are used during update and always got to https://r3---sn-h0jeened.gvt1.com/ and https://r4---sn-h0jeened.gvt1.com/ so I excluded gvt1.com from HTTPS scanning, malware scanning and sandstorm. But also this showed no improvement on download speed.
Currently I wonder if the throughput of the AP55 is that slow?
Does anybody have any suggestions? Thanks.
In reply to LuCar Toni:
This is currently being investigated by our support team, will follow up with any updates as they become available.
In reply to FloSupport:
This ID [NC-40091] is tentatively scheduled to be addressed in SFOS v17.5 MR-2. No exact info on a release date for this version yet, please stay tuned.
Does that mean MR1 is already on its way?
In reply to Jelle:
That's correct. MR1 is tentatively scheduled for a release later this month (December). Please stay tuned for more info, as we will announce more news when it becomes available.
Having the exact same issue. Changing the MTU or disabling offloading temporarily fixes it. However have to redo it on reboot. I am on 17.5.3 MR-3 and it is happening, so i take it MR-2 did not include the fix?
In reply to Mike Hinnenkamp:
Hi Mike Hinnenkamp
Apologies for the delayed response and for any inconvenience caused.
The permanent fix for this issue (NC-40091) is scheduled to be included in the upcoming SFOS v17.5.4 MR-4 version, expected to be released in late March or early April.
Thanks FloSupport, it is listed in the release notes: https://community.sophos.com/products/xg-firewall/b/xg-blog/posts/sfos-17-5-mr4-released
I experienced the same issue and it was still persistent.
We upgraded from 17.5.3 to 17.5.5 and TCP Offload Segmentation was still enabled on the Separate Zone Wifi Networks.
I disabled it manually for the time being and opened a support case.
In reply to Bjoern Ebner:
Another tip would be to verify the Flood Protection.
Disabling TCP Segmentation OffLoad for the Wifi Interfaces seems to solve the problem.
But it's strange that it wasn't disabled automatically when Version 17.5.5 is installed and it seems that 17.5.4 disables TCP Segmentation OffLoad for those Interfaces.
17.5.4 definitly does! After installing it the performance issue was gone.
Maybe it doesn't, if 17.5.4 is skipped and 17.5.5 is installed?
As 17.5.5 came shortly after 17.5.4 that could be if the devs didn't merge everything. Unlikely but possible.
Maybe someone else here also skipped 17.5.4?
Did you switch segmentation in your prior version manually? Maybe it only works if untouched?
No, I didn't notice the problem before 17.5.5 was installed because it wasn't reported to me.
So the Settings were untouched.
I checked the settings on a Sophos XG on which Version 17.5.4 wasn't skipped and on Wifi-Interfaces TSO wasn't deactivated.
Is this by Design?
I checked the TSO Settings on Seperate Zones on a new Sophos XG.
TSO is stilled switched on for Seperate Zones Networks.
Even when I create a new Seperate Zone TSO is switched off.
I thought TSO should be disabled for Seperate Zones Interfaces since version 17.5.4.
Now I'm confused ;)