WireGuard MTU fixes

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.

39 thoughts on “WireGuard MTU fixes”

  1. 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?

    1. 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.

      1. 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.

        1. Çö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.

          1. 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.

            1. Ş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.

          2. 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.

            1. Evet. Test ettim ve şu anda sorunsuz şekilde kullanıyorum. Bir miktar bandwidth düşüşü oluyor ama sıfır kayıp yaşıyor.

              1. Nasil oldugunu paylasabilir misiniz? Blog postunda acik etmek istemezseniz mail de atmistim, oradan da yanit verebilirsiniz isterseniz.

  2. 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

  3. 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
    Thanks.

    1. 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.

  4. 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!

  5. 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.

  6. 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.

  7. 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…)

    1. Harald Reindl

      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

      1. Harald Reindl

        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

  8. 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.

    1. 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.

    2. Harald Reindl

      > 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

      1. 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.

Leave a Comment

Your email address will not be published. Required fields are marked *