RDS RD Web — Application « disconnecting » sous Windows Server 2012 R2 : diagnostic RDP, RD Gateway et résolution VPN

Incident RDS reproductible : RD Web s’ouvre et l’auth AD réussit, le fichier .rdp se télécharge, mais l’application ne démarre pas. Voici un retour d’expérience actionnable : analyse pas‑à‑pas, cause racine (règles VPN), correctif et bonnes pratiques pour éviter la récidive.

Sommaire

Contexte technique

Ferme Remote Desktop Services (RDS) sous Windows Server 2012 R2 avec les rôles : RD Connection Broker, RD Gateway, RD Web Access, RD Licensing, RD Session Host et une collection d’applications publiées (RemoteApp).
Exploitation stable pendant plusieurs années, aucun changement RDS récent identifié avant l’incident.

Symptômes observés

Accès au portail RD Web opérationnel (HTTPS 443) et authentification Active Directory réussie.
Au lancement d’une application publiée : le fichier .rdp est bien téléchargé, mais l’ouverture échoue côté client avec un message générique (« Impossible d’établir la connexion », erreur RD Gateway , etc.).
Aucun événement significatif dans les journaux Windows des serveurs, services RDS actifs, pare‑feu inchangés, redémarrages inopérants, aucune mise à jour serveur récente.

Ce que ces indices racontent

Le portail RD Web fonctionne : cela valide DNS, TLS et l’authentification AD sur 443/TCP jusqu’au serveur RD Web. L’échec survient après le téléchargement du .rdp, c’est‑à-dire lors de l’établissement du canal RDP via RD Gateway (flux 443/TCP et/ou 3391/UDP) et du courtier (Broker) vers un Session Host (3389/TCP en interne). Le signal faible typique : l’appli ne se lance pas alors que le portail s’ouvre correctement → suspectez un blocage RDP/RD Gateway sur le trajet réseau (nouvelle politique VPN, inspection applicative, MTU, latence/packet loss, etc.).

Flux RDS et points de rupture fréquents

Étape	Composants	Ports/Protocoles	Symptômes en cas d’échec	Journaux à examiner
Portail	Client ↔ RD Web (IIS)	TCP 443	Portail inaccessible / erreur TLS	IIS `%SystemDrive%\inetpub\logs\LogFiles`
Téléchargement `.rdp`	RD Web	TCP 443	`.rdp` absent ou corrompu (rare)	IIS, RDWeb (Applications and Services Logs)
Ouverture du `.rdp`	Client ↔ RD Gateway	TCP 443, UDP 3391 (transport RDG-UDP)	Échec immédiat ou après quelques secondes	Event Viewer → TerminalServices-Gateway/Operational et TerminalServices-ClientActiveXCore (poste)
Négociation/Broker	RD Gateway ↔ Broker ↔ Session Host	Interne : TCP 3389 (RDP)	Boucle de connexion, redirections échouées	SessionBroker/Operational, RemoteConnectionManager, LocalSessionManager
Session	Client ↔ Session Host (via Gateway)	TCP 443 (± UDP 3391)	Coupures, lenteurs, audio/USB non dispo	TS-Gateway/Operational, logs NPS/VPN

Investigations et pistes proposées

Axe	Vérifications conseillées
Réseau	Continuité IP, test de ports (TCP 443, 3389, 3391/UDP), latence/packet loss, MTU (`ping -f -l`), effet du VPN (split/full tunnel).
Certificats	Validité CN/SAN (FQDN du RD Gateway), chaîne de confiance, renouvellement ou remplacements récents, bindings IIS/RD Gateway.
État des services RDS	Santé et redémarrage ciblé des rôles (Broker, Gateway, Web, Session Host), dépendances IIS/NPS.
Ressources système	CPU, RAM, disque, files d’attente IIS/HTTP.SYS, saturation réseau/VM.
Client	Reproduire depuis d’autres postes/segments, versions du client RDP, antivirus/EDR, proxy/SSL inspect.

Procédure de diagnostic reproductible

Vérifier l’intégrité du fichier `.rdp`

Ouvrez le .rdp avec un éditeur texte et contrôlez les champs clés :

