Bonjour,
 
Ça fait plusieurs mois maintenant que je cherche d'où peuvent venir les TCP retransmission ou duplicate ACK lorsque je passe par mon VPN wireguard.
 
J'ai tenté plusieurs fois de modifier la MTU, ça persiste toujours. Où alors est-ce simplement dû à la connexion faiblarde  ?
 
Ce tunnel est monté entre ma connexion ADSL et celle de mes parents. Connexion Orange en DHCP (MTU 1500), le tunnel est réglé comme l'indique la doc à 1420. Les deux LAN sont à 1500.
 
Merci  

Bonjour,
 
Il serait intéressant de comparer en utilisant plus de VPN. C'est à dire en mettant en place un relais de port sur la box de tes parents, qui soit actif pour ta seule adresse IP.
 
Si tu fais une nouvelle capture de paquets et que tu constates le même genre de retransmissions TCP, tu sais alors que c'est dû à la connexion.
 
 
Concernant la MTU, c'est plus compliqué que cela. En effet, ce qui compte est la MTU du chemin complet, la Path MTU (PMTU). Voir https://fr.wikipedia.org/wiki/Path_MTU_discovery  .
 
Par exemple, tu peux avoir une MTU sur la partie ADSL de 1498 octets au lieu de 1500. Et Wireguard qui ne gère pas particulièrement bien les questions de PMTUd tentera d'envoyer des paquets UDP d'une taille de 1500 octets qui seront supprimés.
Wireguard, qu'il reçoive ou non des messages ICMP indiquant qu'il envoie des données d'une taille trop importante, continuera en vain à essayer d'envoyer des paquets.
 
Tu peux tester la PMTU avec, sous Windows, une commande de ce genre :  ping -f -l 1472 www.lafibre.info
( mettre éventuellement une IP du LAN distant à la place du nom de domaine. Le test peut aussi se faire avec une IP sur ton propre LAN )
 
L'entête ICMP (ping) ajoutant 8 octets et l'entête IPv4 ajoutant 20 octets, 1472 octets deviennent 1500. Et si tu testes avec une valeur de 1473, tu devrais logiquement recevoir un message comme quoi le paquet devrait être fragmenté mais qu'il y a l'indicateur "Don't Fragment".
Si tu ne reçois rien en retour de ta commande ping au bout de plusieurs dizaines de secondes, ni réponse ni message d'erreur, c'est qu'il y a un problème de PMTUd.

Merci pour ta réponse.
 
A priori, la PMTU fonctionne, je reçois bien un message de fragmentation avec 1473.

Par contre, avec 1472, il se passe des trucs bizarres :  
 
Au premier ping vers le routeur de mes parents, ça passe sans soucis. Deuxième essai sur une autre IP du LAN : ah, ça me dit que le paquet doit être fragmenté. Je réessaie, plus de message. Je tente encore une autre IP : toujours pas de message. Je refait l'IP précédente : le message est de retour.
 
Bref, c'est bizarre. Un coup ça passe un coup ça passe pas. Par contre, lorsque ça passe, sur une capture, je vois bien que c'est quand même fragmenté ce qui ma parait normal au vu de la MTU du tunnel.
 
Du coup, j'arrive pas à déterminer si c'est le comportement normal ou non.
 
EDIT : J'ai testé en VM et j'avais pas fait gaffe, c'était en mode NAT. Je suis passé en pont, et cette fois avec 1472, j'ai bien le message à chaque fois. Rien ne passe. Tout comme sur mon hôte Linux  

Une fois que tu auras déterminé manuellement la PMTU entre vos deux connexions ADSL, à grands coups de ping, tu pourras calculer la MTU pour Wireguard.
 
Dans ce message, le créateur de Wireguard indique que le VPN consomme 40 octets pour son utilisation propre.
A cela il faut ajouter les 20 octets d'un en-tête IPv4 si l'on fait passer de l'IPv4 à travers le lien Wireguard. Ou les 40 octets d'un en-tête IPv6 le cas échéant.
 
Imaginons que tu détermines une PMTU de 1456 octets entre vos deux boxs (donc une valeur de 1428 filée en argument à la commande ping) et que tu veuilles faire passer de l'IPv4 uniquement, il faudra ajouter aux deux fichiers de configuration Wireguard le réglage pour une MTU valant 1396 octets ( 1456 - 40 - 20 ).
Si tu veux également de l'IPv6, il faudra un réglage pour une MTU valant 1376 octets ( 1456 - 40 - 40 ).

A priori, j'ai bien 1500 entre les deux.
 
Un ping à 1472 en attaquant l'ip publique, passe sans problème
 
Du coup, mon réglage à 1420 pour de l'ipv6 est correct. Je vais essayer à 1440, voir si y'a du mieux car pour le moment pas de v6 sur le tunnel.

Bon, ça ne change pas grand chose.
 
Ce qui est bizarre, c'est que ça n'intervient qu'à des moments précis
 
J'ai tenté un transfert de fichiers via SMB. Sur toute la partie dialogue SMB, pas d'erreur. Par contre quand Wireshark détecte l'échange comme TCP lorsque le transfert se lance, c'est le festival, toutes les 3 trames j'ai un Dup ACK... ou alors y'a aussi des erreurs avec SMB, mais non visible ?