Bonjour,
je voulais juste partager ce dont je viens de me rendre compte.
Il me semble qu'SFR mobile bloque le port 53, ce qui est à mon sens une attente à la neutralité du net.

Je m'explique. J'ai chez moi un serveur Wireguard, qui écoute habituellement en UDP sur le port 51820 (le port par défaut). Néanmoins, dans certains réseaux privés, d'entreprises, ou encore certains wifi publiques, seuls les ports standards sont autorisés, à savoir port TCP 80 (le port par défaut du HTTP), TCP 443 (le port par défaut HTTPS) et souvent le port UDP 53 (port par défaut de DNS).
J'utilise jusque là, un serveur OpenVPN maison, qui écoute en TCP 443, ce qui me permet de bypasser le firewall de ces réseaux bloqués.
Pour pouvoir utiliser Wireguard (plus rapide qu'OpenVPN), j'ai donc fait une redirection sur mon serveur du port UDP 53 vers le port UDP 51820. Ainsi je peux me connecter sur mon serveur Wireguard en UDP 53, qui n'est souvent pas bloqué sur ces réseaux limités/verrouillés, s'agissant du port DNS.

Néanmoins je me suis rendu compte que depuis mon téléphone mobile, avec un abonnement SFR (RED en réalité, mais c'est le même réseau), lorsque je suis connecté sur le réseau mobile, je ne peux pas me connecter au VPN Wireguard en UDP 53 (mais en UDP 51820 cela fonctionne bien).
Lorsque je suis sur un réseau fixe, par exemple le Wi-Fi chez des amis, la connexion au serveur VPN Wireguard en UDP 53 fonctionne correctement.

J'en conclu que SFR bloque l'utilisation du port 53 sur son réseau mobile.
L'application de test de neutralité Wehe que recommande l'ARCEP( https://lafibre.info/os-mobile/wehe/ ) ne permet pas de tester le port 53.

Est ce que quelqu'un a déjà eu ce problème ?

Si sur mon PC Windows, en partage de connexion depuis mon téléphone Android sur SFR je fais
>nslookup google.com 14.14.14.14
DNS request timed out.
    timeout was 2 seconds.
Serveur :   UnKnown
Address:  14.14.14.14


Je suis également client RED 30 Go (bientôt 40 Go) et je ne vois pas de blocage sur le port 53 chez SFR en TCP, que ce soit en IPv4 ou en IPv6 :



Serait-il possible de faire le même test que moi ?

wget -O /dev/null https://ipv4.paris.testdebit.info:53/10M.iso
wget -O /dev/null https://ipv6.paris.testdebit.info:53/10M.iso
J'ai fais ce test avec les deux APN proposés par SFR (sl2sfr et websfr) en IPv4 et en IPv6  sans rencontré de problème avec mon Samsung Galaxy S8.

En UDP, donc ?

En TCP, un wget fait bien une requête sortant sur le port 53.

APN sl2sfr:


APN websfr :


Ce test ne permet pas d'assurer que c'est bien le bon serveur qui répond, contrairement à mon test précédent en https sur le port 53.

Je veut bien un test simple pour montrer le problème et surtout l'APN et le protocole concerné (avec deux APN et 2 protocoles, cela fait 4 tests à faire à chaque fois, je veut bien cibler mieux ce qui pose problème).

Donc voici le début du test.
Ce test consiste, depuis mon téléphone Android (Mi Mix 2S avec une ROM Pixel Experience donc un Android globalement stock), sur le réseau mobile SFR uniquement, en 4G, à essayer de me connecter via l'application mobile Wireguard sur mon serveur Wireguard qui tourne sur mon routeur OpenWrt (qui bypass ma neufbox, mon routeur OpenWrt est directement sur le réseau SFR FTTH).
Mon serveur Wireguard tourne sur le port 51820 en UDP. Donc le port UDP 51820 est ouvert sur l'interface WAN. De plus j'ai mis en place une redirection du port entrant UDP 53 sur l'interface WAN vers l'interface LAN en UDP 51820 sur lequel le serveur Wireguard écoute. Cette redirection fonctionne puisque j'ai pu me connecter sur mon serveur Wireguard depuis le Wi-Fi chez des amis en mettant en paramètre de l'application Wireguard sur mon téléphone le port UDP 53.

1er tests avec l'APN sl2sfr (avec IPv4 et IPv6 mais seule l'adresse IPv4 de mon serveur est configurée dans l'application Wireguard)
J'ai volontairement masqué mes IP et adresses MAC.

Donc voici une capture Wireshark de l'interface WAN de mon routeur OpenWrt, avec un filtre pour n'afficher que le port UDP 51820 : on voit la connexion se faire sans soucis depuis mon téléphone en 4G configuré pour se connecter à l'adresse IP de mon serveur sur le port 51820 directement



Sur la 2ème capture : le filtre n'affiche que le port UDP 55 (nombre pris au hasard), qui n'est pas ouvert sur le pare-feu de mon routeur. Mon téléphone est ici configuré dans l'application Wireguard pour se connecter à l'adresse IP de mon serveur sur le port 55. On voit bien des packets arriver de mon téléphone sur mon routeur, qui les refuse.



3ème capture avec le filtre pour n'afficher que le port UDP 53, sur lequel il y a sur mon routeur la redirection UDP 53 depuis WAN -> UDP 51820 sur mon LAN. Mon téléphone est cette fois ci configuré dans l'application Wireguard pour se connecter sur l'IP de mon serveur sur le port 53. Cette fois ci on ne voit aucun packet arriver de mon téléphone

J'ai tenté de reproduire le problème en prenant moi aussi un trace à distance, sur le port 53, sur un serveur qui n'écoute pas sur ce port.

J'ai utilisé l'APN SL2SFR en IPv4.

Pour générer un trafic UDP sur le port 53, j'utilise dig pour faire une requête DNS.

Voici la trace coté serveur (il ne répond, pas, le serveur n’hébergeant pas de serveur DNS) :



Coté client : Ubuntu 20.10 connecté en WiFi sur mon Samsung S8 Andrdoid 9 en partage de connexion (j'ai modifié le profil pour que dun utilise SL2SFR)

Coté serveur : Ubuntu 20.04 LTS, capture réalisé avec TCPDUMP.

Tu as vérifié que ce n'était pas un autre élément de la chaîne qui bloque le trafic sur le port 53 ?
Le plus simple serait de mettre la SIM d'un autre opérateur dans ton smartphone, si un amis / conjoint à souscrit à un autre opérateur.