Als het om de prestaties van Parallels RAS gaat, kijken we vaak naar de dimensionering van de RDSH’s, de optimalisatie van FSLogix-profielen of de netwerkbandbreedte. Maar één parameter blijft vaak onder de radar, terwijl hij de gebruikerservaring ingrijpend verandert: het transportprotocol van de RDP-sessie. TCP of UDP — die keuze bepaalt rechtstreeks hoe soepel de sessie loopt, vooral op minder perfecte netwerken.
Het goede nieuws: Parallels RAS zet UDP standaard aan. Het minder goede nieuws: verschillende onderdelen van je netwerkomgeving kunnen het ongemerkt uitschakelen.
TCP vs. UDP: de Netflix-vergelijking
Om te begrijpen waarom UDP voor een RDP-sessie beter is dan TCP, denk aan Netflix. Netflix gebruikt QUIC — een protocol op basis van UDP. Bij pakketverlies blijft QUIC namelijk de volgende gegevens versturen en corrigeert het fouten onderweg. Een microonderbreking in het netwerk levert hooguit een fractie van een seconde een iets minder scherp beeld op, wat de gebruiker niet merkt.
Zou Netflix TCP gebruiken, dan zou elk pakketverlies de stream volledig stilleggen in afwachting van een nieuwe verzending. De video bevriest. De gebruiker wacht. Precies dat gebeurt met RDP in TCP-modus: een microonderbreking in het netwerk bevriest de sessie, het scherm hangt en de gebruiker belt de helpdesk. In UDP-modus past RAS een foutcorrectiemechanisme toe dat lijkt op dat van videostreaming — de sessie loopt gewoon door.
De 4 verbindingsmodi van Parallels Client
- Gateway Mode (standaardpoort 80) — de client gaat via de Secure Gateway, zonder SSL-versleuteling. Typisch gebruik: vertrouwd intern netwerk. UDP ondersteund.
- Gateway SSL Mode (standaardpoort 443) — hetzelfde, maar met end-to-end SSL/TLS-versleuteling. UDP ondersteund via DTLS. Aanbevolen in productie.
- Direct Mode — de client maakt rechtstreeks verbinding met de RDSH, zonder via de gateway te gaan. De broker regelt alleen de eerste omleiding. Bedoeld voor het LAN met directe toegang tot de RDSH’s.
- Direct SSL Mode — gelijk aan Direct Mode, maar met SSL-versleuteling.
In productie dekt Gateway SSL Mode op poort 443 alle situaties zonder compromissen.
UDP staat in RAS standaard aan
Aan RAS-zijde hoef je niets te configureren. UDP Data Tunneling staat standaard aan op zowel de Secure Gateway als de HALB.
Op de Secure Gateway (tabblad Network) is Enable RDP UDP Data Tunneling standaard aangevinkt.
Op de HALB (tabblad Advanced) staat Enable RDP UDP tunneling standaard op Enable.
Heb je deze instellingen nooit aangeraakt, dan is UDP actief. Punt.
Waarom blijven sommige sessies dan op TCP hangen?
Het antwoord ligt altijd in de netwerkomgeving rond RAS, nooit in RAS zelf. Dit zijn de twee hoofdverdachten.
DNS — de meest voorkomende valkuil
Een Parallels Client die in Gateway SSL Mode is ingesteld met de externe FQDN ras.client.com, lost die FQDN op het LAN via de publieke DNS op naar het publieke IP-adres. De client neemt de externe route, en het resultaat is TCP. De oplossing: een intern DNS-record aanmaken dat ras.client.com naar de LAN-VIP laat wijzen. Zelfde FQDN, zelfde certificaat — DNS regelt de splitsing. UDP wordt meteen onderhandeld.
Een firewall die UDP/443 filtert
UDP-poort 443 moet open staan op het hele pad tussen de client en de Secure Gateway — inclusief tussenliggende firewalls en de HALB. Een firewall die alleen TCP/443 doorlaat, dwingt de client ongemerkt om op TCP te blijven.
Aanbevolen clientconfiguratie in productie
- Primaire verbinding:
ras.client.com— Gateway SSL Mode — poort 443. Op het LAN lost de interne DNS op naar de LAN-VIP → UDP actief, minimale latency. - Secundaire verbinding:
ras.client.com— Gateway SSL Mode — poort 443. Van buitenaf lost de publieke DNS op naar het publieke IP-adres → Gateway SSL, met UDP als de firewall het toelaat.
Zelfde FQDN, zelfde certificaat, zelfde clientconfiguratie. DNS doet al het werk.
Gemeten resultaten
Geval 1 — TCP: publieke DNS, niet-optimale route
Gateway Mode, publieke DNS die naar het externe IP-adres oplost. Transport: TCP, latency 35 ms, kwaliteit Good.
Geval 2 — UDP op het LAN: directe verbinding
Windows-client rechtstreeks verbonden op het LAN in Gateway Mode. Transport: UDP, latency 1 ms, kwaliteit Excellent, 11 Mbps beschikbaar.
Geval 3 — UDP in Gateway SSL Mode via VPN
Mac-client via VPN, Gateway SSL Mode, interne DNS correct doorgegeven. Transport: UDP, latency 42 ms, kwaliteit Good, 8,4 Mbps.
Geval 4 — UDP vanaf internet, UDP/443 open
Mac-client vanaf internet zonder VPN, Gateway SSL Mode, UDP/443 open op de router. Transport: UDP, latency 36 ms, kwaliteit Good, 7,8 Mbps.
Samenvatting
| Context | Modus | Transport | Latency | Kwaliteit | Bandbreedte |
|---|---|---|---|---|---|
| Publieke DNS, niet-optimale route | Gateway Mode | TCP | 35 ms | Good | 5 Mbps |
| LAN direct | Gateway Mode | UDP | 1 ms | Excellent | 11 Mbps |
| Via VPN + interne DNS | Gateway SSL Mode | UDP | 42 ms | Good | 8,4 Mbps |
| Extern, UDP/443 open | Gateway SSL Mode | UDP | 36 ms | Good | 7,8 Mbps |
Checklist voor gegarandeerd UDP
- UDP ingeschakeld op de Secure Gateway — standaard actief ✅
- UDP ingeschakeld op de HALB — standaard actief ✅
- UDP/443 open op de firewalls tussen de client en de SG
- Interne DNS die de RAS-FQDN voor interne clients naar de LAN-VIP laat oplossen
- Gateway SSL Mode ingesteld in Parallels Client (poort 443)
- Geldig certificaat voor de gebruikte FQDN
Conclusie
UDP is in Parallels RAS geen optie die je moet inschakelen — het is het standaardgedrag. Jouw taak als beheerder is ervoor te zorgen dat niets in je netwerkomgeving het ongemerkt blokkeert. Een goed ingestelde interne DNS, een firewall die UDP/443 doorlaat en een geldig certificaat: meer is er niet nodig om je gebruikers soepele RDP-sessies te geven, zelfs op minder perfecte netwerken.
