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

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

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 
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 on viole la neutralité encore une fois.

Il manque vraiment le port 53 dans l'application Wehe.

+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.

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.

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.