Slow downloads on smartphones connected over AP


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 and so I excluded 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.

  • Perhaps we're experiencing the same issue. :-/

    Have you tried to turn off Scan HTTP and set Web Policy to None in your network rule?

    We're using this both components in several network rules. But if we use them in a Wifi network rule, the Wifi performance drops extremely. I've already opened a ticket and Sophos Support is currently investigating our problem.

  • Do you use Separate zone or bridge to AP (V)LAN? 

  • In reply to LuCar Toni:

    It is set to seperate zone. The wifi network is only for offering internet access to the smartphones. Connection to the internal network is not wanted.

  • In reply to Jelle:

    Put 2,4 GHz to 75% power now as suggested in

    Radios are in auto channel mode and encryption is AES only. DoS is currently not configured.


    In it is mentioned that MTU in seperate zone is fixed to 1450 and MSS on WAN interface should be reduced to 1410 to stop fragmentation. Any experience with this?


    Here: it is said that keeping the wifi as a separate zone is severely restricting the traffic. The thread says it has been resolved with SFOS 16.05.2. I did not try to change it to bridged mode.


    Guess latest AP firmware is installed automatically from XG so this thread also didn't apply as 11.0.001 is installed.

  • In reply to dja:

    Turned off Scan HTTP and set web policy to None. No improvement...

  • In reply to Jelle:

    Mmh... Suddenly I'm seeing a real improvement. Maybe I was too fast with testing after changing the settings.

    Currently everything is turned off and using I'm at 16.09 download and 1.04 upload which is connection max.


    Testing 3 times after each change now

    Step 1: Turned on HTTP scanning -> download 15.2 / 15.73 / 15.8, upload 0.78 / 0.96 / 1.04, latency 42ms / 35ms / 41ms

    Step 2: Turned on Block Google QUIC -> download 15.73 / 15.63 / 15.87, upload 1.02 / 0.82 / 0.79, latency 35ms / 37ms / 36ms

    Step 3: Turned on Sandstorm protection -> download 13.43 / 15.74 / 15.91, upload 0.84 / 0.78 / 0.79, latency 43ms / 56ms / 34ms

    Step 4: Turned on FTP scanning -> download 15.71 / 16.14 / 15.78, upload 0.74 / 0.76 / 0.77, latency 56ms / 47ms / 33ms

    Step 5: Activated web policy -> download 3.28 / 5.47 / 5.32, upload 0.75 / 0.97 / 0.75, latency 80ms / 33ms / 35ms


    Verification: Deactivated web policy -> download 15.69 / 15.27 / 15.48, upload 0.78 / 0.82 / 0.89, latency 48ms / 39ms / 48ms


    So I can definitely confirm that using a web policy is the showstopper.

    What is interesting is that the same web policy is used for the web browsing rule for our office computers. Running here returns good values.

  • In reply to Jelle:

    Can you show us a screenshot of the Interface tab - Wireless interface?

    I assume there could be an "very old" issue which affects the MTU Size of the interface. 

  • In reply to LuCar Toni:


    I assume there could be an "very old" issue which affects the MTU Size of the interface. 

    As we're having the same issue. Here's a screenshot of our MSS/MTU values on the wireless interface:

    But I see no way to change this settings.

  • In reply to LuCar Toni:

    Same values here like  posted. Looks like MSS is too high. Mentioned this in a previous post as MTU seems to be fixed to 1450 on wireless interfaces. But were comes MSS from as I already changed it manually on the WAN interface (to 1444)?


    Edit: OK, I assume MSS is taken from the LAN interface...?

  • In reply to Jelle:


    Please delete your Wireless Network and recreate it. 

    It should be created with MTU Size 1500 and the issue should be fixed.


    This is kinda an old bug from UTM. In UTM 9.3 i guess, we tried to fix an issue and setup all networks with 1450. This causes an other issue. Wireless Protection in XG had the same behavior and we fixed it in 16.05. Afterwards all Networks should be created with 1500 instead of 1450. 

  • In reply to LuCar Toni:


    Please delete your Wireless Network and recreate it. 

    Unfortunately that doesn't help. The screenshot shows a test Wifi I've created last week, running SFOS 17.1.1 MR1.

  • In reply to LuCar Toni:

    Well, AP55 and WiFi have been created with the current SFOS 17.1.1 MR-1 so was it really fixed in 16.05???

    How can I recreate without configuring everything from the beginning?

  • In reply to dja:

    Oh - Maybe i am wrong? Try to change the MTU Size on GUI. 

    I do not have access to a XG right now, so i cannot check the CLI for a Console switch. 

    But "from which" Firmware did you upgrade? As far as i know, this can only happen, if you used an old firmware and upgrade to V17.X 

    You should be able to change the MTU Size. The Problem is, i did not saw those issue for quite a while (2 years, since it was fixed in V16.05 ..) 

  • In reply to LuCar Toni:

    MTU for wireless interface can't be changed (on GUI)

  • In reply to Jelle:

    This should be 1500 after recreation. I am quite sure. Checked another appliance right now. There is every Wireless Network created with 1450. 

    So i would highly assume, if you delete all network attached to this AP and recreate it, it should work fine.