Auteur Sujet: [Résolu] Wireguard : problème de MTU depuis passage en DHCP ?  (Lu 4363 fois)

0 Membres et 1 Invité sur ce sujet

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Bonsoir,

Il y a quelques jours, mon DSLAM a été changé ce qui m'a enfin permis de migrer en DHCP.

A priori si tout fonctionne bien pour la navigation normale, je rencontre un gros problème avec mon tunnel wireguard qui était qu'une stabilité remarquable avant la migration. Maintenant, je ne peux plus utiliser certains protocoles (genre SMB) mais HTTP et SSH par exemple fonctionnent presque comme si de rien n'était. Le plus troublant est que dans une machine virtuelle (virtualbox), tout est purement et simplement inaccessible, j'arrive seulement à ping les équipements, mais aucun protocole ne fonctionne.

Lorsque j'étais en PPPoE j'avais :
-tunnel V6 HE (pour avoir une IP fixe) : MTU 1472
-interfaces wg MTU 1420
-le reste du LAN en 1500

En DHCP :
-plus de tunnel HE (je me connecte en V4)
-interfaces wg toujours en 1420

Avec cette config, HTTP et SSH fonctionnent de même que les partages SMB mais seulement à partir de mon PC portable en wifi  ??? (sur mon desktop relié par câble, c'est niet). Depuis une VM (sur le portable ou le desktop, rien ne fonctionne comme mentionné précédemment).

Je me suis alors dit que je devrais peut-être augmenter légèrement la MTU des interfaces WG à 1440 pour éviter la fragmentation : ça ne fonctionne pas mieux.

Voici un exemple de ce que j'ai quand je fais une capture de VM windows (ici c'est une tentative d'ajout d'une station à mon domaine active directory) c'est peu ou prou la même si je tente d'accéder à l'interface du routeur en face.

J'ai l’impression que ça touche TCP et non UDP car tout ce qui est requête DNS par ex, passe bien.

Merci d'avance

« Modifié: 21 mars 2021 à 03:00:17 par renaud07 »

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Wireguard : problème de MTU depuis passage en DHCP ?
« Réponse #1 le: 18 mars 2021 à 18:17:23 »
Je viens repasser en PPPoE sur les 2 connexions pour voir si mon problème se résolvait, mais ce n'est pas le cas... toujours impossible d'accéder au LAN d'en face via les VM.

Franchement je ne vois pas ce qui pourrait clocher. La seule chose qui a changée dans le setup c'est la version d'OWRT sur le routeur "remote" qui est en 18.06.0, j'avais déjà eu des problèmes de stablité par le passé avec cette version, et je l'avais remise pour tester la connectivité IPv6 car sinon le client n'était pas en mesure d'envoyer les options.

Je vais donc faire un rollback sur la 17.04. En  espérant que ce soit bien la source du problème.

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Wireguard : problème de MTU depuis passage en DHCP ?
« Réponse #2 le: 18 mars 2021 à 21:31:18 »
Firmware d'origine restauré... ça ne fonctionne toujours pas  :(

