Information(s) :
Cette procédure concerne uniquement les utilisateurs qui accèdent à leur NAS ou à leur serveur à travers un tunnel VPN WireGuard. Si vous êtes en réseau local (sans VPN), elle ne s’applique pas.
Symptômes typiques corrigés par cette procédure :
- navigation très lente dans les partages réseau (SMB / lecteurs mappés) une fois connecté au VPN ;
- dossiers qui mettent longtemps à s’ouvrir, transferts qui se figent à mi-chemin ;
- partages SMB inaccessibles ou qui se déconnectent alors que le ping vers le NAS fonctionne.
Cause : le tunnel WireGuard ajoute son propre en-tête à chaque paquet. Si le MTU (taille maximale des paquets) de l’interface WireGuard est plus grand que ce que le lien Internet réel peut transporter, les gros paquets SMB sont fragmentés ou purement perdus. Le SMB, très sensible à ce phénomène, se met alors à ramer ou ne répond plus. Ajuster le MTU dans la configuration WireGuard résout le problème.
Prérequis :
- être connecté au NAS / serveur via un tunnel WireGuard fonctionnel (le ping vers l’IP du NAS répond) ;
- pouvoir modifier la configuration WireGuard : le fichier
.conf, l’application WireGuard (Windows / macOS / mobile) ou l’interface du routeur / pare-feu ; - connaître l’adresse IP du NAS ou du serveur dans le VPN (exemple :
10.0.0.10).
Procédure :
1. Trouver le bon MTU (diagnostic)
On cherche la plus grosse taille de paquet qui passe sans fragmentation jusqu’au NAS. On teste avec le drapeau « Don’t Fragment ». Commencez à 1372 et baissez de 20 en 20 tant que le test échoue.
Sous Windows (invite de commandes) — le nombre est la taille utile, il faut lui ajouter 28 pour obtenir le MTU :
ping -f -l 1372 10.0.0.10
Sous macOS / Linux :
ping -D -s 1372 10.0.0.10
- Si vous voyez « Il faut fragmenter le paquet » / « message too long » : la taille est trop grande, réduisez (1352, 1332, 1312, 1252…).
- La plus grande valeur qui répond correctement est votre taille utile. MTU du chemin = cette valeur + 28.
MTU à mettre dans WireGuard = MTU du chemin − 80 (marge pour l’en-tête WireGuard, valable IPv4 et IPv6).
Exemple : ping -f -l 1372 passe mais pas 1392 → taille utile 1372 → MTU du chemin 1400 → MTU WireGuard = 1320.
Si vous ne voulez pas diagnostiquer, testez directement ces valeurs dans l’ordre : 1420 → 1412 → 1380 → 1320 → 1280. 1280 est la valeur la plus basse et la plus sûre (fonctionne quasiment partout, y compris en 4G/5G).
2a. Cas d’un fichier .conf (Linux, routeur, pare-feu OPNsense/pfSense)
Ajoutez la ligne MTU dans la section [Interface] :
[Interface]
PrivateKey = <votre_cle>
Address = 10.0.0.2/24
MTU = 1320
[Peer]
PublicKey = <cle_du_serveur>
Endpoint = vpn.exemple.fr:51820
AllowedIPs = 10.0.0.0/24
Puis rechargez le tunnel :
wg-quick down wg0 && wg-quick up wg0
2b. Application WireGuard (Windows / macOS)
- Ouvrez l’application WireGuard et désactivez le tunnel concerné.
- Cliquez sur Modifier (Edit).
- Dans la section
[Interface], ajoutez la ligneMTU = 1320. - Enregistrez, puis réactivez le tunnel.
2c. Application mobile (iOS / Android)
- Ouvrez le tunnel, appuyez sur Modifier (icône crayon).
- Renseignez le champ MTU avec la valeur
1320(sur Android : « Interface » > MTU). - Enregistrez et relancez le tunnel.
3. Vérifier
- Reconnectez le tunnel, ré-ouvrez le partage SMB : la navigation doit être fluide et stable.
- Si c’est mieux mais pas parfait, descendez d’un cran (ex. 1320 → 1280).
- Si l’accès SMB reste capricieux malgré un MTU bas, contactez le support : le problème peut venir du MSS clamping à configurer côté routeur/serveur (
MSS = MTU − 40).