angristan / wireguard-install

WireGuard VPN installer for Linux servers
https://stanislas.blog/2019/01/how-to-setup-vpn-server-wireguard-nat-ipv6/
MIT License
7.96k stars 1.3k forks source link

Added MTU #224

Open Valerie277 opened 3 years ago

Valerie277 commented 3 years ago

With the mtu we send less packages but have them full. Increased my speed by 50%.

angristan commented 3 years ago

I'm not sure if we want to set his by default for everyone.

wc7086 commented 3 years ago

I'm not sure if we want to set his by default for everyone.

The overhead of WireGuard breaks down as follows:

  • 20-byte IPv4 header or 40 byte IPv6 header
  • 8-byte UDP header
  • 4-byte type
  • 4-byte key index
  • 8-byte nonce
  • N-byte encrypted data
  • 16-byte authentication tag

So, if you assume 1500 byte ethernet frames, the worst case (IPv6) winds up being 1500-(40+8+4+4+8+16), leaving N=1420 bytes. However, if you know ahead of time that you're going to be using IPv4 exclusively, then you could get away with N=1440 bytes.

https://lists.zx2c4.com/pipermail/wireguard/2017-December/002201.html

wg-quick sets the MTU to 1420 by default. Under Windows, when I do not specify the MTU as 1420 on the client, the netsh interface ipv4 show subinterfaces command queries the default MTU to 1420, but netsh interface ipv6 show subinterfaces can see that the default MTU is 65535, so the Windows client needs to specify the MTU value of 1420.

If you do not set the MTU, IPv6 will not work properly. If you want to use IPv6, set the MTU to 1420 or less.

wc7086 commented 3 years ago

If you are an Apple user, you may need to set the MTU to 1280, which may be the minimum MTU required to start wireguard. The following are best practices for developers, because I don’t know Apple products, so I’m not sure if setting the MTU to 1280 is accurate enough.

Hi, we have users that are reporting many issues when using the WireGuard client on MacOS laptops with IPv6 networks. It seems that most of those issues disappear when we set the MTU to 1280 in the configuration.

Since they are using laptops, some are frequently on badly behaved networks. Reading the source code, it seems that this situation is handled differently on iOS vs MacOS in generateNetworkSettings():

    let mtu = tunnelConfiguration.interface.mtu ?? 0

    /* 0 means automatic MTU. In theory, we should just do
     * `networkSettings.tunnelOverheadBytes = 80` but in
     * practice there are too many broken networks out there.
     * Instead set it to 1280. Boohoo. Maybe someday we'll
     * add a nob, maybe, or iOS will do probing for us.
     */
    if mtu == 0 {
        #if os(iOS)
        networkSettings.mtu = NSNumber(value: 1280)
        #elseif os(macOS)
        networkSettings.tunnelOverheadBytes = 80
        #else
        #error("Unimplemented")
        #endif
    } else {
        networkSettings.mtu = NSNumber(value: mtu)
    }

Does networkSettings.tunnelOverheadBytes = 80 means the MTU will used be the one of the interface minus 80 bits of overhead for the WireGuard protocol?

Some of our users where tethering over their phone connection so it seems that 1280 is appropriate in that case, but I’m confused as to why connections not going through the WireGuard tunnel where not impacted in that case.

Does it really make sense to treat laptops and iOS devices differently are sometime connected to random networks? Should this be changed to networkSettings.mtu = NSNumber(value: 1280) in all cases?

https://lists.zx2c4.com/pipermail/wireguard/2019-December/004783.html