Feature Request - Add MTU Disclaimer to Documentation and/or Script

[DerLeole]

Terms

• This request is not a duplicate of an existing feature
• I have provided as much information as I can about the new feature.

Summary

Wireguard has a default MTU of 1420, Docker's Default Bridge MTU is 1500. This leads to dropped and fragmented packages originating from docker containers. As debuging this error is very obscure, a disclaimer warning of this should be added to the tutorial and the scripts.

Motivation

Why are we doing this?

So others don't have to spend 3 days debugging their entire docker setup to find out why curl requests time out randomly.

What use cases does it support?

Every usecase.

What is the expected outcome?

People know about the default docker vs wireguard MTU mismatch and can take steps to fix it.

Potential conflicts / foreseeable issues

Less inexplicable errors reported.

Additional Context

When installing with default values, the wireguard VPN initializes its wg0 interface with a MTU of 1420.
While this is fine for most network interfaces (Modern standard MTU size seems to be 1500), this poses a peculiar problem with docker and docker compose:

The docker daemon (and therefore default bridge network and docker0 network interface) MTU is 1500. All services running directly on the host or containers using the host network, will accept the new MTU of 1420 imposed by wireguard/wg0, but everything using the default or custom docker bridge networks, will use the docker default MTU of 1500.
When making outside requests from within such a container, the packets need to be split to fit the smaller MTU. Theoretically this would just result in more inefficient traffic, but practically, many networks, firewalls, or cloud services prohibit these fragmented packages from passing through, resulting in lost packets, dropped connections, or timeouts.
This is very hard to debug and can be entirely sporadic.

Additionally, some cards/adapters have a smaller MTU than 1500, which could result in the same package loss.

Below I added some articles outlining the problem and describing the two possible fixes:
https://sylwit.medium.com/how-we-spent-a-full-day-figuring-out-a-mtu-issue-with-docker-4d81fdfe2caf
https://mlohr.com/docker-mtu/
https://www.civo.com/learn/fixing-networking-for-docker
(note that the two docker daemon fixes described above are mutually exclusive as described here).
moby/moby#34981

[mochman]

Thank you for this. I will add a disclaimer about the MTU issue with Docker Networks!

https://github.com/mochman/Bypass_CGNAT/wiki/Docker-Troubleshooting