I’ve been having random connectivity and thruput issues connecting to my normally-rock-stable personal WG VPN server that I’d attributed to deprioritization, varying signal and/or the WG FW. It’s on 2Gbit symmetric fiber so raw thruput wasn’t (and usually isn’t, on Ethernet) the problem.
Dropped it to 1320 (on both ends, just because) and it’s been hugely stable ever since.
What clued me in was connectivity issues with Xfinity Hotspots (“Public” WiFi available to customers of a National cable co, for us non-USAns). I’d at first thought they were blocking my UDP port, but I could still ssh; webpages loaded slowly, if at all, and I realized it was MTU (it didn’t help that Xfinity is all-in on IPv6, which requires a smaller MTU even in the best of conditions).
So maybe everyone else was already aware, but for anyone else, Pro-Tip!
ETA: Oh, and there’s this: Wireguard Optimal MTU · GitHub
Thanks for sharing!
MTU is mostly based on your ISP and different other reasons, so it’s not a general fix for everything.
… and see the link I’d posted
I’m no MTU expert but the 1320 may be somewhat specific to xfinitywifi. I have a Creta that uses xfinitywifi and needed to use 1320 to get it to connect to my WireGuard server. On the other hand, my cell phone that uses Verizon was having issues with the “default” MTU value of 1420. I lowered it to 1380 and it is working much better now.
I travel a lot and a couple years ago I was fighting issues where Wireguard would hang at some places I stayed, but OpenVPN over TCP worked just fine.
Googling, I found this posting: WireGuard MTU fixes - Kerem Erkan
And I now just use 1280 on my travel router, and Wireguard just works.
I’d actually experimented with a few values while I was on the XF Hotspot (and I may not have been clear, using the XF HS was via my laptop directly, no GL device involved) and like @eric had seen many people recommending 1280, but in a bid to maximize thruput I’d gradually brought it up and then I’d seen the Gist I’d linked above and 1320 does seem to be the sweet spot.
When I got back to my X3000 setup I lowered it to 1320 there and connected to WWAN (there’s actually Ethernet at my hotel with decent speeds) and the difference was amazing. Thing is, I’d thought I’d tried changing it once before, but probably forgot when I migrated to the X3000.
Since WG doesn’t do pMTUd, there’s no way for it to suss it out on its own, and who knows what kind of packet-size changes are going on with WWAN networks. Also, I believe (i.e., don’t quote me) that T-Mo (where I had the biggest problems) is all IPv6 internally then “fakes” an IPv4 for non-v6 connections might possibly explain that issue.
Thing is, I have people in Europe borrowing my US-based VPN to watch US TV and as it’s all wired connections they haven’t seen any thruput issues, nor did I last year when I was in Argentina. I changed the server MTU to 1320 to match and they haven’t reported any issues, but what I need to find out for sure is if the server/client MTUs don’t match, does WG use the mininum of the two values across both ends of the link.
I would guess that WG is using the minimum value between the two. Looking at the settings on my Asus router which is what my WG server is running on I don’t even see any inputs for MTU in the GUI. I think I’ve seen something in the system log mentioning 1420. That said, as previously mentioned, I have a Creta that is set to 1320 and a phone that is set to 1380 and both are working good. The MTU in the WG app on the Android phone was previously blank (showing a greyscale “Auto”) and the data speeds were terrible. Once I manually entered 1380 the speeds improved dramatically. This leads me to believe that the important location to set the MTU is on the client peer, not the server peer.
Yeah, I’d figured but wasn’t sure. I have a lot of client .conf files out there (some quite inaccessible) that don’t set an MTU, and since according to that Gist the sweet spot seems to be 1320 so I may leave my server there for a while.