Quand on parle de performance avec Parallels RAS, on pense souvent à la puissance des RDSH, à la taille des profils FSLogix ou à la qualité du réseau. Mais il y a un paramètre qui passe souvent sous le radar et qui pourtant change radicalement l’expérience utilisateur : le protocole de transport de la session RDP. TCP ou UDP — ce choix impacte directement la fluidité des sessions, surtout sur des réseaux imparfaits.
La bonne nouvelle : Parallels RAS active UDP par défaut. La moins bonne : plusieurs éléments de votre environnement réseau peuvent silencieusement le désactiver sans que vous le sachiez.
TCP vs UDP : l’analogie Netflix
Pour comprendre pourquoi UDP est préférable au TCP pour une session RDP, pensez à Netflix. Netflix utilise QUIC — un protocole basé sur UDP. Pourquoi ? Parce qu’en cas de perte de paquets sur le réseau, QUIC continue à envoyer les données suivantes et corrige les erreurs à la volée. Résultat : une micro-coupure réseau se traduit par une légère dégradation de l’image pendant une fraction de seconde, imperceptible pour l’utilisateur.
Si Netflix utilisait TCP, chaque perte de paquet provoquerait un arrêt complet du flux le temps de la retransmission. La vidéo se fige. L’utilisateur attend. C’est exactement ce qui se passe avec RDP en TCP : une micro-coupure réseau gèle la session, l’écran se fige, et l’utilisateur appelle le support en pensant que « ça plante encore ». En UDP, RAS applique un mécanisme de correction d’erreur similaire au streaming vidéo — la session continue, imperceptiblement.
Les 4 modes de connexion du client Parallels
- Gateway Mode (port 80 par défaut) — le client passe par la Secure Gateway sans chiffrement SSL entre le client et la gateway. Usage typique : réseau interne de confiance. UDP supporté.
- Gateway SSL Mode (port 443 par défaut) — même chose mais avec chiffrement SSL/TLS de bout en bout entre le client et la gateway. UDP supporté via DTLS. C’est le mode recommandé en production.
- Direct Mode — le client se connecte directement au RDSH en RDP, sans passer par la gateway. Le broker fait uniquement la redirection initiale. UDP natif possible. Réservé au LAN avec accès direct aux RDSH.
- Direct SSL Mode — identique au Direct Mode mais avec chiffrement SSL.
En production, le Gateway SSL Mode sur le port 443 couvre tous les cas sans compromis.
UDP activé par défaut dans RAS
Vous n’avez rien à configurer côté RAS. L’UDP Data Tunneling est activé par défaut sur deux composants.
Sur la Secure Gateway, dans l’onglet Network de ses propriétés, Enable RDP UDP Data Tunneling est coché par défaut :
Sur le HALB, dans l’onglet Advanced, Enable RDP UDP tunneling est positionné sur Enable par défaut :
Si vous n’avez jamais touché ces paramètres, UDP est actif. Point.
Alors pourquoi certaines sessions restent en TCP ?
La réponse est toujours dans l’environnement réseau autour de RAS, jamais dans RAS lui-même. Voici les deux principaux coupables.
Le DNS — le piège le plus fréquent
Un client Parallels configuré avec le FQDN externe ras.client.fr en Gateway SSL Mode résoudra ce FQDN vers l’IP publique via le DNS public lorsqu’il est en LAN. Le client passe par le chemin externe, et la session s’établit en TCP car les conditions réseau ne permettent pas la négociation UDP.
La solution : configurer un enregistrement DNS interne qui fait pointer ras.client.fr vers la VIP LAN. Le client utilise le même FQDN, le même certificat, mais le DNS interne le dirige directement vers la Secure Gateway en LAN. L’UDP peut alors s’établir sans contrainte.
Un firewall qui filtre l’UDP/443
Pour que l’UDP fonctionne en Gateway SSL Mode, le port UDP/443 doit être ouvert sur tout le chemin entre le client et la Secure Gateway — y compris sur les firewalls intermédiaires et le HALB. Un firewall configuré pour n’autoriser que le TCP/443 force silencieusement le client à rester en TCP.
Configuration client recommandée en production
- Connexion primaire :
ras.client.fr— Gateway SSL Mode — port 443. En LAN, le DNS interne résout ce FQDN vers la VIP LAN → UDP actif, latence minimale. - Connexion secondaire :
ras.client.fr— Gateway SSL Mode — port 443. Depuis l’extérieur, le DNS public résout vers l’IP publique → Gateway SSL, UDP si le firewall l’autorise.
Même FQDN, même certificat, même configuration client. C’est le DNS qui fait tout le travail de split.
Résultats mesurés
Cas 1 — TCP : DNS public, chemin non optimal
Gateway Mode, DNS public résolvant vers l’IP externe. Transport : TCP, latence 35ms, qualité Good.
Cas 2 — UDP en LAN : connexion directe
Client Windows connecté directement en LAN en Gateway Mode. Transport : UDP, latence 1ms, qualité Excellent, 11 Mbps disponibles.
Cas 3 — UDP en Gateway SSL Mode via VPN
Client Mac via VPN, Gateway SSL Mode, DNS interne correctement poussé. Transport : UDP, latence 42ms, qualité Good, 8,4 Mbps.
Cas 4 — UDP depuis Internet, UDP/443 ouvert
Client Mac depuis Internet sans VPN, Gateway SSL Mode, UDP/443 ouvert sur le routeur. Transport : UDP, latence 36ms, qualité Good, 7,8 Mbps.
Tableau récapitulatif
| Contexte | Mode | Transport | Latence | Qualité | Bande passante |
|---|---|---|---|---|---|
| DNS public, chemin non optimal | Gateway Mode | TCP | 35 ms | Good | 5 Mbps |
| LAN direct | Gateway Mode | UDP | 1 ms | Excellent | 11 Mbps |
| Via VPN + DNS interne | Gateway SSL Mode | UDP | 42 ms | Good | 8,4 Mbps |
| Externe, UDP/443 ouvert | Gateway SSL Mode | UDP | 36 ms | Good | 7,8 Mbps |
Checklist pour garantir l’UDP
- UDP activé sur la Secure Gateway — actif par défaut ✅
- UDP activé sur le HALB — actif par défaut ✅
- UDP/443 ouvert sur les firewalls entre le client et la SG
- DNS interne qui résout le FQDN RAS vers la VIP LAN pour les clients internes
- Gateway SSL Mode configuré sur le client Parallels (port 443)
- Certificat valide sur le FQDN utilisé
Conclusion
L’UDP dans Parallels RAS n’est pas une option à activer — c’est le comportement par défaut. Votre travail en tant qu’administrateur est de vous assurer que rien dans votre environnement réseau ne vient le bloquer silencieusement. Un DNS interne bien configuré, un firewall qui laisse passer l’UDP/443, et un certificat valide : c’est tout ce qu’il faut pour que vos utilisateurs profitent de sessions RDP fluides, même sur des réseaux imparfaits.