full address:s:&lt;broker ou nom de collection&gt;
use redirection server name:i:1
gatewayhostname:s:rdgw.exemple.com
gatewayusagemethod:i:2   ; 0=Jamais, 1=Auto, 2=Toujours via RD Gateway
gatewaycredentialssource:i:0
remoteapplicationmode:i:1
remoteapplicationprogram:s:||NomDeLAppli
enablecredsspsupport:i:1

gatewayhostname doit correspondre au FQDN figurant dans le certificat du RD Gateway.
Si gatewayusagemethod = 2, le client utilisera toujours la passerelle : vérifiez 443/TCP (et idéalement 3391/UDP).

Tester la connectivité depuis le poste client

# Test des ports critiques
Test-NetConnection rdgw.exemple.com -Port 443 -InformationLevel Detailed
Test-NetConnection rdgw.exemple.com -Port 3391 -InformationLevel Detailed  # UDP testé via -UdpPort sur Win10+ si dispo
# Test vers le Broker et un Session Host (depuis un réseau interne ou bastion)
Test-NetConnection rdbroker.exemple.local -Port 3389
Test-NetConnection rdsh01.exemple.local -Port 3389

# Vérifier le MTU si VPN/fragmentation soupçonnés

ping rdgw.exemple.com -f -l 1472   # réduire jusqu'à succès (ex. 1340, 1200)

Astuce : si l’UDP 3391 est bloqué, RDP retombe en TCP 443. Un blocage applicatif RDP au niveau du VPN/pare‑feu peut néanmoins couper la session au lancement, même si 443 est ouvert.

Contrôles rapides côté serveurs

# État des services clés
Get-Service Tssdis, TermService, W3SVC, TSGateway | Select Name, Status

# Sessions et hôte

qwinsta /server:rdsh01
quser /server:rdsh01

# Journaux utiles (extraits)

wevtutil qe "Microsoft-Windows-TerminalServices-Gateway/Operational" /c:20 /rd:true /f:text
wevtutil qe "Microsoft-Windows-TerminalServices-SessionBroker/Operational" /c:20 /rd:true /f:text
wevtutil qe "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" /c:20 /rd:true /f:text

# Pare-feu Windows (extraits de règles)

netsh advfirewall firewall show rule name=all | findstr /i "3389 3391 443" </code></pre>

<h3>Trace r&eacute;seau minimale si besoin</h3>
<pre><code>netsh trace start capture=yes scenario=netconnection persistent=no report=no
# Reproduire l'échec pendant 15-30 s, puis :
netsh trace stop
# Ouvrir le .ETL avec Message Analyzer/Wireshark sur un poste d'analyse
</code></pre>

<h3>Comparer avec et sans VPN</h3>
<p>Si la politique VPN est <strong>full tunnel</strong> ou applique une <strong>inspection applicative</strong>, comparez&nbsp;:</p>
<ul>
  <li><em>Poste &rarr; RD Web</em> (443) <strong>OK</strong></li>
  <li><em>Poste &rarr; RD Gateway</em> (443 et 3391) <strong>OK en apparence</strong></li>
  <li>Mais &agrave; l’ouverture de l’appli, le VPN <strong>bloque le flux RDP encapsul&eacute;</strong> (<em>App‑ID RDP</em> ou r&egrave;gle interdisant 3389/3391), provoquant la d&eacute;connexion imm&eacute;diate.</li>
</ul>

<h2>Cause racine identifiée</h2>
<p>Une <strong>modification de la nouvelle solution VPN</strong> a bloqué le trafic <strong>RDP</strong> lorsque la session applicative se lançait&nbsp;: inspection applicative et/ou politique interdisant RDP (3389/3391) en sortie. Bien que le portail RD Web (443) et le téléchargement du <code>.rdp</code> fonctionnent, l’ouverture du canal RDP via la passerelle était coupée par la politique VPN. Après ajustement des règles, les connexions ont <strong>repris immédiatement</strong>.</p>

<h2>Correctif appliqué</h2>
<ul>
  <li>Mise à jour de la configuration <strong>VPN</strong> pour <strong>autoriser le flux RD Gateway/RDP</strong> vers la ferme (au minimum&nbsp;: <em>TCP&nbsp;443</em> vers le <em>RD Gateway</em>, <em>UDP&nbsp;3391</em> si l’on souhaite le transport UDP, et ne pas bloquer le protocole RDP au niveau de l’inspection applicative).</li>
  <li>Aucune autre action c&ocirc;t&eacute; serveurs RDS requise&nbsp;: pas de changement sur Broker, RD Web ou Session&nbsp;Host.</li>
