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 ?