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.

TÜRK OKURLAR İÇİN: Bu sayfaya Turkcell/Superonline’ın, sözde destek merkezinin bile haberinin olmadığı Wireguard bant kısıtlaması nedeniyle çözüm ararken geldiyseniz ve evinizde Wireguard bir linux gateway üzerinde kuruluysa muhtemel bir çözüm için e-posta yoluyla bana ulaşabilirsiniz.

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. So I use a permanent 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. The home gateway passes all traffic to the VPN server, so for some devices, I route all traffic through that gateway resulting in an encrypted and restriction free connection.

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):

Address =
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

PresharedKey = PRESHARED_KEY
AllowedIPs =,

Client configuration (Home gateway):

Address =
MTU = 1412
PostUp = ip route add SERVER_PUBLIC_IP/32 via 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 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

PresharedKey = PRESHARED_KEY
Endpoint = SERVER_PUBLIC_IP:51820
AllowedIPs =
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 (You should find the maximum MTU for your network if this does not work, but generally a value of 1380 should work for nearly everyone except extreme cases). 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 block for its internal communication and 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.

You may also like...

39 Responses

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

  2. Chris says:

    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


    • Chris says:

      Sorry, that should be -o wg0 not eth0

      • Harald Reindl says:

        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 — * * tcp flags:0x06/0x02 TCPMSS clamp to PMTU

  3. Raman says:

    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.

    • Harald Reindl says:

      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

  4. Thomas says:

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

  5. Adrian Groh says:

    Thank you so much! I tried for hours to fix these problems and this finally fixed it!

  6. Tacco says:

    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. Thomas says:

    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.

  8. Bofh says:

    Thank you! Had the same problem with wireguard and PPPOE, and your write up fixed it.

  9. Dominik says:

    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!

  10. aLFA says:

    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

  11. Alexis says:

    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

  12. Mithat says:

    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?

    • Kerem says:

      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.

      • Mithat says:

        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.

        • Kerem says:

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

          • Mytonn says:

            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.

            • Kerem says:

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

          • Kuray says:

            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.

Leave a Reply

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