</ul>

<h2>Mesures préventives et bonnes pratiques</h2>
<ol>
  <li><strong>Gestion des changements</strong>&nbsp;: synchroniser toute &eacute;volution r&eacute;seau (VPN, pare‑feu, reverse‑proxy, inspection TLS) avec l’&eacute;quipe RDS pour &eacute;viter les ruptures de service.</li>
  <li><strong>Supervision r&eacute;seau</strong>&nbsp;: mettre en place des sondes externes testant <em>443/TCP</em>, <em>3391/UDP</em> et des ouvertures de <code>.rdp</code> (smoke tests) hors VPN et via VPN.</li>
  <li><strong>Alertes certificat</strong>&nbsp;: notifier l’expiration des certificats RD Gateway/Broker, contr&ocirc;ler les <em>bindings</em> IIS apr&egrave;s renouvellement.</li>
  <li><strong>Journalisation centrale</strong>&nbsp;: agr&eacute;ger <em>TS-Gateway</em>, <em>SessionBroker</em>, <em>RemoteConnectionManager</em>, <em>LocalSessionManager</em>, <em>IIS</em> et <em>NPS/VPN</em> dans un SIEM pour corr&eacute;lation rapide.</li>
  <li><strong>Tests de reprise</strong>&nbsp;: documenter et tester p&eacute;riodiquement le chemin complet (RD Web &rarr; <code>.rdp</code> &rarr; RD Gateway &rarr; Session&nbsp;Host).</li>
</ol>

<h2>Checklist opérationnelle «&nbsp;RD Web ok, appli qui ne s’ouvre pas&nbsp;»</h2>
<ul>
  <li>✅ <strong>DNS/TLS</strong> RD Web <em>OK</em> (443)&nbsp;?</li>
  <li>✅ <strong>Fichier <code>.rdp</code></strong>&nbsp;: <code>gatewayhostname</code> cohérent avec le certificat RD Gateway&nbsp;?</li>
  <li>✅ <strong>Ports</strong> depuis le poste&nbsp;: <code>tnc rdgw -p 443</code> et <code>3391</code> satisfaisants&nbsp;?</li>
  <li>✅ <strong>VPN</strong>&nbsp;: split/full tunnel&nbsp;? Règles App‑ID RDP&nbsp;?</li>
  <li>✅ <strong>Logs</strong> côté Gateway/Broker/Session Host (erreurs corrélées à l’heure du test)&nbsp;?</li>
  <li>✅ <strong>Ressources</strong> serveurs (<em>CPU/RAM</em>), files d’attente IIS&nbsp;?</li>
  <li>✅ Essai <strong>depuis un autre poste/réseau</strong> pour isoler le facteur client.</li>
</ul>

<h2>Matrice des ports indispensables</h2>
<table>
  <thead>
    <tr>
      <th>Source &rarr; Destination</th>
      <th>Port/Proto</th>
      <th>Rôle</th>
      <th>Remarques</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Client Internet &rarr; RD Web</td>
      <td>TCP&nbsp;443</td>
      <td>Portail</td>
      <td>IIS, authentification ADFS/LDAP proxifiée si applicable</td>
    </tr>
    <tr>
      <td>Client Internet &rarr; RD Gateway</td>
      <td>TCP&nbsp;443</td>
      <td>Transport RDP/TLS</td>
      <td>Obligatoire&nbsp;; inspection TLS à éviter</td>
    </tr>
    <tr>
      <td>Client Internet &rarr; RD Gateway</td>
      <td>UDP&nbsp;3391</td>
      <td>Transport RDP/UDP</td>
      <td>Optionnel mais améliore latence; si bloqué, fallback TCP</td>
    </tr>
    <tr>
      <td>RD Gateway &rarr; Session Host</td>
      <td>TCP&nbsp;3389</td>
      <td>Canal RDP interne</td>
      <td>Doit être autorisé entre segments serveurs</td>
    </tr>
    <tr>
      <td>Broker &harr; Session Host</td>
      <td>TCP&nbsp;3389</td>
      <td>Redirection et suivi des sessions</td>
      <td>Plus autres dépendances internes propres à l’environnement</td>
    </tr>
  </tbody>
