Sophos AP/APX users may experience issues registering to Sophos Central. More info available here: Central Wireless
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:
I am just trying to help you with some hints.
I am just trying to help you with some hints.
I know. Thank you so much for your help! MTU was the keyword. :)
Support indeed can't change MTU value, but currently we're testing with a lower MSS value and this looks very promising. I will keep you informed.
In reply to dja:
djaSupport indeed can't change MTU value, but currently we're testing with a lower MSS value and this looks very promising. I will keep you informed.
It's curious. It worked for our testing Wifi, but if we change these values for our productive Wifis, it doesn't work. :-/
How many voucher do you loose, if you recreate the wireless part?
There you could plan a little downtime and recreate everything. I would go with this way, if there are not many voucher currently in business.
Or you escalate the case via support to get a solution.
After many many many tests we now have a solution for us. Indeed the MTU is the key. MSS remains unchanged.We changed our MTU to 1400, now everything works fast.
Connect via SSH > 5. Device Management > 3. Advanced Shell:ifconfig <wifi_name> mtu 1400
This is only a non-persistent solution. Sophos Support will create a startup-script for us, so this value will be set on every appliance boot.
Did you get any hint if there will be a fix in an upcoming release of the firmware? A startup script isn't something I'd like to implement...
In reply to Jelle:
I still go with the way to clear everything and reconfigure it to resolve this.
As far as i can tell, this is not on the dev track because it is already resolved for nearly everybody couple of months ago.
JelleDid you get any hint if there will be a fix in an upcoming release of the firmware?
Nope not really. They said there are constant Sophos-internal PM / Dev discussions and this is very customer-specific. So we just have to wait.
we currently have the same problem with one of our customers. The XGs were all newly installed and shipped with the v17.
The whole time there was the problem that clients were disconnected after 5 to 10 minutes. Only in separate zones.
Now we had updated to the newest version and the MTU on all networks stands at 1450. Only with 17.1.3. Everything is fine on the devices before the update.
Creating everything new comes at 15 XGs with captive portal 100 vouchers on the day actually out of the question.
Will also adjust the MTU but hope for a fix
Would it be possible to please PM me with your support case ID for follow up?
If anyone else is also affected by a similar wireless MTU issue outlined in this thread, please raise a support case and send me a PM with your ID for followup.
As a little info. Today I noticed the same behavior on a SG UTM with a customer.
Here is the MTU value also 1450. Even if you assign the network an AP. But here only the AP 55c. If I take the AP 50 or 30 does not happen
Thanks to FloSupport we now have a solution that is probably boot- and update-safe:
We have set MTU back to default and disabled TCP Segmentation Offloading. This achieves the same performance as custom MTU.
Here is his guide:
Console> system diagnostics interface-driver-settings set <interface_name> offload tso off
To show: Console> system diagnostics interface-driver-settings show <interface_name> offload
To revert back, simply:
Console> system diagnostics interface-driver-settings set <interface_name> offload tso on
What is the initial purpose of this setting? What happens when I set it to 'off' except faster WiFi? In which case could I be forced to revert this change an set Offloading to 'on' again?
For all future readers: Here is a (german) thread with the answer -> https://community.sophos.com/products/xg-firewall/f/network-and-routing/108597/xg-firewall---wifi-mtu-nach-update-17-1-3/389386#389386
Google Translate is your friend. ;)
Support indeed can't change MTU value, but currently we're testing with a lower MSS value and this looks very promising.
8 Ball Pool Google Hangouts Omegle
In reply to bla nca:
As far as i know, Support found the reason and is already working on a Patch. Would expect it for next MR Release.
FloSupport can you track this?