Vos sessions RDP depuis macOS vers Windows Server 2022 se coupent toutes les 3–10 minutes avec des reconnexions/MFA à répétition ? Voici un guide complet, basé sur un cas réel, pour diagnostiquer et corriger la cause — du test le plus rapide aux réglages avancés (UDP/TCP, MTU, redirections, VPN).
Coupures RDP macOS → Windows Server 2022 (reconnexions/MFA en boucle)
Vue d’ensemble
Des utilisateurs macOS constataient la déconnexion silencieuse de sessions RDP ouvertes sur des serveurs Windows Server 2022, toutes les 3–10 minutes, suivies d’une tentative de reconnexion et d’une nouvelle demande MFA (DUO). Les logs côté client mentionnaient notamment Client connMonitor goto CMSTATE_DROPPED et des erreurs de canaux dynamiques du type SendDevicesPacket failed. Aucun événement probant n’apparaissait côté serveur. À noter : aucun incident sur des serveurs Windows Server 2019 dans le même environnement.
Résumé exécutif
- Cause avérée (résolution finale) : pertes de paquets dues à un câble réseau défectueux. Le simple remplacement du câble a supprimé les déconnexions et les relances MFA.
- Approche : isoler d’abord la couche réseau/transport (tests localhost, ping, MTU, câbles/ports/compteurs), puis, si besoin, forcer le transport TCP‑only, mettre à jour le client RDP macOS et alléger la charge graphique/redirections.
Pourquoi ces symptômes ?
RDP moderne (RDP 8+) utilise un mode hybride : TCP 3389 et, lorsqu’il est disponible, RDP‑UDP 3389 pour améliorer latence et fluidité (input/graphique). Or, l’UDP est très sensible aux pertes, au MTU mal calibré et aux minuteries de pare-feu/NAT. Une micro‑coupure (câble, port de switch, EEE, Wi‑Fi, VPN, MTU trop élevé) suffit à rompre le flux UDP et déclencher une reconnexion : côté utilisateur, cela ressemble à « rien ne se passe » puis un retour à l’écran avec MFA. Les erreurs de canaux dynamiques (redirection lecteurs/périphériques) sont fréquentes lorsque la couche transport est instable : ces canaux sont multiplexés dans la session RDP et échouent dès que le transport lâche.
| Symptôme | Indice dans les journaux | Interprétation la plus probable |
|---|---|---|
| Coupure toutes les 3–10 minutes | CMSTATE_DROPPED côté macOS | Perte de paquets/MTU incorrect/NAT/UDP cassé |
| MFA (DUO) ré‑affiché | Multiples authentifications proches dans le temps | Reconnexion de session après micro‑coupure |
| Erreurs « dynamic channels » | SendDevicesPacket failed | Transport instable, redirections perturbées |
| OK sur Server 2019, KO sur 2022 | — | Suspect réseau/transport (UDP) + différences de pile/profils |
Plan d’action en 15 minutes
- Test local : sur le serveur concerné, lancer RDP vers
localhost. Si la session reste stable pendant 15–30 min, le service RDP n’est pas en cause : concentrez‑vous sur le réseau/transport. - Ping continu + jitter : depuis un poste voisin (ou le Mac), lancer un ping soutenu vers l’IP du serveur et relever pertes/variabilité.
- MTU & fragmentation : depuis le serveur Windows (ou un poste Windows), tester la fragmentation avec DF :
ping -f -l 1472 <IP_destination> ping -f -l 1464 <IP_destination> # diminuer jusqu’à disparition de la fragmentationAjuster la MTU de l’interface si nécessaire (environ 1400 avec certains VPN SSL/IPsec). - Couche 1/2 : remplacer le câble, changer de port de switch, vérifier les compteurs d’erreurs (CRC, discards) côté NIC et switch.
- Mitigation immédiate : forcer RDP en TCP‑only (voir plus bas). Souvent suffisant pour contourner les pertes UDP/NAT.
Diagnostic détaillé
1. Confirmer que le problème est bien réseau
- Session locale (sur le serveur cible) :
mstsc /v:localhostSi stable localement : suspectez le chemin réseau (lien, switch, routeur, pare‑feu, VPN, MTU). - Test de port RDP (depuis un poste Windows) :
Test-NetConnection <serveur> -Port 3389 - Perfs & erreurs réseau (Windows) :
Get-NetAdapterStatistics | ft Name,ReceivedErrors,OutboundErrors,InDiscards,OutDiscards - Perfs & erreurs réseau (macOS) :
netstat -ib | awk 'NR==1 || /en0/' # remplacer en0 par l’interface active sudo tcpdump -i <if> udp port 3389 # vérifier pertes/pauses du flux RDP-UDP
2. Vérifier le MTU (spécial VPN)
Un MTU trop élevé entraîne une fragmentation ou des pertes silencieuses (DF). Sur Windows, utilisez ping -f -l pour trouver la plus grande charge utile non fragmentée, puis soustrayez l’en‑tête pour déterminer la MTU optimale.
| Environnement | MTU souvent observée | Remarques |
|---|---|---|
| LAN filaire | 1500 | Valeur par défaut Ethernet |
| VPN SSL/SSL split‑tunnel | 1350–1450 | Ajuster selon le fournisseur VPN |
| IPsec (ESP) | 1400–1420 | Sur‑coût d’en‑tête IPsec |
| WireGuard | 1280–1420 | Dépend du chemin Internet |
Ajuster la MTU (Windows) :
netsh interface ipv4 show subinterfaces
netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent
# Vérifier
Get-NetIPInterface | ft ifIndex,InterfaceAlias,NlMtu3. Inspecter la couche physique & la couche 2
- Remplacer le câble suspect (catégorie adaptée, blindage correct) — c’est ici que le cas réel a été résolu.
- Changer de port de switch (ou de switch) et vérifier la négociation speed/duplex.
- Compteurs d’erreurs NIC/switch : CRC, alignment errors, late collisions, in/out discards.
- Énergie & offload : désactiver à titre de test « Energy Efficient Ethernet (EEE) », LSO/Checksum Offload si vous suspectez un driver/NIC capricieux.
4. Examiner les canaux dynamiques (redirections)
Les erreurs « SendDevicesPacket failed » renvoient souvent à la redirection de périphériques/lecteurs sur un transport instable. Testez sans redirections :
- Côté client macOS : dans Microsoft Remote Desktop, désactiver provisoirement « Rediriger les lecteurs », « Imprimantes », « Smart Cards », etc.
- Côté serveur (GPO) : « Do not allow drive redirection », « Do not allow supported Plug and Play device redirection » (uniquement pour test).
5. Comparer 2019 vs 2022
Le fait que Windows Server 2019 ne soit pas impacté dans le même environnement oriente vers une cause réseau/transport plutôt qu’un défaut du service RDP lui‑même. Les piles réseau et les profils par défaut pouvant diverger (par exemple sur l’agressivité d’UDP ou certains offloads), la mitigation « TCP‑only » ci‑dessous est pertinente pour valider l’hypothèse.
Mesures de mitigation lorsque le réseau reste instable
Forcer RDP à utiliser uniquement TCP
Le TCP tolère mieux certaines pertes et les temporisations NAT que l’UDP. Deux stratégies complémentaires :
| Emplacement | Paramètre de stratégie | Valeur |
|---|---|---|
| Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Connection Client | Turn Off UDP On Client | Enabled |
| Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections | Select RDP transport protocols | Enabled → Use only TCP |
Remarque : le client macOS ne propose pas d’option graphique pour désactiver l’UDP, mais la politique côté serveur suffit pour forcer l’utilisation exclusive de TCP.
Mettre à jour le client Microsoft Remote Desktop pour macOS
Assurez‑vous d’utiliser la version 10.x la plus récente. Les corrections de stabilité réseau et les améliorations de canaux virtuels y sont fréquentes.
Réduire la charge graphique et les périphériques redirigés
- Désactiver les animations, l’Aero et autres effets visuels dans la session.
- Réduire la profondeur de couleur, activer la mise en cache bitmap du client.
- Limiter la redirection aux éléments indispensables (presse‑papiers uniquement, par exemple).
Ajuster la MTU en environnement VPN
Si vos tests DF montrent une fragmentation, abaissez la MTU et validez avec un ping non fragmenté vers l’extrémité distante. Autoriser la fragmentation peut contourner certaines limites, mais calibrer la MTU reste préférable.
Procédure pas‑à‑pas (avec commandes)
macOS : mesurer la stabilité du chemin
# Ping soutenu (jitter et pertes)
sudo ping -i 0.2 <ip_serveur>
# Jauge de réactivité (macOS 12+)
networkQuality
# Capture ciblée RDP-UDP
sudo tcpdump -i \ udp port 3389 -vvv -w rdp\_udp.pcap
# Statistiques interface
netstat -ib | grep -E "Name|\"
ifconfig \Windows : vérifier la pile réseau
# Test du port
Test-NetConnection <serveur> -Port 3389
# Erreurs et files
Get-NetAdapterStatistics
Get-NetAdapterAdvancedProperty -Name "Ethernet"
# MTU et sous‑interfaces
netsh interface ipv4 show subinterfaces
netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent
# Trafic UDP 3389 côté serveur
Get-NetUDPEndpoint | Where-Object {$\_.LocalPort -eq 3389}Vérifier les journaux pertinents sur le serveur
- Microsoft‑Windows‑RemoteDesktopServices‑RdpCoreTS/Operational : négociation, transport.
- RemoteConnectionManager/Operational : connexions/déconnexions.
- TerminalServices‑LocalSessionManager/Operational : gestion des sessions.
Cas réel : résolution par remplacement de câble
Dans l’incident ayant motivé cet article, tout pointait vers le réseau : stabilité en RDP sur localhost, pertes sporadiques en ping, erreurs de canaux dynamiques. Après permutation de port de switch et remplacement du câble cuivre entre le poste et le switch, les déconnexions ont disparu. C’est un rappel : la couche physique demeure le maillon le plus fragile.
| Action | Résultat | Conclusion |
|---|---|---|
RDP vers localhost (sur le serveur) | Session stable > 30 min | Service RDP OK, suspect réseau |
| Ping soutenu depuis le Mac | Pertes intermittentes | Instabilité transport |
| Remplacement du câble | Aucune coupure sur 24 h | Cause avérée : câble défectueux |
Scénarios particuliers et pistes complémentaires
Environnement VPN/pare‑feu/NAT
- Minuteries UDP agressives peuvent fermer le flux RDP‑UDP (3389) trop vite. La mitigation TCP‑only est efficace.
- Inspection profonde (DPI) sur UDP peut perturber RDP‑UDP : tester une règle d’exclusion ou passthrough.
- Split‑tunnel : valider la route vers l’IP du serveur et l’absence d’asymétrie.
Wi‑Fi et mobilité
- Préférer Ethernet en production ; le Wi‑Fi introduit jitter et pertes (handover, roaming, DFS).
- Désactiver les options « d’économie d’énergie » susceptibles d’endormir l’interface entre deux keepalives.
RDP Gateway / Broker (si utilisés)
- Vérifier la compatibilité des Transport Settings (UDP/HTTP) et les temps d’inactivité.
- Surveiller les logs Gateway pour corréler les timestamps de coupure.
Expérience utilisateur & MFA
- Des relances MFA rapprochées ne sont pas la cause mais le symptôme d’une reconnexion.
- Une fois la stabilité restaurée, le flux d’authentification redevient normal.
Checklist ultra‑pratique
- ✅ Session RDP locale
localhoststable ? Oui → réseau. - ✅ Ping continu sans pertes/jitter excessif ? Sinon → réseau.
- ✅ MTU validée (DF) ? Adapter si VPN.
- ✅ Câble & port de switch substitués ? Vérifier compteurs d’erreurs.
- ✅ Redirections désactivées pour test ? Réactiver ensuite au besoin.
- ✅ Forcer TCP‑only si le chemin UDP n’est pas fiable.
- ✅ Client Microsoft Remote Desktop à jour (macOS).
- ✅ Effets visuels/charge graphique réduits sur liens contraints.
FAQ ciblée
Pourquoi n’ai‑je pas d’erreurs visibles côté serveur ?
En cas de micro‑coupures réseau, la session peut se rétablir rapidement (tentatives de reconnexion), laissant peu de traces serveur. Les meilleurs « témoins » sont alors les compteurs d’erreurs L2/NIC, les PCAP et les logs client.
Pourquoi Windows Server 2019 est OK et 2022 pose problème ?
Ce type d’écart apparaît quand le transport est en jeu (UDP, offload, MTU) et non le rôle RDP lui‑même. Les piles et valeurs par défaut ayant évolué, un chemin « limite » peut devenir instable sur 2022, tout en restant toléré sur 2019. La mitigation TCP‑only ou la réparation physique (câble/port) lève généralement le doute.
Les erreurs « SendDevicesPacket failed » signifient‑elles que la redirection cause le problème ?
Pas nécessairement. Elles indiquent que le canal de redirection a échoué, souvent parce que le transport sous‑jacent a lâché. Désactiver temporairement la redirection est un bon test : si la stabilité s’améliore, vous avez un indice supplémentaire que le transport est en cause.
Faut‑il désactiver définitivement l’UDP ?
Non. L’UDP améliore nettement l’expérience RDP sur un réseau sain. Utilisez le TCP‑only comme mitigation sur des chemins problématiques. L’objectif final reste de corriger la cause (câble, MTU, pare‑feu, VPN), puis de rétablir l’UDP.
Modèles de messages & scripts utiles
Message d’investigation au support réseau
Objet: Micro‑coupures impactant RDP (UDP 3389)
Bonjour,
Nous observons des déconnexions RDP toutes les 3–10 min depuis macOS vers des serveurs WS2022.
Indices:
- Pertes de paquets intermittentes (ping)
- Erreurs canaux dynamiques RDP
- Stabilité en RDP localhost
Pouvez‑vous vérifier MTU, timers UDP/NAT, CRC et discards sur les ports impliqués ?
Merci.Commande PerfMon (à documenter dans un plan de suivi)
- Ajouter compteurs RDP‑UDP (activité/débits), Network Interface (Packets Outbound/Inbound Errors), TCPv4 (Segments Retransmitted/sec).
Conclusion
En bref : dans ce cas, la cause était triviale mais critique : un câble réseau défectueux. Pour des symptômes similaires (coupures RDP macOS → Windows Server 2022, reconnexions, MFA récurrent), commencez par isoler le réseau : RDP vers localhost, ping/MTU, remplacement de câble et de port, contrôle des compteurs d’erreurs. Si le chemin reste instable, forcez TCP‑only, mettez à jour le client macOS et réduisez la charge graphique/redirections. Une fois la couche physique assainie, réactivez l’UDP pour profiter de ses bénéfices.
Annexes
Récapitulatif des réglages côté stratégie
| Chemin GPO | Paramètre | Valeur recommandée (mitigation) |
|---|---|---|
| Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Connection Client | Turn Off UDP On Client | Enabled |
| Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections | Select RDP transport protocols | Use only TCP |
| User/Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Device and Resource Redirection | Do not allow drive / PnP device redirection | Désactiver temporairement pour test |
Tableau de décision
| Si… | Alors… | Action |
|---|---|---|
RDP localhost stable | Le service RDP est sain | Focaliser sur réseau/transport |
| Pertes en ping/jitter | Instabilité de lien | Câble, port, MTU, VPN, EEE |
| UDP bloqué/défaillant | RDP‑UDP indisponible | Forcer TCP‑only |
| Erreurs canaux dynamiques | Transport instable | Désactiver redirections pour test |
| OK sur 2019, KO sur 2022 | Différence de tolérance | Corriger le réseau, valider avec TCP‑only |
Points clés à retenir
- Des MFA en boucle sont un symptôme d’interruptions brèves du transport, pas la cause.
- Commencez toujours par le physique : un câble peut ruiner votre journée.
- La mitigation TCP‑only est un test simple et efficace pour contourner un chemin UDP dégradé.
- Ajustez la MTU en présence de VPN, et validez par un ping DF non fragmenté.
- Réduisez la charge graphique et les redirections pour stabiliser les sessions sur des liens contraints.
Conclusion opérationnelle : isolez d’abord le réseau (test localhost, ping/MTU, câbles/ports/compteurs), appliquez la mitigation TCP si nécessaire, mettez à jour le client macOS et optimisez la session. Dans le cas présenté, le changement d’un simple câble a tout résolu.