feat(vpn): path MTU discovery to find the best MTU #2586

qdm12 · 2024-11-14T15:46:29Z

Run with image tag pr-2586 that's it 😉

pmtud for IPv4, which takes up to 1s
pmtud for IPv6 (untested), which takes up to 1s
Fallback on a binary search with echo requests of different sizes, which takes up to 3 seconds (3 x 11 ICMP echoes)
if icmp isn't available, fall back to use WIREGUARD_MTU or a default 1300 conservative mtu
Run PMTUD after VPN is up and modify live the VPN link MTU with netlink. This is blocking otherwise other network operations would fail in parallel, due to the temporary high MTU set on the link.

Note for Openvpn, mssfix might still have an impact on changing the mtu

It is not reliable? See qdm12/gluetun#2533 maybe.

frozenfoxx · 2025-09-10T18:13:25Z

Tested this with ProtonVPN using Wireguard, doesn't work for me:

2025-09-10T18:11:16Z INFO [MTU discovery] finding maximum MTU, this can take up to 4 seconds
2025-09-10T18:11:16Z ERROR [vpn] path MTU discovering: finding IPv4 next hop MTU: ICMP destination unreachable: code 13
2025-09-10T18:11:20Z WARN [dns] cannot update filter block lists: Get "https://raw.githubusercontent.com/qdm12/files/master/malicious-hostnames.updated": context deadline exceeded (Client.Timeout exceeded while awaiting headers), Get "https://raw.githubusercontent.com/qdm12/files/master/malicious-ips.updated": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
2025-09-10T18:11:20Z INFO [dns] attempting restart in 20s

qdm12 · 2025-09-12T15:36:53Z

Can you try re-pulling the image and see if it works? It should now fallback on the more-bruteforcey method of finding the MTU, if PMTUD isn't allowed by their firewall.

tribut · 2025-09-13T09:52:44Z

Tried it out and the feature seems to fall back to the minimum MTU of 68:

INFO [MTU discovery] finding maximum MTU, this can take up to 4 seconds
INFO [MTU discovery] VPN interface tun0 MTU set to maximum valid MTU 68

However, when I connect a debian:stable container to the gluetun network, I get responses from the Proton VPN endpoint up to ping -M do -s 1472 -c 1 89.36.76.130 (the link MTU is 1500).

DrummyFloyd · 2025-09-19T00:40:11Z

