- I faced bandwidth issues between a WG Peer and a WG server. Download bandwidth when downloading from WG Server to WG peer was reduced significantly and upload bandwidth was practically non existent.
- I found a few reddit posts that said that we need to choose the right MTU. So I wrote a script to find an optimal MTU.
- Ideally I would have liked to have run all possible MTU configurations for both WG Server and WG Peer but for simplicity I choose to fix the WG Server to the original 1420 MTU and tried all MTUs from 1280 to 1500 for the WG Peer.
- On WG server, I started an
iperf3server - On WG peer, I wrote a script that does the following:
wg-quick down wg0- Edit MTU in the
/etc/wireguard/wg0.conffile wg-quick up wg0iperf3 -c 172.123.0.1 -J -t 5 -i 5- This runs an
iperf3client that connects to172.123.0.1which is the WG Server gateway - The
iperf3client runs for 5 seconds and stops and dumps a JSON output
- This runs an
- Max bandwidth provided by my ISP (1000Mbps Download, 50Mbps Upload)
- WG Server is a VPS running Ubuntu 20.04 on a cloud provider.
- WG Peer is a PC running Ubuntu 20.04 locally at home.
I followed this tutorial to setup my Wireguard configurations.
WG-server
# /etc/wireguard/wg0.conf
[Interface]
Address = 172.123.0.1/24
MTU = 1420
SaveConfig = true
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; iptables -t nat -A POSTROUTING -o ens10 -j MASQUERADE; ip6tables -t nat -A POSTROUTING -o ens10 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; iptables -t nat -D POSTROUTING -o ens10 -j MASQUERADE; ip6tables -t nat -D POSTROUTING -o ens10 -j MASQUERADE
ListenPort = 51820
PrivateKey = xxxxxxxxxxxxxxxxxx
[Peer]
PublicKey = xxxxxxxxxxxxxxxxxx
AllowedIPs = 172.123.0.2/32
Endpoint = X.X.X.X:61426
WG-peer
# /etc/wireguard/wg0.conf
[Interface]
PrivateKey = xxxxxxxxxxxxxxxxxx
ListenPort = 51820
Address = 172.123.0.2/24
MTU = 1384
[Peer]
PublicKey = xxxxxxxxxxxxxxxxxx
AllowedIPs = 172.123.0.0/24, 10.1.0.0/24
Endpoint = Y.Y.Y.Y:51820
PersistentKeepalive = 5
- As you can see in the image, the original MTU setting of 1420 for both peer and server gives abysmal bandwdith.
- I found that that MTU 1384 on the WG peer with 1420 on the WG server seems to almost have the best bandwidth.
- For WG Peer MTU 1384, the max upload bandwidth of 50Mbps of my ISP connection is achieved but I was only able to hit 550 Mbps for the download bandwidth where the max download bandwidth of my ISP connection is 1000 Mbps. This reduction in download bandwidth might be due to other factors but 550 Mbps was sufficient for my use cases so I stopped testing it further.
In case any one has any explanations for this behavior or have found some mistakes in my configurations or tests, please let me know.
For half a day I couldn't figure out why I couldn't stream normally to YouTube with a bitrate of 18-20+ Mbits using OBS under VPN, despite the fact that everything else worked and loaded my channel as it should. There were dropped frames due to connection problems and OBS showed that the upload speed dropped to 7-10 Mbit/s. And only thanks to this thread I decided to set MTU 1400 on the server (Windows) and client. After that, I was able to start a stream not only at 25 Mbit/s, but also at 30 Mbit/s. It should be about 700-800 km from my PC to the VPS with WireGuard.
I can directly ping 8.8.8.8 without fragmentation various nodes from my home provider at a maximum size of 1472. The same thing happens if I connect to a VPS and ping from there.
I was told that it is better not to block ICMP Path MTU discovery for normal operation, but I haven't blocked it anywhere on outgoing traffic, and everything I use, as far as I understand, is "stateful". In any case, only adding a record about MTU with 1400 helped solve the problem. Otherwise, I already wanted to look for another VPS and in another country...