- 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
iperf3
server - On WG peer, I wrote a script that does the following:
wg-quick down wg0
- Edit MTU in the
/etc/wireguard/wg0.conf
file wg-quick up wg0
iperf3 -c 172.123.0.1 -J -t 5 -i 5
- This runs an
iperf3
client that connects to172.123.0.1
which is the WG Server gateway - The
iperf3
client 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.
Yeah I would personally never block Echo/Reply because it makes troubleshooting a big pain in the ass. But that sentence was more a comment on IF you want to block ICMP to "hide", only block (or rather, drop, so your computer wont reply at all) those two types and not all of ICMP (which is was most people do). Blocking ICMP entirely will break your connection in various ways.
As for redirects, most operating systems nowadays don't really accept them:
[svag@tuxxx] sysctl net.ipv4.conf.all.accept_redirects
net.ipv4.conf.all.accept_redirects = 0
[svag@tuxxx] sysctl net.ipv4.conf.default.accept_redirects
net.ipv4.conf.default.accept_redirects = 0
But blocking them in firewall anyway is good for a layered approach to security.
When MTU is not aligned to the actual MTU of the link, then every connection you make has to rely on Path MTU Discovery to work. But PMTUD is often broken due to firewalls and middleboxes. That results in packets sized above the actual MTU not reaching their target at all thus creating packetloss - especially with UDP; which is very noticable with DNS traffic and of course also with gaming.