hi, thank for your hard work !
i've just tested the PR, (wireguard+AirVpn) and i 'e reached 1320 MTU (the best value i've already found earlier )

qdm12 · 2025-09-26T16:52:43Z

@tribut can you run with LOG_LEVEL=debug? 68 is the minimum MTU possible, that's odd.

tribut · 2025-09-27T09:41:46Z

I've tried again with LOG_LEVEL=debug and it looks like some sort of race condition? When the VPN is not healthy on first try, it works after a reconnect:

INFO [wireguard] Connecting to 217.138.216.130:51820
DEBUG [netlink] ip -f inet rule add lookup 51820 pref 101
INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working.
INFO [MTU discovery] finding maximum MTU, this can take up to 4 seconds
DEBUG [MTU discovery] VPN interface tun0 MTU temporarily set to 1440
DEBUG [MTU discovery] finding IPv4 next hop MTU
DEBUG [MTU discovery] falling back to sending different sized echo packets
DEBUG [MTU discovery] testing the following MTUs: [192 316 440 564 688 812 936 1060 1184 1308 1440]
DEBUG [MTU discovery] testing the following MTUs: [79 90 101 112 123 134 145 156 167 178 191]
DEBUG [MTU discovery] testing the following MTUs: [69 70 71 72 73 74 75 76 77 78]
INFO [MTU discovery] VPN interface tun0 MTU set to maximum valid MTU 68
INFO [dns] downloading hostnames and IP block lists
INFO [dns] DNS server listening on [::]:53
INFO [dns] ready
INFO [healthcheck] program has been unhealthy for 6s: restarting VPN (healthcheck error: dialing: dial tcp4: lookup cloudflare.com: i/o timeout)
INFO [healthcheck] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md
INFO [healthcheck] DO NOT OPEN AN ISSUE UNLESS YOU READ AND TRIED EACH POSSIBLE SOLUTION
INFO [vpn] stopping
ERROR [vpn] getting public IP address information: fetching information: Get "https://ipinfo.io/": context canceled
ERROR [vpn] cannot get version information: Get "https://api.github.com/repos/qdm12/gluetun/releases": context canceled
DEBUG [wireguard] closing controller client...
DEBUG [wireguard] removing IPv4 rule...
DEBUG [netlink] ip -f inet rule del lookup 51820 pref 101
DEBUG [wireguard] shutting down link...
DEBUG [wireguard] deleting link...
INFO [vpn] starting
DEBUG [wireguard] Wireguard server public key: XXXXXXXXXXXXXXX
DEBUG [wireguard] Wireguard client private key: XXXXXXXXXXXXXXX
DEBUG [wireguard] Wireguard pre-shared key: [not set]
INFO [firewall] allowing VPN connection...
INFO [wireguard] Using available kernelspace implementation
INFO [wireguard] Connecting to 217.138.216.130:51820
DEBUG [netlink] ip -f inet rule add lookup 51820 pref 101
INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working.
INFO [MTU discovery] finding maximum MTU, this can take up to 4 seconds
DEBUG [MTU discovery] VPN interface tun0 MTU temporarily set to 1440
DEBUG [MTU discovery] finding IPv4 next hop MTU
INFO [MTU discovery] VPN interface tun0 MTU set to maximum valid MTU 1440
INFO [healthcheck] healthy!

But when the VPN is healthy on first connect, it's stuck on 68:

INFO [wireguard] Connecting to 185.159.158.178:51820
DEBUG [netlink] ip -f inet rule add lookup 51820 pref 101
INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working.
INFO [MTU discovery] finding maximum MTU, this can take up to 4 seconds
DEBUG [MTU discovery] VPN interface tun0 MTU temporarily set to 1440
DEBUG [MTU discovery] finding IPv4 next hop MTU
DEBUG [MTU discovery] falling back to sending different sized echo packets
DEBUG [MTU discovery] testing the following MTUs: [192 316 440 564 688 812 936 1060 1184 1308 1440]
DEBUG [MTU discovery] testing the following MTUs: [79 90 101 112 123 134 145 156 167 178 191]
DEBUG [MTU discovery] testing the following MTUs: [69 70 71 72 73 74 75 76 77 78]
INFO [MTU discovery] VPN interface tun0 MTU set to maximum valid MTU 68
INFO [dns] downloading hostnames and IP block lists
INFO [dns] DNS server listening on [::]:53
INFO [healthcheck] healthy!
INFO [dns] ready

I've restarted it a few times and this appears to be reproducible.

strunzoz · 2025-09-29T15:44:03Z

is there a wiki explaining how to do this

qdm12 · 2025-10-02T16:51:58Z

Ok so INFO [MTU discovery] VPN interface tun0 MTU set to maximum valid MTU 68 is definitely wrong when the connection doesn't work. I just changed it to return an error and stop guessing MTUs if all MTU tested (68...1440) fail, since it cannot be lower than 68 for ipv4 for example.

But when the VPN is healthy on first connect, it's stuck on 68

Now I'm a bit confused by this, this is not happening for me or @DrummyFloyd so that's kind of odd! I'm wondering if all MTU testing fail (like above), maybe because ICMP is blocked 🤔 So it's healthy (i.e. for https etc.) but not ICMP 🤔 🤔 That would indicate we definitely need a backup mechanism if ICMP is blocked, for example default to 1300.

@strunzoz run the container image with tag :pr-2586 that's it. The more we can test this with different providers, the better it is 💪 !

qdm12 · 2025-10-03T14:21:44Z

the previous container image was bugged, it's now fixed. New additions:

the lowest MTU possible 68 (for ipv4) is now tested as well
if all MTU testing fail, it doesn't set it to 68, it returns an error which is then handled and it reverts to the VPN interface MTU set before (set by openvpn+OPENVPN_MSSFIX or WIREGUARD_MTU). This can happen if ICMP is blocked OR if the connection simply doesn't work.
VPN_PMTUD variable removed, since it should be on always, especially because it manages to fallback on WIREGUARD_MTU etc. if it fails.

All in all, I think this should work in all situations now:

Your connection works and accepts ICMP: PMTUD finds the optimal MTU
Your connection works and rejects ICMP: PMTUD fails and reverts to the previous MTU set on the VPN interface
Your connection does not work: PMTUD fails and reverts to the previous MTU set on the VPN interface

qdm12 · 2025-10-03T14:22:46Z

@tribut let me know if you still are facing issues 🙏 Thanks!

Copilot

Pull Request Overview

This PR implements path MTU discovery (PMTUD) for VPN connections to automatically find the optimal MTU size. The implementation adds a new pmtud package that performs ICMP-based MTU discovery for both IPv4 and IPv6 connections, with fallback mechanisms when ICMP is blocked.

Key changes:

New pmtud package with IPv4/IPv6 MTU discovery using ICMP packets
Integration of PMTUD into VPN tunnel setup process
Refactoring of VPN setup functions to return full connection objects instead of individual fields

Reviewed Changes

Copilot reviewed 23 out of 24 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
internal/pmtud/*.go	New package implementing path MTU discovery with ICMP probing and binary search fallback
internal/vpn/tunnelup.go	Integration of MTU discovery into tunnel setup process
internal/vpn/wireguard.go	Refactored to return connection object instead of individual fields
internal/vpn/openvpn.go	Refactored to return connection object instead of individual fields
internal/vpn/run.go	Updated to use connection object from setup functions
internal/vpn/interfaces.go	Added LinkSetMTU method to Linker interface
internal/netlink/link.go	Implementation of LinkSetMTU method
cmd/gluetun/main.go	Added LinkSetMTU to Linker interface

Comments suppressed due to low confidence (1)

internal/pmtud/ipv4.go:1

Using panic for invalid IP version is inappropriate in this context. This should return an error instead of panicking, as invalid input should be handled gracefully.

package pmtud

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

internal/pmtud/pmtud.go

internal/vpn/tunnelup.go

internal/pmtud/message.go

- Add `VPN_PMTUD` option enabled by default - One can revert to use `VPN_PMTUD=off` to disable the new PMTUD mechanism

… fails

tribut · 2025-10-15T10:50:00Z

@tribut let me know if you still are facing issues 🙏 Thanks!

Can't reproduce the problem with the latest changes. Thanks.

qdm12 mentioned this pull request Nov 14, 2024

Bug: Really slow speeds (wireguard and openvpn, PIA and windscribe) #2585

Closed

qdm12 referenced this pull request in jfroy/flatops Nov 14, 2024

fix(gluetun): fully disable DOT

9b8b158

It is not reliable? See qdm12/gluetun#2533 maybe.

qdm12 mentioned this pull request Nov 14, 2024

Bug: dns over tls timing out on latest image (TLS handshake) #2533

Closed

qdm12 force-pushed the pmtu branch from 0bd15cf to 90e5ce6 Compare September 10, 2025 15:53

qdm12 force-pushed the pmtu branch from 714695c to a43bbe4 Compare September 11, 2025 14:57

qdm12 mentioned this pull request Sep 11, 2025

Feature request: MTU testing to find the best MTU #2570

Open

qdm12 force-pushed the pmtu branch from 6391d0f to 92efc9c Compare October 3, 2025 14:07

qdm12 requested a review from Copilot October 3, 2025 14:22

qdm12 marked this pull request as ready for review October 3, 2025 14:22

Copilot AI reviewed Oct 3, 2025

View reviewed changes

internal/pmtud/pmtud.go Show resolved Hide resolved

internal/pmtud/pmtud.go Show resolved Hide resolved

internal/pmtud/pmtud.go Show resolved Hide resolved

internal/vpn/tunnelup.go Outdated Show resolved Hide resolved

internal/pmtud/message.go Show resolved Hide resolved

qdm12 added 10 commits October 6, 2025 09:57

pmtud package

e21d798

Use PMTUD to set the MTU to the VPN interface

162d244

- Add `VPN_PMTUD` option enabled by default - One can revert to use `VPN_PMTUD=off` to disable the new PMTUD mechanism

Make binary search faster with 11 parallel queries

d83999d

Update log that PMTUD can take up to 4s

9ad1907

Fix unit test

8bef380

Handle administrative prohibition of ICMP

00bc8bb

Return an error if all MTUs failed to test

5b1dc29

Fallback on 1320 if ICMP is blocked

ccc2f30

Improve logging in case of ICMP blocked

b6e873c

Revert to VPN original MTU (set by WIREGUARD_MTU for example) if ICMP…

c0ebd18

… fails

qdm12 added 2 commits October 6, 2025 09:57

Remove VPN_PMTUD option

f0f3193

Use the VPN local gateway IP address to run path MTU discovery

b9051b0

qdm12 force-pushed the pmtu branch from df4bf4d to b9051b0 Compare October 6, 2025 10:03

Fix unit test

6c25ee5

qdm12 added Priority: 🚨 Urgent Status: 🗯️ Waiting for feedback labels Oct 6, 2025

qdm12 added 2 commits October 14, 2025 17:56

Handle ICMP not permitted errors

5428580

Remove unneeded error context wrapping

906e7b5

qdm12 added 3 commits October 17, 2025 00:17

Merge branch 'master' into pmtu

51fd46b

Run MTU discovery AFTER healthcheck is started

2391c89

Merge branch 'master' into pmtu

90b9e81

qdm12 temporarily deployed to secrets November 12, 2025 01:47 — with GitHub Actions Inactive

This was referenced Nov 13, 2025

Increased bandwith with wireguard and mtu tuning qdm12/gluetun-wiki#140

Closed

Bug: healthcheck error: dialing: dial tcp4: lookup cloudflare.com on 1.1.1.1:53: write udp {IP}:{PORT}->1.1.1.1:53: write: operation not permitted #2794

Closed

Uh oh!

feat(vpn): path MTU discovery to find the best MTU #2586

Are you sure you want to change the base?

feat(vpn): path MTU discovery to find the best MTU #2586

Uh oh!

Conversation

qdm12 commented Nov 14, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

frozenfoxx commented Sep 10, 2025

Uh oh!

qdm12 commented Sep 12, 2025

Uh oh!

tribut commented Sep 13, 2025

Uh oh!

DrummyFloyd commented Sep 19, 2025

Uh oh!

qdm12 commented Sep 26, 2025

Uh oh!

tribut commented Sep 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

strunzoz commented Sep 29, 2025

Uh oh!

qdm12 commented Oct 2, 2025

Uh oh!

qdm12 commented Oct 3, 2025

Uh oh!

qdm12 commented Oct 3, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tribut commented Oct 15, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

qdm12 commented Nov 14, 2024 •

edited

Loading

tribut commented Sep 27, 2025 •

edited

Loading