Collectivité territoriale — Troubleshooting WAF & accès distants

Le contexte

Notre client est une collectivité territoriale qui met à disposition de ses agents un accès distant à leurs applications internes via Microsoft RD Gateway (Remote Desktop Gateway). Cet accès permet aux agents en télétravail ou en déplacement de se connecter à leur environnement de bureau à distance, à travers un navigateur ou le client RDP natif de Windows.

L'architecture de sécurité repose sur une solution WAF/WAAP positionnée en frontal, qui inspecte et filtre le trafic entrant avant de le relayer vers les serveurs internes. C'est une bonne pratique : le WAF protège les applications exposées sur Internet contre les attaques web classiques (injections, XSS, requêtes malformées, etc.).

Le problème : depuis la mise en place de cette architecture, les utilisateurs distants rencontraient des erreurs 502 (Bad Gateway) de manière systématique lorsqu'ils tentaient de se connecter via le RD Gateway. Les sessions ne s'établissaient pas, rendant l'accès distant totalement inopérant.

Le diagnostic

Ce que les équipes avaient déjà vérifié

Avant notre intervention, l'équipe IT de la collectivité avait déjà réalisé un certain nombre de vérifications :

• Le serveur RD Gateway était fonctionnel et accessible en direct (sans passer par le WAF)
• Les certificats SSL étaient valides et correctement configurés
• Les règles de reverse proxy du WAF semblaient correctement définies
• Aucune règle de sécurité du WAF ne bloquait explicitement le trafic

Tout semblait en ordre, et pourtant le 502 persistait. C'est à ce stade que nous sommes intervenus.

Notre analyse

On a commencé par analyser le flux réseau de bout en bout pour comprendre à quel moment précis la connexion échouait. Le RD Gateway utilise un mécanisme en deux temps :

1. Phase initiale en HTTPS — le client établit une connexion HTTPS classique vers le Gateway pour l'authentification et la négociation de la session.
2. Upgrade en WebSocket — une fois authentifié, le client demande un upgrade de la connexion HTTP vers le protocole WebSocket (via l'en-tête Upgrade: websocket). C'est par ce canal WebSocket que transite ensuite le flux RDP encapsulé.

C'est précisément à la phase 2 que le problème se produisait.

La cause racine

Le WAF/WAAP était configuré pour relayer le trafic vers le RD Gateway en utilisant son module de reverse proxy HTTP standard. Ce module sait parfaitement gérer les requêtes HTTP/HTTPS classiques : il reçoit la requête du client, l'inspecte, et la transmet au serveur backend.

Mais quand le client RDP demandait l'upgrade en WebSocket, le reverse proxy HTTP ne savait pas gérer cette transition. Concrètement :

• Le client envoyait une requête HTTP avec l'en-tête Upgrade: websocket et Connection: Upgrade
• Le module de proxy HTTP du WAF ne comprenait pas cette demande d'upgrade
• Il tentait de relayer la requête comme du HTTP classique vers le backend
• Le backend RD Gateway répondait en conséquence, mais le proxy n'arrivait pas à maintenir la connexion bidirectionnelle
• Résultat : erreur 502 Bad Gateway — le proxy ne pouvait pas établir de connexion valide avec le backend

En résumé : le trafic passait par le mauvais module de proxy. Il fallait utiliser le module dédié au WebSocket au lieu du module HTTP standard.

La préconisation

La correction consistait à reconfigurer la règle de reverse proxy du WAF pour que le trafic à destination du RD Gateway soit traité par le module de proxy WebSocket plutôt que par le module de proxy HTTP standard.

Concrètement, au lieu de faire transiter l'intégralité du flux via le handler HTTP classique, la règle devait :

1. Détecter la demande d'upgrade WebSocket dans les en-têtes HTTP
2. Basculer le flux vers le module de proxy dédié WebSocket qui sait maintenir la connexion bidirectionnelle persistante
3. Conserver le proxy HTTP standard pour la phase initiale d'authentification HTTPS

Avant / Après

Les livrables

• Rapport d'analyse — description détaillée du flux réseau, identification de la cause racine avec captures protocolaires à l'appui.
• Préconisation de correction — procédure pas à pas pour reconfigurer la règle de reverse proxy du WAF, avec les paramètres spécifiques au module WebSocket.
• Documentation d'architecture — schéma mis à jour du flux applicatif RD Gateway à travers le WAF, distinguant les phases HTTP et WebSocket.

Ce qu'on retient de cette mission

Ce cas illustre un problème classique mais sous-estimé dans les architectures de sécurité applicative : la majorité des WAF/WAAP gèrent très bien le trafic HTTP/HTTPS, mais le support des protocoles basés sur WebSocket nécessite une configuration spécifique qui n'est pas toujours activée par défaut — ni même documentée clairement par les éditeurs.

Le RD Gateway n'est pas le seul service concerné : toute application utilisant WebSocket (visioconférence, outils collaboratifs temps réel, applications métier modernes) peut rencontrer le même problème derrière un reverse proxy ou un WAF mal configuré.

L'autre enseignement : un diagnostic protocolaire rigoureux, couche par couche, permet souvent de résoudre en quelques heures un problème sur lequel les équipes butent depuis des semaines. Ici, l'infrastructure fonctionnait, la configuration semblait correcte, les certificats étaient valides. Seule l'analyse fine du flux au moment de l'upgrade WebSocket a permis d'identifier la cause racine.