Bug: Download speeds not as high as it should

bertmeeuws commented 11 months ago

Is this urgent?

No

Host OS

Debian GNU/Linux 11 (bullseye)

CPU arch

aarch64

VPN service provider

Mullvad

What are you using to run the container

docker-compose

What is the version of Gluetun

Running version latest built on 2023-08-11T11:08:54.752Z (commit e556871)

What's the problem 🤔

I am running Gluetun with Mullvad on a Raspberry Pi 4 model B with 8GB RAM.

But whenever I run a speed test inside one of the dockers I only get around 340 Mbits. My Raspberry Pi is connected to my router with a cable and I have an internet speed of 1 gigabit. In reality, it is more or less 920Mbits without a VPN.

Inside my qbittorrent I use port forwarding which works and has been validated with ipleak.net Whenever I run a speed test inside the docker and look at my CPU usage. Core 1 is maxed out but the other 3 cores are at ~20 percent usage.

Extra notes:

The same result when connecting to a 10Gig mullvad server in Brussels or Amsterdam
Before this, I was running a vpn client on my windows with wireless and even those speeds were better. Should be getting around ~600-700 Mbits on cable with VPN on. With my desktop 10m away I was having ~450Mbits with VPN
I have nothing else running on the RSPi
Operating system and everything except media files are running on a Samsung SSD

Inside the container:

   Speedtest by Ookla

      Server: Behostings - Cloud Services Provider - Brussels (id: 54889)
         ISP: M247 Europe SRL
Idle Latency:    18.32 ms   (jitter: 0.57ms, low: 17.91ms, high: 20.08ms)
    Download:   339.50 Mbps (data used: 435.9 MB)
                 65.78 ms   (jitter: 8.63ms, low: 16.54ms, high: 132.70ms)
      Upload:    36.37 Mbps (data used: 17.3 MB)
                 24.14 ms   (jitter: 2.16ms, low: 18.51ms, high: 50.16ms)
 Packet Loss:     0.0%

Without VPN raspberry pi

Speedtest by Ookla

      Server: edpnet Belgium BV - Antwerp (id: 40400)
         ISP: Telenet
Idle Latency:    17.30 ms   (jitter: 1.23ms, low: 15.93ms, high: 18.22ms)
    Download:   940.57 Mbps (data used: 1.1 GB)
                 31.93 ms   (jitter: 9.81ms, low: 16.22ms, high: 164.89ms)
      Upload:    38.01 Mbps (data used: 19.1 MB)
                 10.86 ms   (jitter: 0.94ms, low: 9.17ms, high: 23.45ms)
 Packet Loss:     0.0%

Share your logs (at least 10 lines)

2023-09-28T12:16:28+02:00 INFO [routing] default route found: interface eth0, gateway 172.19.0.1, assigned IP 172.19.0.2 and family v4
2023-09-28T12:16:28+02:00 DEBUG [routing] ip rule add from 172.19.0.2/32 lookup 200 pref 100
2023-09-28T12:16:28+02:00 INFO [routing] adding route for 0.0.0.0/0
2023-09-28T12:16:28+02:00 DEBUG [routing] ip route replace 0.0.0.0/0 via 172.19.0.1 dev eth0 table 200
2023-09-28T12:16:28+02:00 INFO [firewall] setting allowed subnets...
2023-09-28T12:16:28+02:00 INFO [routing] default route found: interface eth0, gateway 172.19.0.1, assigned IP 172.19.0.2 and family v4
2023-09-28T12:16:28+02:00 DEBUG [routing] ip rule add to 172.19.0.0/16 lookup 254 pref 98
2023-09-28T12:16:28+02:00 INFO [dns] using plaintext DNS at address 1.1.1.1
2023-09-28T12:16:28+02:00 INFO [http server] http server listening on [::]:8000
2023-09-28T12:16:28+02:00 DEBUG [wireguard] Wireguard server public key: xxxxxxxxxx
2023-09-28T12:16:28+02:00 DEBUG [wireguard] Wireguard client private key: 0LY...2I=
2023-09-28T12:16:28+02:00 DEBUG [wireguard] Wireguard pre-shared key: [not set]
2023-09-28T12:16:28+02:00 INFO [firewall] allowing VPN connection...
2023-09-28T12:16:28+02:00 DEBUG [firewall] iptables --append OUTPUT -d 91.90.123.2 -o eth0 -p udp -m udp --dport 51820 -j ACCEPT
2023-09-28T12:16:28+02:00 INFO [healthcheck] listening on 127.0.0.1:9999
2023-09-28T12:16:28+02:00 DEBUG [firewall] iptables --append OUTPUT -o tun0 -j ACCEPT
2023-09-28T12:16:28+02:00 DEBUG [firewall] ip6tables-nft --append OUTPUT -o tun0 -j ACCEPT
2023-09-28T12:16:28+02:00 INFO [wireguard] Using available kernelspace implementation
2023-09-28T12:16:28+02:00 INFO [wireguard] Connecting to 91.90.123.2:51820
2023-09-28T12:16:28+02:00 INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working.
2023-09-28T12:16:28+02:00 INFO [firewall] setting allowed input port 51840 through interface tun0...
2023-09-28T12:16:28+02:00 DEBUG [firewall] iptables --append INPUT -i tun0 -p tcp --dport 51820 -j ACCEPT
2023-09-28T12:16:28+02:00 DEBUG [firewall] ip6tables-nft --append INPUT -i tun0 -p tcp --dport 51820 -j ACCEPT
2023-09-28T12:16:28+02:00 DEBUG [firewall] iptables --append INPUT -i tun0 -p udp --dport 51820 -j ACCEPT
2023-09-28T12:16:28+02:00 DEBUG [firewall] ip6tables-nft --append INPUT -i tun0 -p udp --dport 51820 -j ACCEPT
2023-09-28T12:16:28+02:00 INFO [dns] downloading DNS over TLS cryptographic files
2023-09-28T12:16:32+02:00 INFO [dns] downloading hostnames and IP block lists
2023-09-28T12:16:33+02:00 INFO [healthcheck] healthy!
2023-09-28T12:16:47+02:00 INFO [healthcheck] unhealthy: dialing: dial tcp4: lookup cloudflare.com: i/o timeout
2023-09-28T12:16:48+02:00 INFO [dns] init module 0: validator
2023-09-28T12:16:48+02:00 INFO [dns] init module 1: iterator
2023-09-28T12:16:48+02:00 INFO [dns] start of service (unbound 1.17.1).
2023-09-28T12:16:49+02:00 INFO [dns] generate keytag query _ta-4a5c-4f66. NULL IN
2023-09-28T12:16:49+02:00 INFO [dns] generate keytag query _ta-4a5c-4f66. NULL IN
2023-09-28T12:16:49+02:00 INFO [dns] ready
2023-09-28T12:16:49+02:00 INFO [healthcheck] healthy!
2023-09-28T12:16:49+02:00 INFO [ip getter] Public IP address is xxxxxxxx (Belgium, Brussels Capital, Brussels)
2023-09-28T12:16:50+02:00 INFO [vpn] You are running 25 commits behind the most recent latest
2023-09-28T12:17:17+02:00 INFO [healthcheck] unhealthy: dialing: dial tcp4 104.16.133.229:443: i/o timeout
2023-09-28T12:17:19+02:00 INFO [healthcheck] healthy!

