You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MTU — if not specified, the MTU is automatically determined from the endpoint addresses or the system default route, which is usually a sane choice. However, to manually specify an MTU to override this automatic discovery, this value may be specified explicitly.
Currently, leaving MTU in the yaml config of wg-netns as 0 or -1 fails with this error message:
With mtu: 0
pre-up from managed netns
RTNETLINK answers: No such device
pre-down from managed netns
post-down from managed netns
error: subprocess failed: ip -n vpn-ns -4 route add 0.0.0.0/0 dev wg-myvpn: exit code 2 (RuntimeError)
With mtu: -1
pre-up from managed netns
Error: mtu less than device minimum.
pre-down from managed netns
post-down from managed netns
error: subprocess failed: ip -n vpn-ns link set dev wg-myvpn mtu -1 up: exit code 2 (RuntimeError)
It seems weird that this hits different code paths.
I did expect an auto-derived MTU value like wg-quick suggests.
Then I arrived at the wg-quick script (see link above) and thought I'd learn some automatic magic... but no (apart from Bash-hackery-magic). It looks like the code simply subtracts 80 from whatever MTU it found (or from the default 1500).
This brings up the questions:
is their -80 an arbitrary "safe value" or was it determined based on WG encapsulation overhead?
Wouldn't it be different for tunnels going over IPv4 vs IPv6?
PS: If you couldn't tell, I'm investigating those dreaded MTU issues :)
The text was updated successfully, but these errors were encountered:
I never looked into how WireGuard handles MTU so I can't really answer your questions. Does your setup work with the regular wg-quick? Then the easiest solution would probably be to translate the logic from Bash to Python.
Yes, for wg-quick when MTU is left unspecified it calculates the target MTU as 1420 for the interface. Since my ethernet int shows mtu 1500, I can't tell if it did so by calculating (int_mtu - 80) or the default (1500 - 80) -> 1420. Either way, the result is the same, wg-netns has the default sorta set to 1420 too (on the inside).
Before effort is spent implementing the derivation code, I'd like to find out whether the MTU should be different for IPv4 vs IPv6-connected tunnels. Logically it must be.
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
123: wg-quick0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420
wg-quick: master/src/wg-quick/linux.bash#L125
current (gets current default 1420): eff7413c/wgnetns/main.py#L143
From
man wg-quick
:Currently, leaving MTU in the yaml config of wg-netns as
0
or-1
fails with this error message:With
mtu: 0
With
mtu: -1
Then I arrived at the wg-quick script (see link above) and thought I'd learn some automatic magic... but no (apart from Bash-hackery-magic). It looks like the code simply subtracts 80 from whatever MTU it found (or from the default 1500).
This brings up the questions:
PS: If you couldn't tell, I'm investigating those dreaded MTU issues :)
The text was updated successfully, but these errors were encountered: