UPDATE: I researched a little more on this. ipv6 connections require
1280 as the minimum MTU and most router configurations expect to see some standardized MTU. So instead of
1412 as I wrote below, I now recommend
1280 for MTU. While it is smaller and will generate more packets, I think it will encounter fewer configuration problems across different sites.
I live in a country where internet access is severely censored. Wikipedia and Imgur access were just recently restored, and access to many other websites are blocked for various reasons. Due to the incompetence of our censors, sometimes sites with necessary knowledge get blocked too. So I use a VPN at home and on my mobile devices to overcome this issue. Until recently, I was using OpenVPN but then I came upon a great new technology by Jason A. Donenfeld called WireGuard, which blew my mind as I read about it.
It is incredibly fast to connect, very easy to implement and uses minimal resources on a modern computer. My home gateway is on a Debian server with VMWare Fusion, installed on a Mac mini 2018 as I write this post.
I also use WireGuard as an on demand VPN for cellular networks on my iPhone and iPad and the battery impact is minimal. It is really something to configure and forget about, just perfect.
There are many how-tos about installing and configuring WireGuard on the internet, so I will not cover that. What I will cover is, how to fix problems if you are connecting to the internet using PPPoE, for example on an ADSL connection.
I had problems with connection drops, timeouts or other weird issues when I first installed WireGuard on Debian (The mobile devices had no problems whatsoever, so this was an issue with the home gateway). Some sites behaved normally, others had intermittent problems, and some were just not working. After searching for hours and trying many options I came to a perfectly working configuration. So I decided to write it as a future reference to people who will most probably have the same problems on PPPoE.
Server configuration (VPN server):
[Interface] PrivateKey = SERVER_PRIVATE_KEY Address = 10.88.88.1/24 SaveConfig = true PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; iptables -A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; iptables -D FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT ListenPort = 51820 [Peer] PublicKey = CLIENT_PUBLIC_KEY PresharedKey = PRESHARED_KEY AllowedIPs = 10.88.88.2/32, 192.168.1.0/24
Client configuration (Home gateway):
[Interface] PrivateKey = CLIENT_PRIVATE_KEY Address = 10.88.88.2/24 MTU = 1412 PostUp = ip route add SERVER_PUBLIC_IP/32 via 192.168.1.1 dev eth0; iptables -A FORWARD -i wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT; iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu PostDown = ip route del SERVER_PUBLIC_IP/32 via 192.168.1.1 dev eth0; iptables -D FORWARD -i wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT; iptables -D FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu [Peer] PublicKey = SERVER_PUBLIC_KEY PresharedKey = PRESHARED_KEY Endpoint = SERVER_PUBLIC_IP:51820 AllowedIPs = 0.0.0.0/0 PersistentKeepalive = 15
So, what makes this configuration work? First, on PPPoE connections, the maximum MTU is generally
1492 instead of widely used
1500, so the default MTU of WireGuard which is
1420, needs to be corrected to
1412 (I recommend setting the MTU to
1280, see my update on the top of the post for my reasoning). Also,
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu added on
PostUp to the client configuration is the magical setting here that fixes the remaining issues. With it, the client tells the server to use the correct MTU when sending packets to it.
Other noteworthy items with this configuration: The VPN tunnel uses
10.88.88.0/24 block for its internal communication and
192.168.1.0/24 block (change this to your local IP address range) is added to the IP addresses behind the client, which lets local machines connect directly to the server without any extra NAT configuration. On OpenVPN I had to use double NAT, first on the home gateway, then on the server, resulting in a slower connection. With WireGuard, only the server hides IP addresses behind it using NAT. A much simpler configuration.
45 thoughts on “WireGuard MTU fixes”
You saved my life. I have a similar setup using a gateway in my LAN and I’m everything seemed to work but I had a lot of timeouts.
Now it is working and I learnt something.
Glad to be able to help. 😊
This worked amazingly for me, I’m very curious how I can see the problem with the original settings at the packet level so I can see how the changes in configuration affect things. i.e. If I revert to the original settings, what commands could I run that demonstrate that there is a problem with the MTU settings that manifest themselves as SSL handshake problems?
Thanks again for this post, it was extremely useful for me!
Thanks for the comment. I am not sure how easy it would be to directly troubleshoot the SSL handshake problem. Some servers seem to just drop any fragmented packet resulting in the handshake problems. Some just do not care and continue to work.
Got it, thank you for the reply.
I had also SSL handshake problems which did not reoccur after I reduced the MTU. Some browsers like Chrome or Firefox (I am not sure) gave error messages and others like Safari failed without specifiying the error.
(But I am failing now reproducing the error by setting the MTU to the default…)
Kerem Bey, günaydın. VPS üzerinde kurduğum bir Wireguard VPNim var. Bu servera cep telefonum, Android televizyonum ve laptopumu wireguard aplikasyonu ile bağlanıyor. Superonline modemi vpn kurulumuna uygun olmadığı için modeme bir kurulum yapamadım. Geçen gün fark ettim ki eğer telefonumda ilk wireguard bağlantısını mobil veri ile yapmazsam Servera bağlantı sağlanamıyor. Aynı şey laptop ve tv için de geçerli. Eğer cep telefonumdan ilk bağlantıyı mobil veri ile yaparsam sonra wifi ile bağlantıyı kurabiliyorum. Önerdiğiniz MTU ayarlarını Windows ve Androidte nasıl yapabilirim?
Merhaba Mithat bey, Turkcell birkaç gün önce Wireguard protokolüne nereye gittiğine bakmaksızın bandwidth sınırlaması getirmeye başladı. Sıkıntınız bundan olabilir. WiFi ile bağlantı kurduğunuzu düşünürken hala mobil veri üzerinden gidiyor olabilirsiniz. MTU ayarlarının bu durumla bir bağlantısı yok fakat WireGuard uugulamasının kendisinde MTU’yu girebileceğiniz bir alan var, oraya uygun değeri girebilirsiniz.
6 aydır sorunsuz kullanırken sorunum dediğiniz gibi 2 hafta önce başladı. Yıkıldım şu an 🙂 Teşekkür ederim.
Çözüm olarak ucuz bir cihaz olan bir Raspberry Pi üzerine Wireguard kurulumu ve onun üzerinde de tünelleme yöntemiyle trafiği Superonline’dan gizlemeyi öneririm. Tabi ikinci bir seçenek de farklı operatöre geçmek ama onlar ne zaman aynı yönteme başlar bilemiyorum. Ne yazık ki ülkemizde altyapı yatırımından çok teknoloji sansürüne çaba ve kaynak harcandığı için yasal haklarımızı kullanabilmek yerine bu tür saçmalıklarla uğraşıyoruz.
Bu bant daraltma olayı aslında aklıma gelmişti. Aynı laptopu TTNET üzerinden bağlayınca sıkıntısız bağlanırken evde deneyince packet loss %70lere varıyordu. Zorla network uzmanı yapacaklar kullanıcıları. Raspberry çok uzun zamandır gündemimdeydi ama artık bu vesileyle kullanımı şart oldu demek ki. Model fark eder mi raspberry için? 3-4 peeri bağlamak için kullanacağım sadece.
Şifreleme yapması gerektiği için Pi 4 olması hız konusunda etkili olur. Yüksek hafızaya çok gerek olmasa da fiyat olarak pek az farkettiği için en az 4 GB ramli almanızı tavsiye ederim.
Pi uzerinden WG tunelleme yaparak sorunun cozuleceginden emin misiniz? AWS’deki server’dan, Pi uzerinde Server olarak calisan WG’a baglanirken bile drop yasiyorum. DigitalOcean’daki sunucuda da ayni sekilde, Pi’deki servera dosya WG olusturdugu network ile transfer yapilamiyor veya ping sonuclari yaridan fazlasi drop ediyor.
Dun sorun yokken ben de bugun itibariyle 90%’lara yaklasan packet loss’larla neredeyse tamamen baglantiyi kaybetmis durumdayim.
Evet. Test ettim ve şu anda sorunsuz şekilde kullanıyorum. Bir miktar bandwidth düşüşü oluyor ama sıfır kayıp yaşıyor.
Nasil oldugunu paylasabilir misiniz? Blog postunda acik etmek istemezseniz mail de atmistim, oradan da yanit verebilirsiniz isterseniz.
Mailinize yanıt yazdım.
Hocam merhabalar aynı mailden bende alabilirmiyim rica etsem aynı sorunu yaşıyorum
Mail atabilir misiniz?
thanks u right, i set mtu to 1412 and i can acccess yahoo.com iplocation.net. before those site can’t loaded after i change it everything normal
Hi i have wireguard connection from 10mb/s 4G modem to wireguard server point. Everything is working normally, I have no problem with internet connection but we have “Oracle Database 10g ” in server point and when i was trying to database querying this occurs very slow. However when i connected on server point LAN to Oracle Database i don’t have any connection trouble about speed. Is my problem related with MTU? Could you help me ? Any help would be appreciated
4G modems generally have 1500 MTU. You can try the default MTU or the recommended minimum of 1280. Oracle may be needing a faster connection though.
Thank you, should i set both 4g modem and wireguard server/client MTU s to 1280?
Just the client. Server will take the setting from that. No need to change the modem MTU.
thanks i set th mtu 1280 but problem still occurs
It may be a problem with Oracle settings then. It can be a very picky software.
Thank you kind sir! The PostUp and PostDown commands fixed my issues on Ubuntu. I was just unable to send any packets to my VPN server when I enabled the wg0 interface and was so frustrated over this.
Thank you once more, this was super helpful!
Glad to be able to help 😊
Thank you! Had the same problem with wireguard and PPPOE, and your write up fixed it.
We have a strange issue in our hub-and-spoke Wireguard network:
– Setting an MTU of 1500 on the Wireguard interface makes everything working for normal clients (not connecting via PPPoE).
– Setting an MTU of 1420 (default) on the Wireguard interface bricks MSSQL connections on the link for all locations and introduces severe issues with PPPoE locations.
– Setting an MTU of 1300 on the Wireguard interface bricks MSSQL connections on the link for all locations but everything else works (including PPPoE locations).
Setting https://www.reddit.com/r/WireGuard/comments/g8tay9/wireguard_mtu_effects_ssl_handshake/fotgzql/?utm_source=reddit&utm_medium=web2x&context=3 didn’t change anything so far.
Who has an idea of what’s going on here? We’re using Azure as our hub.
It works great, thank you! I was about to go back to OpenVPN. Likely i read your article and now everything is working super fine. Thank you.
Thank you so much! I tried for hours to fix these problems and this finally fixed it!
Glad to hear it works!
Thank you for this article. It helped my a lot.
In my case I had to go down to 1380 (O.k., 1400 didn’t work, so I took 1380 and it worked…)
Yeah, different systems may have different MTUs, but it works as long as you find the right value.
Thank you, I ran into this issue with TLS handshake timeouts over the Wireguard VPN. Using
PostUp = iptables -I FORWARD -p tcp –tcp-flags SYN,RST SYN -j TCPMSS –clamp-mss-to-pmtu
PostDown = iptables -D FORWARD -p tcp –tcp-flags SYN,RST SYN -j TCPMSS –clamp-mss-to-pmtu
on the “server” peer fixed the problem by avoiding pMTU discovery entirely. See https://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.mtu-mss.html.
are you aware that this is only for TCP while more and more stuff goes over UDP like HTTP3/CUBIC? so without lower the MTU you may run into issues here and there and MTU troubles are miracles by their nature not to be always visible? lower the wireguard MTU to 1400 to be on the safe side, after doing so speedtest.net to different ISPs from my smartphone over the comany tunnel no longer died
If you are not accessing wireguard directly (e.g. from a VM through a Linux server that routes to wireguard), I had to use this:
iptables -t mangle -A POSTROUTING -p tcp –tcp-flags SYN,RST SYN -o eth0 -j TCPMSS –clamp-mss-to-pmtu
Sorry, that should be -o wg0 not eth0
just remove the interface, it will help you in case some idiotic router in your path has a MTU of 1480 for evereything else
Chain POSTROUTING (policy ACCEPT 39M packets, 37G bytes)
num pkts bytes target prot opt in out source destination
1 87694 5327K TCPMSS tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
I had my own Wireguard VPN server in my home and clients on my mobile phone and laptop set up with MTU=1420 and it worked fine but then I realised my mobile network has MTU less than 1400! So how was it working? I don’t know exactly, but clearly Wireguard doesn’t mind. In fact you can setup the Wireguard VPN with MTU=1500 and it just works, with 1500 byte packets going through the tunnel! I guess it must be slightly less efficient that way though. Certainly avoids all the weird problems you get with other UDP based VPNs if you miscalculate the MTU. Wireguard is THE BEST VPN.
Yes, WireGuard doesn’t mind, the problem is, some sites mind. For example I could access many sites without problems, but could not access Reddit. Or the client for my Viessmann boiler completely stopped. After correcting the MTU, everything went back to normal.
> it just works, with 1500 byte packets going through the tunnel!
no, they don’t if the can’t be fragmented
MTU issues are subtle and unpredictable
the first thing which breaks are TLS handshakes
Great insight. That must be the problem with my connection issues with 1500 mtu. Some sites may be accepting fragmentation but some don’t. That’s why it is not immediately apparent that there are issues.
Great! Thank you.