Posted: Fri Jul 09, 2021 0:43 Post subject: wireguard issue?
I've been having problems with slow web page performance for some time. I don't know when it started but nothing in my configuration has changed. Most of my troubles are with youtube buffering but I've had problems with a couple other sites - mostly forums. I was hoping that it was a firmware issue but I've done 3 firmware upgrades in the past month and still have the problem. Internet speed tests look good though. DNS looks like it's working OK. Reboot of the R9000 for the WAN connection doesn't help. It doesn't matter if it's a wired or wireless connection. Currently running firmware 47033 on my Netgear routers (WDS arrangement). Performance looks much better with wireguard turned off on the clients.
Joined: 18 Mar 2014 Posts: 12889 Location: Netherlands
Posted: Fri Jul 09, 2021 14:15 Post subject:
Maybe the following applies (from the troubleshooting section of the wg guide):
Quote:
MTU size problems (Connection, but no traffic, hang, slow loading, or no streaming media)
MTU problems often manifest themselves as connections which hang during
periods of active usage, or does not load the whole page when browsing.
Or you can connect but not see or use streaming media (like an IP camera, Facebook etc.) or your connection is unexpected slow.
The MTU (Maximum Transmission Units) is the maximum datagram size in bytes that can be sent unfragmented over a particular network path.
Wireguard requires that packets be sent unfragmented.
MTU size is set in the GUI and is standard 1440 for IPv4 and 1420 for IPv6. But sometimes this is too high
especially if you are using connection via LTE.
You can try lowering the MTU wit trial and error i.e. start at 1024 (for IPv6 the minimum MTU is 1280) and work your way up or use the approach describe at: https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-openvpn
I was thinking exactly the same thing - I had almost an identical problem with 2 sites of a customer of mine last month - both supplied by the same ISP. Setting MTU to 1400 magically fixed everything. I then went back and started polishing my flamethrowers since when I meet with a tech next week from that ISP I'm gonna light him up like the 4th of July.
My suggestion though is that before messing with any settings on the router you TEST with setting the MTU on the clients.
If you have a Windows 10 client you can do this at an elevated command prompt with the command
Netsh interface ipv4 set subinterface 'Ethernet" mtu=1400 store=persistent
of course your interface may not be named "Ethernet" so you need to list them first to find the name in use. Look up netsh syntax for this.
Other clients (mac/linux/etc) are going to have different ways of doing this.
One big advantage of doing it this way is even if you get the settings on the router adjusted right, your router will still be fragmenting packets which involves extra work for all the devices. However if your sending host already knows the MTU is lower than 1500 it won't send out a packet that needs to be fragmented in the first place. And it will also assist with MTU path discovery assuming that this protocol isn't blocked since the receiver on the other end of the connection will also know not to send you large packets.
Thanks for the info but I'm wondering if I'm doing something wrong. Here's how I'm doing this:
1. Run ping test with successively smaller packet sizes until I get no error message.
2. Put that packet size into both the wireguard "server" and client.
3. Reboot router and restart wireguard on client.
4. Test again
5. Failure?
a. Yes - repeat test until MTU no longer generates error
1) Goto step 2 above
b. No - end
When I do the ping test with the new MTU size the test fails. So I repeat the test with a reduced MTU until it no longer generates the error (ping: local error: message too long, mtu=####). Then I put the new MTU value in the client and server, reboot/restart, and retest - I get the error message with the new value again.
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Fri Jul 09, 2021 20:38 Post subject:
FWIW, an edit of @egc's wireguard guide for clients connecting to commercial providers acquired a small edit not long ago. It pointed out that even IPv4-only router setups may need MTU 1420 rather than the usual 1440 if the wireguard provider also supports IPv6 clients. That turned out to solve all of my wireguard issues. With 1440 I routinely had failed curls in scripts and other mysterious brief failures. At 1420 it's all golden. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
I solved my MTU issues and it seems that streaming is looking better so far. I ended up setting the MTU to 1390 on the wireguard server and deleted the MTU setting in the clients or set them to auto (which is what happened on the smartphone). I'm using only IPv4.
I solved my MTU issues and it seems that streaming is looking better so far. I ended up setting the MTU to 1390 on the wireguard server and deleted the MTU setting in the clients or set them to auto (which is what happened on the smartphone). I'm using only IPv4.
Turns out the MTU setting didn't fix the problem. So, the search for a solution continues......