</table>

<h2>Signatures d’erreurs côté client</h2>
<ul>
  <li><em>&laquo;&nbsp;Votre ordinateur ne peut pas se connecter au serveur de passerelle des services Bureau &agrave; distance&nbsp;&raquo;</em>&nbsp;: certificat/bindings ou politique VPN.</li>
  <li><em>&laquo;&nbsp;La connexion &agrave; l’ordinateur distant a &eacute;t&eacute; interrompue&nbsp;&raquo;</em> imm&eacute;diatement apr&egrave;s double‑clic&nbsp;: inspection applicative ou blocage UDP&nbsp;3391/TCP&nbsp;443 sur RD Gateway.</li>
  <li><em>&laquo;&nbsp;Le bureau &agrave; distance ne peut pas &ecirc;tre d&eacute;marr&eacute;&nbsp;&raquo;</em>&nbsp;: v&eacute;rifier Broker/collection, ou h&ocirc;tes satur&eacute;s.</li>
</ul>

<h2>Journalisation utile (emplacements)</h2>
<table>
  <thead>
    <tr>
      <th>Rôle</th>
      <th>Source de logs</th>
      <th>Ce qu’on cherche</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>RD Gateway</td>
      <td>Event Viewer &rarr; <em>Microsoft-Windows-TerminalServices-Gateway/Operational</em></td>
      <td>Échecs d’auth, erreurs de canal, refus de politique</td>
    </tr>
    <tr>
      <td>RD Web</td>
      <td>IIS&nbsp;: <code>%SystemDrive%\inetpub\logs\LogFiles</code></td>
      <td>Codes HTTP anormaux, lenteurs</td>
    </tr>
    <tr>
      <td>Broker</td>
      <td><em>TerminalServices-SessionBroker/Operational</em></td>
      <td>Échecs de redirection/affinité de session</td>
    </tr>
    <tr>
      <td>Session Host</td>
      <td><em>RemoteConnectionManager</em>, <em>LocalSessionManager</em></td>
      <td>Refus de connexion, surcharge, NLA</td>
    </tr>
    <tr>
      <td>Client</td>
      <td><em>TerminalServices-ClientActiveXCore/Operational</em></td>
      <td>Codes d’erreur RDP exacts et horodatage pour corrélation</td>
    </tr>
    <tr>
      <td>NPS/VPN</td>
      <td>Serveur VPN/pare‑feu</td>
      <td>Règle App‑ID/ACL ayant bloqué le flux RDP</td>
    </tr>
  </tbody>
</table>

<h2>Contournements temporaires (à n’utiliser qu’en test)</h2>
<ul>
  <li><strong>Désactiver l’UDP RDP</strong> sur le poste (pour valider un souci 3391/UDP)&nbsp;:
    <pre><code>reg add "HKCU\Software\Microsoft\Terminal Server Client" /v DisableUDP /t REG_DWORD /d 1 /f

Exclure provisoirement l’inspection TLS pour le FQDN du RD Gateway dans le proxy SSL, si présent.
Tester en split‑tunnel pour confirmer l’hypothèse VPN full‑tunnel bloquant RDP.

Script d’auto‑vérification (exemple PowerShell)

Exécutez‑le depuis un point d’entrée Internet (ou via VPN) pour un smoke test :

$targets = @(
  @{ Name = "RD Web 443"; Host="rdweb.exemple.com"; Port=443; Proto="TCP" },
  @{ Name = "RD Gateway 443"; Host="rdgw.exemple.com"; Port=443; Proto="TCP" },
  @{ Name = "RD Gateway 3391"; Host="rdgw.exemple.com"; Port=3391; Proto="UDP" }
)