Share your configuration

version: '3'
services:
  gluetun:
    image: qmcgaw/gluetun:latest
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - '/dev/net/tun:/dev/net/tun'
    ports:
      - '8888:8888/tcp'
      - '8388:8388/tcp'
      - '8388:8388/udp'
      - '8085:8085'
    volumes:
      - '/gluetun:/gluetun'
    environment:
      - VPN_SERVICE_PROVIDER=mullvad
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=$$$$
      - WIREGUARD_ADDRESSES=xx.xx.3.22/32
      - SERVER_CITIES=Brussels
      - TZ=Europe/Brussels
      - FIREWALL_VPN_INPUT_PORTS=$$$
    restart: always
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent
    container_name: qbittorrent
    network_mode: 'service:gluetun'
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Brussels
      - WEBUI_PORT=8085
    volumes:
      - '/home/pi/Applications/bittorrent:/config'
      - '/home:/home'
      - '/mnt/HDD:/mnt/HDD'
    depends_on:
      - gluetun
    restart: always

EDIT: I still had to Docker pull the latest image, issue has not been resolved.

qdm12 commented 11 months ago

Docker/containers add some overhead, so that can be a reason for lower bandwidths, see https://github.com/qdm12/gluetun-wiki/blob/main/faq/bandwidth.md

Core 1 is maxed out but the other 3 cores are at ~20 percent usage.

Not everything is parallelizable, so that would explain the only 20% of usage on the 3 other cores. The Raspberry Pi 4 single core performance might be quite worst than for a laptop, and that could be the reason for the bottleneck (since first core is at 100% usage as well). Enough blabla though! What you should try, is to setup a Wireguard server (not the easiest, but not too hard either) on another machine in your local network, and speed test (for example with iperf) the bandwidth from Gluetun to your own wireguard server. If it is still at the same speeds, it means you have a single core performance bottleneck 😉

I'll leave this issue opened in case you make new discoveries in the coming days, I'll close it if inactive for a few days.

clemone210 commented 11 months ago

On the host I have:

Retrieving speedtest.net configuration...
Testing from Hetzner Online GmbH (162.XX.162.XX)...
Retrieving speedtest.net server list...
Retrieving information for the selected server...
Hosted by WOBCOM GmbH (Wolfsburg) [153.34 km]: 30.074 ms
Testing download speed
Download: 1891.43 Mbit/s
Testing upload speed
Upload: 703.17 Mbit/s

Within the ProtonVPN gluetun container:

Retrieving speedtest.net configuration...
Testing from Proton AG (194.XXX.177.XX)...
Retrieving speedtest.net server list...
Retrieving information for the selected server...
Hosted by WOBCOM GmbH (Wolfsburg) [294.95 km]: 106.612 ms
Testing download speed
Download: 267.37 Mbit/s
Testing upload speed
Upload: 142.39 Mbit/s

qdm12 commented 11 months ago

@clemone210 what machine are you using? A raspberry pi 4 as well? It looks like you're comparing no-VPN bandwidths to VPN bandwidths, which not really comparable because:

different speedtest server
different routes to server (and different bandwidth bottlenecks on the way)
CPU encryption impact

The only way to reliably compare if Gluetun would have an impact on performance, would be to run wireguard natively without Docker versus Gluetun

on the same machine for both tests
connecting to the same VPN server hostname for both tests
use the same speedtest server for both tests

Appel-flappen commented 11 months ago

as long as you are using the kernelspace wireguard, I don't think there'll be any difference in speed between using gluetun and not. The CPU actually has to do a great deal of work in encrypting all of the data before it is sent. I've seen on some forums people are suggesting midrange x86_64 processors in order to be able to run a wireguard connection at 1gbps. This is just a fundamental reality of using encryption, it has a computational cost.

github-actions[bot] commented 3 weeks ago

Closed issues are NOT monitored, so commenting here is likely to be not seen. If you think this is still unresolved and have more information to bring, please create another issue.

This is an automated comment setup because @qdm12 is the sole maintainer of this project which became too popular to monitor issues closed.

qdm12 / gluetun