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/24Client 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 = 15So, 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.
I found this interesting post and just wanted to make sure we have a similar setup: I have two flats, both with a seperate ISP. To connect them I setup pivpn on a Raspberry as wireguard-server on the remote LAN. I then setup a second Pi in my local LAN as wireguard client.
This Pi also acts as a router for other clients on that LAN.
When other clients connect to the LAN they get the IP from the Pi and with it they get a route for the remote LAN-IP-range. So if a client connected in my local LAN wants to send packages to the remote LAN it will know to send the packages to the local Pi. The Pi will then apply the wireguard tunnel and send it out via the router.
This works fine.
I can mount my SMB shares from the remote LAN on my local Pi and then the Pi can act as DLNA-server for my TV.
However, when trying to transfer large amounts of data from the remote LAN to a Windows Laptop on my local LAN the connection is really bad. I think the MTU-fix might do some good here, but I am reluctant to mess with the Windows settings.
In my case, the server sits on an ISP, other than that your configuration looks similar. I think changing the MTU can drastically improve your speed. But also check the upload speed of your remote LAN. It is generally much lower than download speed. That may also be a contributing issue.
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.
Thanks!
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…)
Me too, GitHub and Reddit failed to load.
I have a Setup where my Pi does the PPPoE connection to an IPv6 ONLY ISP
I use WireGuard to connect my Pi to a DualStack VPS via the VPS’s Public IPv6 & AllowedIPs = 0.0.0.0/0
Then to give IPv4 access for all devices in my LAN behind my Pi, I use IPTABLES to NAT to the wg0 interface.
Using MTU of 1280 seems to be working, although I don’t understand how this value is Calculated
It is the minimum. And thus works best with any network configuration with a small performance penalty.
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
Thanks.
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
https://www.linuxtopia.org/Linux_Firewall_iptables/x4700.html
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.
https://support.microsoft.com/de-at/help/159211/diagnoses-and-treatment-of-black-hole-routers
Great! Thank you.