La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Orange / Sosh => 
Incidents Orange => Discussion démarrée par: nicox11 le 30 avril 2023 à 10:11:12
-
Bonjour,
J'ai voulu mettre en place un serveur VPN (Wireguard) sur le port udp 53 sur ma connexion fibre fixe Orange.
Clairement je rencontre des soucis.
J'ai effectué quelques tests et il semblerait que c'est vraiment le port udp 53 qui a des problèmes.
Globalement, j'utilise un smartphone en 4G (Sosh) pour me connecter en interne (fibre fixe Orange) sur mon serveur VPN Wireguard.
Dans mon premier test, le serveur écoute sur le port udp 53 :
CAS1
Dans ce cas, la connexion VPN fonctionne un court temps (quelques minutes). Ensuite le VPN ne marche plus. Avec un tcpdump sur le serveur, on peut voir une armée de SYN-ACK en direction du mobile 4G sans réponse : Donc le mobile continue à envoyer du trafic mais il ne semble jamais recevoir les réponses.
Avec une capture en simultanée sur le port physique, on peut voir que les SYN ACK partent bien encapsulé dans le paquet UDP chiffré vers internet.
Après quelques temps (minutes/secondes), la connexion reprends sans problème.
Dans mon deuxième test, pour vérifier mon infrastructure, j'ai basculé le mobile sur le vlan wifi :
CAS 2
Dans ce cas, la connexion VPN fonctionne sans problème. Tout le trafic reste en local entre deux VLAN. Cela fait supposer qu'il n'y a pas de problème avec le smartphone.
Pour le troisième test, j'ai simplement repris le cas 1, sauf que j'ai modifié le port d'écoute de 53 vers un port plus haut, le port 51820 (port par défaut de wireguard).
Et dans ce cas, aucun problème. Même lorsque je suis en 4G !
Je reste perplexe face à cette situation. Je ne suis pas du genre à vouloir accuser le réseau opérateur au moindre problème, mais les résultats sont troublant :
- Pourquoi cela se mettrait-il à marcher en changeant simplement de port (53 -> 51820) ?
- Si c'était un bridage/problème du smartphone, pourquoi en WIFI tout en gardant le port 53 je n'ai pas de problème ?
De mon point de vue, cela ressemble à un bridge/anti DDOs sur le port UDP 53 en direction des devices 4G ? Le smartphone envoi bien du traffic udp 53 mais ne semble plus en recevoir au bout d'un certain temps. D'un point de vue opérateur, il voit arriver des paquet "DNS" malformés en masse en entrée sur un mobile 4G.
Êtes vous au fait d'un tel bridage chez Orange ? Il y a bien le port 25 qui est tout simplement bloqué alors pourquoi pas un truc du genre.
Si non, des idées pour trouver ce qu'il se passe dans mon cas ?
J'aurai bien fait un tcpdump sur le smartphone, mais il faut rooter etc... je suis pas très chaud :)
Je vous remercie d'avance
-
Hello, j'ai vu ça.
https://communaute.orange.fr/t5/Livebox/Redirection-port-53-sur-LB5/td-p/2295692
-
Petit détail que je n'ai pas mis, je n'utilise pas de livebox (remplacé par un routeur perso).
On peut éliminer un problème au niveau de ça déjà.
Le flux est en IPv6, donc pas de redirection de port ou truc comme ça, mais un flux udp 53 ouvert en direct vers le serveur (GUA).
-
Pour moi oui, il y a bien un bridage.
Chez SFR aussi d'ailleurs : là il n'y a carrément pas de trafic si tu envoie autre chose que du DNS ! Neutralité du net et blocage port 53 chez SFR (https://lafibre.info/4g-sfr/neutralite-du-net-et-blocage-port-53-chez-sfr/)
Il te reste la solution de l'IP over DNS, mais pareil c'est hyper lent... d'autant plus que tu rajoutes du chiffrement (SSH & cie)
-
Pour moi oui, il y a bien un bridage.
Chez SFR aussi d'ailleurs : là il n'y a carrément pas de trafic si tu envoie autre chose que du DNS ! Neutralité du net et blocage port 53 chez SFR (https://lafibre.info/4g-sfr/neutralite-du-net-et-blocage-port-53-chez-sfr/)
Il te reste la solution de l'IP over DNS, mais pareil c'est hyper lent... d'autant plus que tu rajoutes du chiffrement (SSH & cie)
Effectivement, je viens de lire le sujet et ça ressemble fortement. Sauf qu'avec Orange on m'autorise quelques minutes/secondes avant de bloquer :P
Après le port 53, c'est surement pour éviter du DDOS, mais bon dommage c'était une bonne porte de sortie.
Je serais intéressé d'avoir l'avis de Vivien la dessus, savoir si quelque chose peut être fait côté opérateur, car clairement ça ne respecte pas le principe de neutralité.
Il manque vraiment le port 53 dans l'application Wehe.
-
Plutôt que côté FTTH, le problème a plus de chances de venir du côté 4G : même si en IPv6 ce n'est pas un CGNAT comme en IPv4, il y a quand même une gestion des "connexions" pour savoir quels flux entrants autoriser.
Est-ce que le trafic est régulier ? Peut-être que sans keepalive le timeout est plus court sur le port 53 que sur d'autres ports.
J'aurai bien fait un tcpdump sur le smartphone, mais il faut rooter etc... je suis pas très chaud :)
Peut-être que le problème pourrait être reproduit avec un client Wireguard sur un PC connecté en 4G avec le partage de connexion du smartphone (USB ou Wifi).
-
+1 pour le test en partage de connexion. Normalement ça devrait revenir au même.
C'est d'ailleurs ce qui a été fait sur le topic SFR.
Cette histoire m’intrigue, je crois que je vais essayer de mon côté vu que j'ai déjà un serveur WG. En plus j'ai aussi du bouygues, on va pouvoir comparer.
-
Plutôt que côté FTTH, le problème a plus de chances de venir du côté 4G : même si en IPv6 ce n'est pas un CGNAT comme en IPv4, il y a quand même une gestion des "connexions" pour savoir quels flux entrants autoriser.
Est-ce que le trafic est régulier ? Peut-être que sans keepalive le timeout est plus court sur le port 53 que sur d'autres ports.
Peut-être que le problème pourrait être reproduit avec un client Wireguard sur un PC connecté en 4G avec le partage de connexion du smartphone (USB ou Wifi).
Oui le problème est surement sur la connexion 4g.
Pour la régularité, j'affichais des pages web + video. J'ai pas spécialement trouvé un volume qui activait le blocage.
Quand j'aurai un peu de temps je testerai le partage de connexion pour faire un tcpdump.
-
https://www.wireguard.com/quickstart/ mentionne le keepalive dans "NAT and Firewall Traversal Persistence".
La configuration côté téléphone pourrait aider le firewall côté 4G à considérer la "connexion" toujours active.
Ca reste étrange que des paquets puissent circuler du téléphone vers le serveur sans permettre le flux dans le sens inverse.
-
Ca reste étrange que des paquets puissent circuler du téléphone vers le serveur sans permettre le flux dans le sens inverse.
Le flux retour est permit, mais ça dure pas plus de quelques minutes/secondes.
-
Le flux retour est permit, mais ça dure pas plus de quelques minutes/secondes.
Je parlais du moment où le problème arrive.
Si le firewall considère le flux comme terminé, et qu'il bloque la création d'un nouveau avec les mêmes ports pendant un certain temps, c'est étrange qu'il autorise les paquets sortants du téléphone.
-
Il manque vraiment le port 53 dans l'application Wehe.
On va travailler sur un nouvel outil pour tester la neutralité qui permettra de tester tous les ports. Plutôt sous forme de script pour Linux, Windows et Mac. Peut-être qu'il faudrait prévoir une app mobile, mais on n'a pas les compétences.
Là, il serait intéressant de savoir si le problème est lié au fixe ou au mobile.
Si tu prends un port autre que le port 53 et le port 80, cela fonctionne ?
-
On va travailler sur un nouvel outil pour tester la neutralité qui permettra de tester tous les ports. Plutôt sous forme de script pour Linux, Windows et Mac. Peut-être qu'il faudrait prévoir une app mobile, mais on n'a pas les compétences.
Là, il serait intéressant de savoir si le problème est lié au fixe ou au mobile.
Si tu prends un port autre que le port 53 et le port 80, cela fonctionne ?
Pas de problème sur le port udp 80.
J'ai pu faire le test en partage de connexion, et ça confirme bien ce que j'ai observé.
J'ai le client avec l'IP en f0ba et le serveur en 4693.
Sur la capture du routeur on voit les paquets reçu et envoyé vers mon peer : une requête du client obtient toujours au moins une réponse et parfois une retransmission du SYN ACK (cf pj).
Par contre sur le tcpdump du PC en partage de connexion, on voit uniquement les paquets envoyé :
13:30:37.756003 IP6 ****:****:****:****:****:****:****:f0ba.42474 > ****:****:****:****:****:****:****:4693.53: 1024 [33649a] [40207q] [256n] Type0 (Class 214)? . [|domain]
13:30:38.756136 IP6 ****:****:****:****:****:****:****:f0ba.42474 > ****:****:****:****:****:****:****:4693.53: 1024 [33649a] [40207q] [512n] Type0 (Class 65)? . Type54214 (Class 50092)? <BAD PTR> [|domain]
13:30:40.772257 IP6 ****:****:****:****:****:****:****:f0ba.42474 > ****:****:****:****:****:****:****:4693.53: 1024 [33649a] [40207q] [768n] Type0 (Class 223)? . [|domain]
13:30:44.804231 IP6 ****:****:****:****:****:****:****:f0ba.42474 > ****:****:****:****:****:****:****:4693.53: 1024 [33649a] [40207q] [1024n] Type0 (Class 202)? . Type38578 (Class 6368)? M-^DM-^O7M-2HM/^R3-KM-!M-upM-E]M-iM-cWvM-VlM-;M-CM-_HM-bM-I$M-H5XM-^FM-djM-,M-IM-<5M-~M-6]M-*M-WM-^MzM-JM-^TM-]hM-fyaM-^PM-ez^N.^Vh^K3M-^\^\M-;M-aM-J^XM-kM-IuJM-^^M-`M-a,M-$5SM-R^(.<BAD PTR> [|domain]
^C
7 packets captured
7 packets received by filter
0 packets dropped by kernel
Ça semble indiquer que les paquets udp 53 entrant sur le réseau mobile sont bloqué.
Je n'ai pas encore eu la possibilité d'effectuer le test avec un client ailleurs que sur un réseau 4G pour vérifier ça. Je suppose que de client Orange fixe vers Orange fixe il doit pas y avoir de problème.
Les ports 80/81520 udp ne posent aucun problème.
-
Taking a wild guess.
Vu qu'on a un firewall à état (connection tracking) pour empêcher le traffic non sollicité dans le sens internet -> mobile, il faut garder en mémoire la liste des flux établis par chaque mobile quelque part (en RAM sur l'équipement qui fait le connection tracking, normalement). On ajoute ùne entrée dans la liste lors de l'établissement de la connexion et on la retire lorsque la connexion est fermée.
Autant en TCP il est facile de savoir quand une connexion est fermée (on attend de voir passer un échange FIN/FIN-ACK), autant en UDP, on a pas de marqueur de fin de connexion (UDP n'a pas de notion de connexion, d'ailleurs).
On utilise donc un timer qui est réarmé à chaque paquet UDP traversant le firewall. Lorsque le timer expire, le flux est considéré comme fermé et on retire l'entrée de la liste.
DNS est un protocole qui utilise UDP pour la majorité de ses requêtes, avec un port source aléatoire par requête côté client, et le port 53 côté serveur. Comme on peut facilement avoir une centaine de requête DNS par page Web (ca peut aller très vite... regardez le nombre de domaines contactés par www.lemonde.fr ou www.lequipe.fr sur un navigateur sans adblocker... avec une requête AAAA, une A et une HTTPS par domaine, je pense même qu'on est au dela de 100), on va avoir autant de flux de très courte durée vus par le firewall.
Je pense donc que pour éviter de faire exploser les tables de connection tracking, Orange traite les paquets UDP port 53 de façon un peu différente, par exemple avec un timer très court. Tant qu'il y a du traffic sur le VPN, pas de souci. Dès qu'il y a une période d'inactivité plus longue que le timer, le flux UDP utilisé par le VPN est marqué comme terminé et l'entrée correspondante est retirée de la liste : les paquets dans le sens internet -> mobile sont jetés par le firewall et tu constates une interruption de service.
Lorsque le mobile émet à nouveau des paquets pour ce flux, une nouvelle entrée est créée par le firewall (qui pense que c'est une nouvelle connexion) et le VPN apparaît à nouveau fonctionnel.
Ce n'est qu'une théorie, mais ca me semble plus être une réponse pragmatique qu'une atteinte à la neutralité :
- l'opérateur n'a pas le droit de regarder le contenu applicatif du paquet pour déterminer si c'est une requête DNS ou autre chose, il ne peut donc pas appliquer ce traitement spécifique uniquement aux requêtes DNS,
- les firewalls limitent probablement le nombre de flux ouverts par client pour éviter une saturation des tables de conntrack et une dégradation de service pour tous les clients,
- au vu de la fragilité relative des liens 2/3/4/5G actuels (ressource radio précieuse car spectre cher, autonomie batterie limitée, niveau de cybersécurité faible des mobiles, etc.), il est judicieux de faire du connection tracking dans le réseau mobile pour protéger les mobiles des attaques extérieures.
Je suppose que tu fais écouter ton serveur Wireguard sur 53/udp pour contourner des portails captifs. Ne pourrais-tu pas le faire écouter sur les deux ports (53 et 51820) et n'utiliser le port 53 que si tu es sur un tel réseau ?
-
Je ne suis pas trop d'accord avec toi.
Je pense donc que pour éviter de faire exploser les tables de connection tracking, Orange traite les paquets UDP port 53 de façon un peu différente, par exemple avec un timer très court. Tant qu'il y a du traffic sur le VPN, pas de souci. Dès qu'il y a une période d'inactivité plus longue que le timer, le flux UDP utilisé par le VPN est marqué comme terminé et l'entrée correspondante est retirée de la liste : les paquets dans le sens internet -> mobile sont jetés par le firewall et tu constates une interruption de service.
Le problème est le flux retour, pour chaque flux retour bloqué, il y a eu un flux aller quelques millisecondes plus tôt. Dans ce cas là, le timer en question aurait du être rafraichi et autoriser le flux retour. Par exemple, j'ai trouvé beaucoup de blocage après de simple SYN (et donc les SYN ACK bloqués).
- l'opérateur n'a pas le droit de regarder le contenu applicatif du paquet pour déterminer si c'est une requête DNS ou autre chose, il ne peut donc pas appliquer ce traitement spécifique uniquement aux requêtes DNS,
Je suis pas trop d'accord non plus. Pour mon vpn, le flux est bloqué en retour.
Par contre si je fais une boucle bash assez violente de ce style :
while true; do dig google.fr +trace; done;
En gros requêter à fond du DNS, jamais je n'ai de flux UDP retour bloqué sur un même port udp 53 (je vois pas Orange risquer ça d'ailleur, bloquer du DNS classique). Pour moi il y a forcement une inspection ou quelque chose de ce style que détecte que mes paquets ne sont pas du DNS pur et flag ça comme du malveillant.
- au vu de la fragilité relative des liens 2/3/4/5G actuels (ressource radio précieuse car spectre cher, autonomie batterie limitée, niveau de cybersécurité faible des mobiles, etc.), il est judicieux de faire du connection tracking dans le réseau mobile pour protéger les mobiles des attaques extérieures.
Connection tracking, je ne sais pas, mais des systèmes anti-ddos c'est fort probable.
Je suppose que tu fais écouter ton serveur Wireguard sur 53/udp pour contourner des portails captifs. Ne pourrais-tu pas le faire écouter sur les deux ports (53 et 51820) et n'utiliser le port 53 que si tu es sur un tel réseau ?
Oui c'est certainement ce que je vais faire, même si j'aurais eu envie d'éviter de faire du NAT (par exemple rediriger le port 51820 vers le 53 en interne). Surtout qu'on est sur de l'IPv6. Maintenant l'idée du post c'est plutôt de voir pourquoi il y a ce blocage/filtrage, si c'est vraiment acceptable ou non aux yeux du concept de neutralité que de débloquer ma situation (qui ne l'est pas vraiment, il y a des contournements).
-
On peut pas passer plusieurs options ListenPort à Wireguard pour éviter d'avoir à faire du DNAT ?
> while true; do dig google.fr +trace; done;
Si tu fais ca, dig devrait utiliser un port source différent à chaque invocation. Ce n'est pas le cas ? Sur mon laptop ceci dit, il tape dans systemd-resolved qui fait office de cache, donc ca ne génère pas des masses de traffic réseau, mais c'est un détail d'implémentation.
Pour le reste, tu as sans doute raison, j'ai probablement tort. C'était juste une tentative d'explication rationnelle.
> Maintenant l'idée du post c'est plutôt de voir pourquoi il y a ce blocage/filtrage, si c'est vraiment acceptable ou non aux yeux du concept de neutralité
La réponse m'intéresse en tout cas :) D'ailleurs, j'irai plus loin : si un opérateur a des filtres anti-IP spoofing (voeux pieux, mais j'espère qu'ils en ont tous!), est-ce une atteinte au concept de neutralité ?
Plus on-topic et de facon plus large, l'unidirectionnalité des connexions induite par la présence de ce connection tracking / stateful filtering bloque clairement des applications et restreint les usages. Même si c'est fait dans l'intérêt du grand public, le fait qu'on ne puisse pas le désactiver est-il acceptable également ?
-
Le problème est présent en IPv4 également (si possible avec le mobile configuré en APN IPv4 only) ?
Je souhaiterais savoir si c'est une régression IPv6)
-
Le problème est présent en IPv4 également (si possible avec le mobile configuré en APN IPv4 only) ?
Je souhaiterais savoir si c'est une régression IPv6)
J'ai restesté aujourd'hui, et le comportement est similaire avec un tunnel en IPv4.
-
A priori pas de blocage d'internet Fibre vers Fibre. Donc surement un protection sur le réseau mobile uniquement.
-
Bonjour Vivien,
Le problème est présent en IPv4 également (si possible avec le mobile configuré en APN IPv4 only) ?
Je souhaiterais savoir si c'est une régression IPv6)
C'est assez proche du souci que j'ai signalé ici (https://lafibre.info/arcep/est-ce-que-les-4-plus-gros-fai-respectent-la-loi-de-la-neutralite-du-net/msg983713/#msg983713) en Octobre dernier.
Je n'avais pas re testé depuis un moment, surprise mon vpn s'établit maintenant bien en udp 53 (ipv4) en 4G.
Il faudrait donc que je test plus avant pour voir si j'observe des déconnexions.
Bon Dimanche.
-
J'ai rafraichi mes confs aujourd'hui et j'ai voulu réessayer.
Un réseau wifi quelconque vers mon VPN (hébergé à la maison chez orange) hébergé sur le port 53: RAS.
Réseau 5G sosh vers mon VPN sur le port 53 : Fonctionne quelques secondes puis K.O.
Dès qu'on bascule en port 80, tout refonctionne par magie :)
Les paquets depuis le réseau 5G vers le fibre Orange sont toujours reçu, mais les paquets udp 53 vers le réseau 5G semblent filtré.
Je suppose que c'est une sorte de protection anti-dos ou autre.
J'imagine qu'on aura jamais le fin mot de l'histoire, sauf si une personne de chez Orange nous donne plus de détails.
En principe ça ne respecte pas le principe de neutralité.
Ca m'aurait permit de contourner quelques points d'accès un peu mal configuré que autorisent du udp 53 en ANY sur internet :)