"very high" (probably?) MTU being set automatically on wireguard interface

Yoel Navas Escalante

11/18/23, 4:43 PM

So, I have a VPS running on Amazon Lightsail and I installed wireguard on it; I setup an interface this way:

[Interface]
Address = 10.255.128.1/24
MTU = 1420
SaveConfig = true
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 51820
PrivateKey = ********************************************

Then something very weird happened: I bring the iface UP and run sudo ip addr, then I get this output

3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8921 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.255.128.1/24 scope global wg0
       valid_lft forever preferred_lft forever

The weird thing? Look at the mtu 8921

Then I go to the conf file, and for my surprise, the value I set for mtu is being overwritten with 8921.

sudo systemctl status [email protected] gives this output:

Nov 18 16:04:08 ip-172-26-0-77 systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
Nov 18 16:04:08 ip-172-26-0-77 wg-quick[583]: [#] ip link add wg0 type wireguard
Nov 18 16:04:09 ip-172-26-0-77 wg-quick[583]: [#] wg setconf wg0 /dev/fd/63
Nov 18 16:04:09 ip-172-26-0-77 wg-quick[583]: [#] ip -4 address add 10.255.128.1/24 dev wg0
Nov 18 16:04:09 ip-172-26-0-77 wg-quick[583]: [#] ip link set mtu 8921 up dev wg0
Nov 18 16:04:09 ip-172-26-0-77 wg-quick[583]: [#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING >
Nov 18 16:04:09 ip-172-26-0-77 systemd[1]: Finished WireGuard via wg-quick(8) for wg0.

What's going on here?

3412

1 + 0

mtu

amazon-lightsail

wireguard

Score:4

Server

Justin Ludwig

11/21/23, 11:06 PM

SaveConfig = true directs wg-quick to overwrite a WireGuard interface's config file with the interface's current settings when the interface is shut down (or restarted). This is undesirable behavior for many uses of WireGuard, which is why it's not on by default. The most common reason why you'd want to turn it on is if you make frequent changes to an active WireGuard interface while it's up, and don't want have to duplicate those changes manually in the config file.

If you do use SaveConfig = true, and want to make a change to the WireGuard interface, you typically would do it via the wg command (for WireGuard-specific settings), or (on Linux) the ip command (for general network interface settings).

For example, to set the MTU of an active WireGuard interface named wg0 to 1420, run the following command (as root):

ip link set wg0 mtu 1420

Alternatively, shut down the WireGuard interface with the wg-quick down wg0 command (or systemctl stop wg-quick@wg0 if you're running it as a systemd service), make the change to the WireGuard config file, and then start up the interface again with the wg-quick up wg0 command (or systemctl start wg-quick@wg0).

If you don't explicitly configure an MTU for a WireGuard interface, wg-quick is smart enough to make a good guess for you, based on the MTU of the (physical) network interface it expects the tunnel to use. The network interface of most EC2 instances use jumbo frames (MTU of 9001). So on those EC2 instances, wg-quick will guess that the WireGuard interface should use an MTU of 8921 (80 bytes smaller than 9001, to allow each packet to be wrapped with UDP/IP and WireGuard headers).

So what probably happened is that you originally configured the WireGuard interface with SaveConfig = true, but without an MTU. When you started the interface up with wg-quick, it set an MTU of 8921 for the interface. Then, while the interface was up, you edited the WireGuard configuration file to add MTU = 1420. When you restarted the interface, your change was overwritten by existing MTU for the interface.

+ 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: "very high" (probably?) MTU being set automatically on wireguard interface

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.