foreach ($t in $targets) {
if ($t.Proto -eq "TCP") {
$r = Test-NetConnection -ComputerName $t.Host -Port $t.Port -InformationLevel Detailed
"{0,-18} {1} {2}:{3} => {4}" -f $t.Name,$t.Proto,$t.Host,$t.Port,($r.TcpTestSucceeded)
} else {
try {
$udpClient = New-Object System.Net.Sockets.UdpClient
$udpClient.Client.ReceiveTimeout = 2000
$udpClient.Connect($t.Host, $t.Port)
$bytes = [Text.Encoding]::ASCII.GetBytes("ping")
[void]$udpClient.Send($bytes, $bytes.Length)
"RD Gateway 3391 UDP => paquet émis (réception non garantie)"
$udpClient.Close()
} catch { "RD Gateway 3391 UDP => échec d’émission: $_" }
}
}

Pièges courants à éviter

Certificat RD Gateway non aligné (CN/SAN diffère du FQDN gatewayhostname) → avertissements TLS/échec.
Inspection TLS/Proxy réécrivant le trafic 443 → handshake RDP encapsulé perturbé.
Politique VPN App‑ID interdisant RDP, y compris encapsulé, → déconnexion au lancement.
Blocage 3391/UDP sans fallback correct → performance dégradée voire échec sur certains clients.
DNS split‑horizon incohérent → le client résout un FQDN interne non joignable depuis l’extérieur.

Rétro‑analyse de l’incident

Chronologie : l’infrastructure RDS est stable, aucun patch ni changement serveur. Un nouveau profil VPN est déployé. À partir de cette date, les utilisateurs peuvent toujours se connecter au portail RD Web, mais toutes les ouvertures d’applications échouent. Le Rollback de la règle VPN ou son ajustement immédiat restaure la connectivité, confirmant la causalité.

Recommandations finales

Documentation d’architecture : schéma des flux RDS (Client → RD Web → RD Gateway → Session Host) avec ports ouverts et responsabilités.
Change management : geler les modifications VPN/pare‑feu pendant les pics d’activité, et planifier un créneau de tests avec l’équipe RDS.
Supervision de bout en bout : un robot qui ouvre réellement une appli RemoteApp est plus fiable qu’un simple ping/443.
Capteurs d’expérience utilisateur : collecter les erreurs exactes du client RDP (via journaux Windows) pour accélérer la corrélation.

Conclusion

Dans ce cas, l’échec après téléchargement du .rdp pointait vers la couche transport RDP/RD Gateway. La cause racine était une politique VPN nouvelle bloquant le protocole RDP au moment de l’ouverture de session applicative. La correction a simplement consisté à autoriser les flux RDP (TCP 443 via RD Gateway et, selon le besoin, UDP 3391) sans inspection intrusive. En appliquant les mesures préventives proposées (change coordonné, supervision des ports, alertes certificat, SIEM, tests périodiques), on réduit drastiquement le risque de coupure inattendue et on accélère le diagnostic lors d’un prochain incident.

Annexe : commandes utiles (mémo)

# Tester un hôte RD Gateway depuis Internet
tnc rdgw.exemple.com -Port 443 -InformationLevel Detailed

# Forcer RDP en TCP uniquement (test client)

reg add "HKCU\Software\Microsoft\Terminal Server Client" /v DisableUDP /t REG_DWORD /d 1 /f

# Lister les RemoteApp publiées (sur le serveur de gestion)

Get-RDRemoteApp -CollectionName "NomDeLaCollection"

# Sur un Session Host, voir les sessions et processus par utilisateur

quser /server:rdsh01
tasklist /v /fi "SESSIONNAME eq rdp-tcp#"

# Journaux Gateway récents

wevtutil qe "Microsoft-Windows-TerminalServices-Gateway/Operational" /c:50 /rd:true /f:text

# IIS - dernières lignes (RD Web)

Get-Content -Tail 100 "C:\inetpub\logs\LogFiles\W3SVC1\u_ex*.log"

Annexe : plan d’escalade express

Contexte : portail OK, .rdp OK, l’appli ne démarre pas.
Isoler VPN : reproduction sans VPN ou en split‑tunnel.
Tester 443/3391 vers RD Gateway, puis 3389 interne depuis un bastion.
Corréler les logs RD Gateway & NPS/VPN au même timestamp.
Décision : si blocage VPN confirmé, ajuster règles (autoriser RDG/RDP) et vérifier que l’inspection applicative n’intervient pas sur le flux RDG.

RDS RD Web — Application « disconnecting » sous Windows Server 2012 R2 : diagnostic RDP, RD Gateway et résolution VPN