Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Derive MTU from default interface #11

Open
vadcx opened this issue Apr 29, 2023 · 2 comments
Open

Derive MTU from default interface #11

vadcx opened this issue Apr 29, 2023 · 2 comments
Assignees
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@vadcx
Copy link

vadcx commented Apr 29, 2023

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)

  1. It seems weird that this hits different code paths.
  2. 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:

  1. is their -80 an arbitrary "safe value" or was it determined based on WG encapsulation overhead?
  2. 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 :)

@dadevel dadevel added the bug Something isn't working label Apr 30, 2023
@dadevel
Copy link
Owner

dadevel commented Apr 30, 2023

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.

@dadevel dadevel self-assigned this Apr 30, 2023
@vadcx
Copy link
Author

vadcx commented Apr 30, 2023

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

@dadevel dadevel added the help wanted Extra attention is needed label May 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants