Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

UTM ownCloud very slow download

I’ve a UTM virtual appliance running at home for almost 5 years. Never got a problem.
Just a few weeks ago I installed ownCloud so I can share files on my smartphone, etc.
ownCloud syncs the files. My internet connection is 40 down and 4 up.

The Problem
When I use the ownCloud client outside my LAN, example at work, I got really really slow
download speed of 15 – 30 KB/s. This problem also excists with any webbrowser.
When I upload from my work to home I got my full upload speed of my provider, 4Mb.
When ownCloud starts syncing I see that it starts on the maxium download speed and then
quickly drops to almost nothing.

On my LAN I got no problems, there is it the maxium up and down. So ownCloud must be
working good. Because of that I think it’s something in the UTM.


What I did so far
I made 2 rules DNAT and SNAT.

SNAT :
For traffic from “IP ownCloud server” --> service “443” --> going to “Any” --> service “MyPortNumber

DNAT :
For traffic from “Any” --> service “MyPortNumber” --> going to “ExternalWAN-IP” --> destination “ownCloud IPà service “443


I also tested true a VPN connection where I connect the ownCloud client with the IP of my ownCloud server and the download speed is there also bad. But the upload is the maxium. Also when I download
a file from a share on one of my servers I got the full download speed.
I see also no performance issues on my server or on all the clients that are running on it.
I tried to turn off logging of the rules, turn off Intrusion Prevetion.

Anybody a clue on whats going on?

 



 

 



This thread was automatically locked due to age.
  • Just a guess - Check with your home ISP to see if they restrict bandwidth when you're doing a large upload.

    Turning Intrusion Prevention off is not a good problem solving technique, but looking in that log is as other things also are logged there.

    Any luck with either of those guesses?

    Cheers - Bob

  • I did some more tests.

    1. Linksys Router connected to modem with Ubuntu 15 laptop
        test with iperf3 are the results good

    2. Linksys Router connected to modem with W7 laptop
        test with iperf3 are the results good

    3. Virtual Machine Ubuntu 15 server (same IP as ownCloud server)
       test with iperf results are bad.

    4. Virtual Machine Ubuntu 15 desktop (other IP)
       test with iperf results are bad.

    5. Virtual Machine W7/W10
           test with iperf3 are the results good

    Tested the Ubuntu VM's with different mtu settings, no change.
    Tested the Ubuntu VM's with different virtual NICs, no change

    So my conclusions it happens only with Virtual Machines with a Linux version???? [:'(]
    I made a tcpdump on the UTM and I see these errors when look at it with Wireshark

    - 590 Destionation unreachable (Fragmentation needed)
    - 1514 TCP retransmission
    -  1514 Out of Order
    -  78 TCP Dup ACK
    - 1514 TCP fast retransmission
    etc

    When I look at the dump file with the laptop connected I see 0 errors.

    Is this a problem in combination with ESXi and Linux?

  • I've found the solution [<:o)][<:o)][<:o)] LSO (Large Segment Offload)

    Its explained on the website below

    http://blog.cyberexplorer.me/2013/03/improving-vm-to-vm-network-throughput.html

    "To learn more about LSO (Large Segment Offload) read http://en.wikipedia.org/wiki/Large_segment_offload.
    Essentially, the kernel is sending large packets (16K in the capture) and the NIC (or virtual NIC) is supposed to fragment the packet and transmit valid-size packets. On a real hardware NIC, at high speeds, this saves considerable amounts of CPU. in a virtualized environment I don't see the benefit. And it seems to be badly broken."


    On the Ubuntu servers I used this command

    Ethtool -K eth0 tso off (after reboot its gone, so you need to make a change in your config)

    After this change I got a good result with iperf.

  • RW, in order to do the same for wlan0 to combat a bug in 2014, I added the following to clients' /etc/crontab-static where they had Sophos wireless APs:

    @reboot root /sbin/ethtool -K wlan0 tso off && date>/home/ethtoolran

    Cheers - Bob