-
Notifications
You must be signed in to change notification settings - Fork 27
Description
wg-quick: master/src/wg-quick/linux.bash#L125
current (gets current default 1420): eff7413c/wgnetns/main.py#L143
From man wg-quick:
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 :)