Honnêtement j'ai plus d'idée. Tout est comme à l'origine et rien... ou alors c'est le DSLAM lui-même (je n'ai pas pensé de faire un test complet avant de modifier) mais ça serait quand même très improbable.

lechercheur123

  • AS2027 MilkyWan
  • Expert
  • *
  • Messages: 1 296
  • Montauban (82)
    • AS208261 - Pomme Télécom
Wireguard : problème de MTU depuis passage en DHCP ?
« Réponse #3 le: 18 mars 2021 à 22:10:26 »
Avec cette config, HTTP et SSH fonctionnent de même que les partages SMB mais seulement à partir de mon PC portable en wifi  ??? (sur mon desktop relié par câble, c'est niet).

C'est bizarre cette histoire.

Ils sont montés où tes tunnels ? Directement sur le PC fixe ?

Je n'ai pas très bien compris pourquoi le tunnel HE était HS. Tu peux en dire plus ?

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Wireguard : problème de MTU depuis passage en DHCP ?
« Réponse #4 le: 19 mars 2021 à 00:32:21 »
C'est vrai que j'aurais du détailler un peu.

Les tunnels HE sont montés directement sur les routeurs. Ils servent exclusivement d'ip fixe pour WG.
Pour WG, de mon côté c'est sur mon Raspberry Pi et de l'autre il est dans une VM debian sur proxmox.

Concernant le tunnel HE "HS" il ne l'a jamais été. Vu que j'ai du DHCP et une IPv4 fixe maintenant je l'avais simplement enlevé de l'équation.

Pour mes partages SMB, une fois que j'ai eu fini de tout remettre d’origine (donc PPPoE + HE) j'ai refait un nouveau test et cette fois j'arrive bien à y accéder depuis mon PC fixe... Bref, c'est un peu confus.

Seules les VM et je viens de le découvrir mon smartphone n'a plus accès au LAN d'en face. Alors que ça fonctionnait hyper bien depuis des mois auparavant. Vraiment je ne comprends pas où ça coince.

J'ai à priori trouvé un contournement possible pour les VM : en les mettant en mode NAT, elles utilisent l'ip de l’hôte et là le trafic passe bien, mais ce n'est pas idéal...

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Wireguard : problème de MTU depuis passage en DHCP ?
« Réponse #5 le: 19 mars 2021 à 03:00:25 »
Oh pu**** j'ai enfin trouvé la source du problème et vous n'allez jamais le croire.

C'était une case cochée en trop : Drop invalid packets dans le firewall d'OWRT (dont je ne me rappelais plus que j'y avais touché tellement j'ai fait de manip ces derniers jours). Désormais tout est débloqué : les VM ont de nouveau accès au LAN en mode bridge ainsi que mon smartphone !

Je pouvais m'amuser longtemps avec la MTU  ::)

Vais-je pouvoir enfin configurer la connexion en DHCP ?  :P


renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
[Résolu] Wireguard : problème de MTU depuis passage en DHCP ?
« Réponse #6 le: 21 mars 2021 à 03:02:38 »
Configuration DHCP effectuée sur les deux routeurs : ça tourne nickel.

Tout ça pour une maudite case...

zoc

  • Abonné Orange Fibre
  • *
  • Messages: 4 260
  • Antibes (06) / Mercury (73)
[Résolu] Wireguard : problème de MTU depuis passage en DHCP ?
« Réponse #7 le: 21 mars 2021 à 07:19:14 »
C’est quand même étonnant qu’il faille autoriser les paquets invalides pour que WireGuard fonctionne correctement.

Et d’autant plus parce que de mon côté sur mon ER4 je droppe les paquets invalides sur toutes mes interfaces et que je n’ai aucun problème avec mon serveur WireGuard (qui, de plus, est une VM proxmox sur un hôte en mode bridge avec openvswitch)...

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
[Résolu] Wireguard : problème de MTU depuis passage en DHCP ?
« Réponse #8 le: 21 mars 2021 à 18:26:27 »
Moi aussi je suis perplexe.

C'est quel types de paquets qui sont considéré comme invalide ?

Car je vois que j'ai beaucoup de retransmission ou duplicate sur le trafic des VMs justement (et quasi rien à partir de l’hôte). Je me demande si ça vient pas de là.

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
[Résolu] Wireguard : problème de MTU depuis passage en DHCP ?
« Réponse #9 le: 22 mars 2021 à 01:45:22 »
J'ai fait un petit ping pour voir le temps que ça mettait : je passe de ~100ms à ~35ms en V4 vs V6 avec HE  8)

Mais une chose m'interpelle : si je fais un traceroute pour joindre l'autre bout je ne passe que par un routeur (ce qui est logique les 2 lignes sont sur le même NRA).

ping 86.194..x
PING 86.194.x.x (86.194.x.x) 56(84) bytes of data.
64 octets de 86.194.x.x : icmp_seq=1 ttl=62 temps=38.1 ms
64 octets de 86.194.x.x : icmp_seq=2 ttl=62 temps=36.5 ms
64 octets de 86.194.x.x : icmp_seq=3 ttl=62 temps=38.0 ms
64 octets de 86.194.x.x : icmp_seq=4 ttl=62 temps=36.8 ms
64 octets de 86.194.x.x : icmp_seq=5 ttl=62 temps=38.3 ms
64 octets de 86.194.x.x : icmp_seq=6 ttl=62 temps=37.3 ms
64 octets de 86.194.x.x : icmp_seq=7 ttl=62 temps=36.4 ms
64 octets de 86.194.x.x : icmp_seq=8 ttl=62 temps=37.1 ms
64 octets de 86.194.x.x : icmp_seq=9 ttl=62 temps=37.9 ms
64 octets de 86.194.x.x : icmp_seq=10 ttl=62 temps=36.8 ms
^C
--- statistiques ping 86.194.x.x ---
10 paquets transmis, 10 reçus, 0 % paquets perdus, temps 9012 ms

traceroute 86.194.x.x
traceroute to 86.194.x.x (86.194.x.x), 30 hops max, 60 byte packets
 1  bt.lpa.lan (192.168.1.1)  2.769 ms  2.634 ms  2.947 ms
 2  80.10.238.65 (80.10.238.65)  19.792 ms  21.025 ms  24.904 ms
 3  lfbn-lyo-1-x-x.w86-194.abo.wanadoo.fr (86.194.x.x)  40.273 ms  42.827 ms  43.106 ms

Mais ce que je n'explique pas c'est qu'un ping vers lafibre soit plus rapide à ~20ms avec pas moins de 7 routeurs traversés.

ping lafibre.info
PING lafibre.info (80.67.167.77) 56(84) bytes of data.
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=1 ttl=54 temps=21.7 ms
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=2 ttl=54 temps=22.3 ms
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=3 ttl=54 temps=21.7 ms
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=4 ttl=54 temps=22.6 ms
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=5 ttl=54 temps=21.4 ms
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=6 ttl=54 temps=22.9 ms
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=7 ttl=54 temps=21.7 ms
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=8 ttl=54 temps=24.7 ms
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=9 ttl=54 temps=21.7 ms
64 octets de lafibre.cust.milkywan.net (80.67.167.77) : icmp_seq=10 ttl=54 temps=23.3 ms
^C
--- statistiques ping lafibre.info ---
10 paquets transmis, 10 reçus, 0 % paquets perdus, temps 9015 ms
rtt min/avg/max/mdev = 21.361/22.405/24.655/0.959 ms

traceroute lafibre.info
traceroute to lafibre.info (80.67.167.77), 30 hops max, 60 byte packets
 1  bt.lpa.lan (192.168.1.1)  1.341 ms  1.481 ms  2.068 ms
 2  80.10.238.65 (80.10.238.65)  19.300 ms  20.581 ms  21.198 ms
 3  ae93-0.nclyo201.rbci.orange.net (193.251.109.166)  22.910 ms  23.999 ms  24.921 ms
 4  ae42-0.nrlyo201.rbci.orange.net (193.252.101.234)  26.234 ms  27.897 ms  28.392 ms
 5  ae43-0.nolyo101.rbci.orange.net (193.252.101.225)  28.717 ms  29.179 ms  29.827 ms
 6  193.252.227.98 (193.252.227.98)  30.441 ms  28.583 ms  29.439 ms
 7  appliwave.ly1-1.hopus.net (37.77.39.11)  30.045 ms  21.659 ms  19.765 ms
 8  lo0.ccr2004.edge.vnx.bb.ip4.milkywan.net (80.67.167.2)  20.899 ms  25.975 ms  27.705 ms
 9  te0.rb4011.col.vnx.infra.ip4.milkywan.net (80.67.167.194)  27.656 ms  27.619 ms  20.033 ms
10  lafibre.cust.milkywan.net (80.67.167.77)  21.654 ms  23.886 ms  25.828 ms

Une idée ?


lechercheur123

  • AS2027 MilkyWan
  • Expert
  • *
  • Messages: 1 296
  • Montauban (82)
    • AS208261 - Pomme Télécom
[Résolu] Wireguard : problème de MTU depuis passage en DHCP ?
« Réponse #10 le: 22 mars 2021 à 14:51:37 »
Mais une chose m'interpelle : si je fais un traceroute pour joindre l'autre bout je ne passe que par un routeur (ce qui est logique les 2 lignes sont sur le même NRA).

L'autre bout de ton tunnel WG est sur une autre ligne ADSL ?

Une idée ?

Visiblement, entre toi et le premier routeur (80.10.238.65) tu as 19ms. Donc je trouve normal que tu ais 38ms pour aller sur un autre ADSL proche de chez toi.
L'ADSL amène beaucoup de latence. Beaucoup plus que la fibre (c'est sûrement une histoire de codage/décodage, correction d'erreurs, mais je ne m'y connais pas trop en ADSL).

Pour lafibre.info, le ping n'est que légèrement supérieur à 21ms car tu es visiblement près de Lyon, et Orange est connecté à Milkywan à Lyon. Or, lafibre.info est porté par Milkywan (au moins en partie), et est près de Lyon. Ce qui fait que tu as très peu de ping vers lafibre.info

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
[Résolu] Wireguard : problème de MTU depuis passage en DHCP ?
« Réponse #11 le: 22 mars 2021 à 16:02:23 »
L'autre bout de ton tunnel WG est sur une autre ligne ADSL ?

Yep

Visiblement, entre toi et le premier routeur (80.10.238.65) tu as 19ms. Donc je trouve normal que tu ais 38ms pour aller sur un autre ADSL proche de chez toi.
L'ADSL amène beaucoup de latence. Beaucoup plus que la fibre (c'est sûrement une histoire de codage/décodage, correction d'erreurs, mais je ne m'y connais pas trop en ADSL).

Pour lafibre.info, le ping n'est que légèrement supérieur à 21ms car tu es visiblement près de Lyon, et Orange est connecté à Milkywan à Lyon. Or, lafibre.info est porté par Milkywan (au moins en partie), et est près de Lyon. Ce qui fait que tu as très peu de ping vers lafibre.info

Après réflexion j'en étais arrivé un peu à la même conclusion. J'ai plus de latence entre mes 2 lignes car les paquets doivent passer 4 fois par de l'adsl alors que vers la fibre.info, la majorité passe par de la fibre et 2 fois par la ligne.