Netzanforderungen: alles ausgehend, und nichts pauschal

Es gibt keine IP-Adressliste, die man statt der Namen freigeben könnte — die Dokumentation schließt das ausdrücklich aus. Und zwei Azure-Plattformadressen dürfen laut Dokumentation nicht abgefangen, über einen Proxy geführt oder umgeleitet werden: Wer eine zentrale Proxy-Vorgabe über die Session Hosts legt, nimmt genau diesen Verkehr mit und bekommt Fehler bei der Bereitstellung, Lücken in der Zustandsüberwachung und Verbindungsprobleme — die alle aussehen wie defekte Hosts. Dieses Modul behandelt, was eine Sitzungsplattform vom Netz braucht: warum alle Verbindungen ausgehend sind, warum die Windows-Aktivierung über Port 1688 und Zertifikatsprüfungen über Port 80 laufen, warum Platzhalter im Diensteverkehr Pflicht sind, und wie man die wirksame Erreichbarkeit misst statt sie anzunehmen.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-13

Zwei Netzbedarfe, die ständig verwechselt werden

Eine Sitzungsplattform hat zwei getrennte Netzbedarfe: die Verbindungen, die der Session Host zu den Plattformdiensten braucht, und die Verbindung, über die der Client seine Sitzung führt. Wer beides gemeinsam plant, reißt regelmäßig in beiden ein Loch.

Client→Dienst und Gateway→Session Host→Plattformdienste

Zwei Pfade, zwei Regelwerke

LernzielDu kannst die Ausgangsverbindungen eines Session Hosts benennen und begrenzen, die Rolle von Dienst-Tags gegenüber Adresslisten einordnen und erkennen, welche Netzkonfigurationen eine Plattform beschädigen, ohne einen Fehler zu melden.

Die Trennung lohnt sich schon deshalb, weil beide Seiten in verschiedenen Händen liegen. Die Hostseite gehört dem Team, das die Azure-Umgebung betreibt, und lässt sich dort vollständig steuern. Die Clientseite liegt in Firmennetzen, Heimnetzen, Mobilfunknetzen und Gastzugängen — also überwiegend außerhalb jeder eigenen Kontrolle. Wer beide Bedarfe in einem Regelwerk zusammenfasst, unterstellt eine Steuerbarkeit, die nur für eine Hälfte besteht.

Der eine Satz, der die Richtung festlegtAlle benötigten Verbindungen sind ausgehend. Für Azure Virtual Desktop muss kein eingehender Port geöffnet werden — weder am Session Host noch an der Firewall davor. Wer eingehendes 3389 öffnet, schafft Angriffsfläche ohne Gegenwert.

Was der Session Host erreichen muss

Die Zielliste ist benannt und begrenzt — eine pauschale Öffnung ins Internet ist also weder nötig noch die Antwort. Ein Auszug der Pflichtziele in der öffentlichen Azure-Cloud:

login.microsoftonline.com: TCP 443 — Authentifizierung. Dienst-Tag AzureActiveDirectory.
*.wvd.microsoft.com: TCP 443 — Diensteverkehr einschließlich TCP-basierter RDP-Verbindung. Dienst-Tag WindowsVirtualDesktop.
51.5.0.0/16: UDP 3478 — weitergeleitete RDP-Verbindung. Dienst-Tag WindowsVirtualDesktop.
*.prod.warm.ingest.monitor.core.windows.net: TCP 443 — Agentverkehr und Diagnoseausgabe. Dienst-Tag AzureMonitor.
mrsglobalsteus2prod.blob.core.windows.net: TCP 443 — Aktualisierungen des Agenten und des Side-by-side-Stapels.
azkms.core.windows.net: TCP 1688 — Windows-Aktivierung.

Zwei Ports, die auffallenDie Windows-Aktivierung läuft über 1688, nicht über 443 — ein Port, den viele Regelwerke gar nicht kennen. Und eine ganze Reihe von Zielen für Zertifikatsprüfungen wird über Port 80 angesprochen, darunter oneocsp.microsoft.com, ctldl.windowsupdate.com und www.microsoft.com. Wer Port 80 ausgehend pauschal sperrt, weil „alles TLS ist“, bricht die Sperrlistenprüfung.

Es gibt keine Adressliste

Ein verbreiteter Wunsch bei Firewallprojekten ist eine Liste von IP-Adressbereichen, die man statt der Namen freigeben könnte. Die Dokumentation beantwortet ihn eindeutig.

Der BefundAzure Virtual Desktop hat keine Liste von IP-Adressbereichen, die man anstelle der FQDNs freigeben kann. Wer eine Firewall der neueren Generation einsetzt, braucht eine dynamische Liste für Azure-Adressen. Empfohlen wird stattdessen die Arbeit mit Dienst-Tags und FQDN-Tags, weil Microsoft die dahinterliegenden Adresspräfixe pflegt und automatisch aktualisiert.

Dienst-Tag — Ein Name, der für eine von Microsoft gepflegte Gruppe von IP-Adresspräfixen eines Azure-Dienstes steht — etwa WindowsVirtualDesktop oder AzureMonitor. Verwendbar in Netzwerksicherheitsgruppen, in Azure Firewall und in benutzerdefinierten Routen. Der Vorteil ist nicht Bequemlichkeit, sondern dass die Regel nicht veraltet.

Für den Diensteverkehr ist das Platzhalterzeichen * in den FQDNs ausdrücklich Pflicht — die Namen dahinter wechseln. Beim Agentverkehr geht es auch ohne, aber der Weg ist mühsam: Die konkreten Namen stehen auf einem registrierten Session Host in der Ereignisanzeige unter *Windows-Protokolle*, *Anwendung*, Quelle WVD-Agent, Ereignis-ID 3701. Diese Namen sind regionsspezifisch; für jede Azure-Region, in der Hosts stehen, ist der Vorgang zu wiederholen.

Zwei Adressen, die man nicht anfassen darf

Neben den benannten Zielen brauchen Session Hosts zwei Azure-Plattformadressen, die sich anders verhalten als alles andere in diesem Modul — und die in gut gemeinten Netzentwürfen regelmäßig zum Opfer fallen.

169.254.169.254: TCP 80 — Azure Instance Metadata Service. Eine verbindungslokale Adresse; der Verkehr verlässt den Host nie.
168.63.129.16: TCP 80 und 32526, dazu 53 über TCP und UDP — Plattformkommunikation des Azure-VM-Agenten: Zustandssignale, DNS bei von Azure bereitgestelltem DNS, DHCP.

Die Warnung im OriginalDer Verkehr zu diesen Adressen darf nicht abgefangen, über einen Proxy geführt oder umgeleitet werden. Netzkonfigurationen, die ihn blockieren oder umleiten, verursachen laut Dokumentation Fehler bei der Bereitstellung, Probleme in der Zustandsüberwachung und Verbindungsprobleme. Das ist die gefährlichste Zeile dieses Moduls, weil eine zentrale Proxy-Vorgabe genau diesen Verkehr mitnimmt — und die Symptome danach aussehen wie defekte Hosts.

Port 53 zu 168.63.129.16 wird nur gebraucht, wenn Azure-DNS genutzt wird. Bei eigenem DNS gehen die Abfragen dorthin — und dann muss die Erreichbarkeit dieser DNS-Server aus dem virtuellen Netz sichergestellt sein.

Kurzcheck

Eine zentrale Vorgabe leitet den gesamten ausgehenden Verkehr der Session Hosts über einen inspizierenden Proxy. Danach schlagen neue Bereitstellungen fehl, und Hosts melden sich unregelmäßig als ungesund. Was ist zu prüfen?

Ob der Verkehr zu den beiden Plattformadressen mit umgeleitet wird.
Ob der Proxy TLS-Inspektion für *.wvd.microsoft.com durchführt.
Ob der Port 1688 für die Windows-Aktivierung offen ist.
Ob die Dienst-Tags in der Firewall aktuell sind.

Treffer. Richtig. Der Verkehr zu 169.254.169.254 und 168.63.129.16 darf nicht abgefangen oder umgeleitet werden; genau diese Symptome nennt die Dokumentation.

Die Clientseite hat eine eigene Liste

Endgeräte, auf denen ein Client läuft, brauchen ihre eigenen Ziele. Sie mit der Hostliste zu verwechseln ist der zweithäufigste Fehler in diesem Feld — die Listen überschneiden sich, sind aber nicht identisch.

*.wvd.microsoft.com und die Diensteverkehrsnamen über TCP 443.
login.microsoftonline.com über TCP 443 für die Authentifizierung.
51.5.0.0/16 über UDP 3478 für die weitergeleitete RDP-Verbindung.
*.servicebus.windows.net über TCP 443 für Daten zur Fehlersuche.
Namen für Verbindungszentrum, automatische Aktualisierungen und Zertifikatsprüfungen — letztere wieder über Port 80.

Nicht unterstützt heißt nicht unterstütztDie Dokumentation sagt es für beide Seiten: Microsoft unterstützt keine Bereitstellungen, in denen die genannten FQDNs und Endpunkte blockiert sind, und das Blockieren der Clientziele beeinträchtigt die Funktion des Dienstes. Eine Umgebung, die aus Sicherheitsgründen einen Teil davon sperrt, verlässt damit den unterstützten Zustand — das gehört vor der Entscheidung auf den Tisch, nicht danach.

Was die Liste nicht enthält

Eine Fehlerquelle entsteht aus einer Auslassung: Die Liste beschreibt nur Azure Virtual Desktop. Andere Dienste, die eine Sitzung ebenfalls braucht, stehen nicht darin.

Microsoft Entra ID hat eigene Endpunkte, die in eingeschränkten Netzen zusätzlich nötig sind.
Microsoft 365 braucht seine eigenen Ziele, wenn Nutzer damit arbeiten sollen.
Eigene DNS-Anbieter und Zeitdienste sind ebenfalls nicht enthalten.
Wer Intune Remote Help für Sitzungsunterstützung nutzt, braucht zusätzlich die von Intune gepflegten Endpunkte.

Der praktische FehlerEin Projekt arbeitet die Liste sorgfältig ab, die Hosts registrieren sich, Sitzungen kommen zustande — und dann kann niemand seine E-Mail öffnen oder die Zeit läuft auseinander. Beides sieht aus wie ein Problem der Sitzungsplattform und ist keines. Die Netzfreigabe für eine Sitzungsplattform ist die Freigabe für einen vollständigen Arbeitsplatz, nicht nur für den Verbindungsaufbau.

Optional heißt nicht entbehrlich

Neben den Pflichtzielen führt die Dokumentation eine Liste optionaler Endpunkte. Optional heißt dort: nicht für den Verbindungsaufbau nötig — für einen brauchbaren Arbeitsplatz aber sehr wohl.

*.prod.do.dsp.mp.microsoft.com: TCP 443 — Windows Update. Ohne dieses Ziel bekommen die Hosts keine Aktualisierungen.
*.digicert.com: TCP 80 — Prüfung von Sperrlisten für Zertifikate.
*.azure-dns.com und *.azure-dns.net: TCP 443 — Namensauflösung über Azure DNS.
*eh.servicebus.windows.net: TCP 443 — Diagnoseeinstellungen. Dienst-Tag EventHub.
www.msftconnecttest.com: TCP 80 — Erkennung, ob der Host überhaupt mit dem Internet verbunden ist.
*.events.data.microsoft.com: TCP 443 — Telemetriedienst.

Warum die Unterscheidung trügtEin Host, der *.prod.do.dsp.mp.microsoft.com nicht erreicht, registriert sich einwandfrei und nimmt Sitzungen an — er veraltet nur still. Ein Host ohne *.digicert.com baut Verbindungen auf, prüft aber keine Sperrlisten mehr. Beides fällt nicht beim Aufbau auf, sondern Monate später bei einer Prüfung. Das Wort optional beschreibt hier die Verbindungsfähigkeit, nicht die Betriebstauglichkeit.

Andere Clouds, andere Namen

Die Zielliste ist nicht dieselbe für alle Azure-Clouds. Wer aus der öffentlichen Cloud kommt und eine Umgebung in einer souveränen Cloud aufbaut, kann die Regeln nicht übernehmen.

Öffentliche Cloud: *.wvd.microsoft.com, login.microsoftonline.com, azkms.core.windows.net, oneocsp.microsoft.com.
Azure für US-Behörden: *.wvd.azure.us, login.microsoftonline.us, azkms.core.usgovcloudapi.net, ocsp.msocsp.com.

Gleich bleiben dabei die Struktur und die Ports: Authentifizierung, Diensteverkehr, Agentverkehr, Aktivierung über 1688 und Zertifikatsprüfungen über 80 — nur unter anderen Namen. Die Dienst-Tags heißen ebenfalls gleich, WindowsVirtualDesktop und AzureMonitor etwa, und stehen in beiden Clouds zur Verfügung.

Der Fehler, den das erzeugtEine Firewallregel, die aus einem Projekt in der öffentlichen Cloud übernommen wird, sieht vollständig aus und ist in einer souveränen Cloud wertlos. Weil die Struktur stimmt, fällt es beim Durchsehen nicht auf — es fällt auf, wenn sich kein Host registriert. Die Ziele gehören für jede Cloud einzeln aus der Dokumentation geholt, nicht aus dem letzten Projekt.

Prüfen statt annehmen

Für die Frage, ob ein Session Host die benötigten Ziele tatsächlich erreicht, gibt es ein eigenes Werkzeug: das Azure Virtual Desktop Agent URL Tool. Es prüft jeden FQDN und jeden Endpunkt einzeln und zeigt, welche erreichbar sind.

Der Wert liegt darin, dass es die wirksame Lage misst statt der beabsichtigten. Zwischen einer Firewallregel und der Erreichbarkeit eines Ziels liegen Routen, Proxys, Namensauflösung und lokale Regeln auf dem Host — jede davon kann eine korrekt gemeinte Freigabe wirkungslos machen.

Ein Host, der sich nicht registriert

Szenario

Ein neu bereitgestellter Session Host erscheint dauerhaft als nicht verfügbar. Die Firewallregeln wurden nach der Dokumentation gesetzt, das Netzteam bestätigt, dass die Ziele freigegeben sind. Die Maschine selbst läuft, die Anmeldung per Remotedesktop direkt auf den Host funktioniert.

Anforderungen

Die Ursache soll benannt werden, bevor der Host neu erzeugt wird.
Das Ergebnis soll zwischen Hostproblem und Netzproblem entscheiden.

Schritte

Das Agent URL Tool auf dem Host laufen lassen — es benennt genau die Ziele, die nicht erreichbar sind.
Bei Treffern prüfen, ob für den Diensteverkehr Platzhalter verwendet wurden; ohne sie greifen die Regeln nicht.
Prüfen, ob der Verkehr zu den beiden Plattformadressen umgeleitet wird.
Bei Agentverkehr: Ereignis-ID 3701 im Protokoll WVD-Agent auslesen und die dort genannten regionsspezifischen Namen freigeben.
Erst wenn alle Ziele erreichbar sind und der Host sich weiterhin nicht registriert, lohnt der Blick auf den Host selbst.

Merksatz: Dass eine Regel existiert, ist keine Aussage darüber, dass ein Ziel erreichbar ist. Zwischen beidem liegen genug Schichten, um eine sorgfältige Freigabe wirkungslos zu machen — und das Werkzeug entscheidet die Frage in Minuten.

Was das Werkzeug nicht prüftEs prüft die Ziele von Azure Virtual Desktop. Es sagt nichts darüber, ob Microsoft Entra ID, Microsoft 365, der eigene DNS-Dienst oder ein Zeitdienst erreichbar sind — die stehen gar nicht in der Liste. Ein grünes Ergebnis bedeutet also: Die Plattform kann arbeiten. Ob ein Mensch darin arbeiten kann, ist damit nicht beantwortet.

Der Weg der Sitzung selbst

Von den Verbindungen der Plattform ist der Weg zu unterscheiden, den die Sitzung nimmt. Er beginnt immer mit einer TCP-basierten Rückverbindung über das Gateway und wechselt, wenn die Netzlage es zulässt, auf einen direkten UDP-Transport.

Weitergeleitet: Über den Dienst, notfalls über eine UDP-Weiterleitung aus 51.5.0.0/16. Funktioniert nahezu überall, fügt aber einen Umweg hinzu.
Direkt: Client und Host verbinden sich unmittelbar, sobald Firewalls und Adressumsetzung es erlauben. Kürzerer Weg, gleichmäßigere Latenz.

Was das für die Netzplanung heißtWeil sich der Aufenthaltsort der Nutzer in den meisten Fällen nicht vorhersagen lässt, empfiehlt die Dokumentation, ausgehende UDP-Verbindungen von den Session Hosts ins Internet zuzulassen. Wer die Zahl der Ports verkleinern will, kann den verwendeten Bereich einschränken — öffnen muss er ihn trotzdem. Ohne UDP bleibt der TCP-Rückfall, und der funktioniert, nur eben mit schwankenderer Latenz.

Für die Firewall heißt das zweierlei. Ausgehend braucht das Subnetz der Session Hosts UDP zu den Zielports des dynamischen Bereichs sowie UDP 3478 in Richtung des Weiterleitungsbereichs. Auf der Clientseite gilt dasselbe in Richtung der öffentlichen Adressen, die der Adressumsetzung der Hosts zugeordnet sind. Beide Richtungen bleiben ausgehend — auch der direkte Transport verlangt keine eingehende Öffnung.

Bandbreite gehört zum Netzentwurf

Der letzte Teil des Netzbedarfs ist die Menge. Sie hängt nicht an der Zahl der Nutzer, sondern an ihrer Tätigkeit — und die Spanne ist groß genug, dass ein Mittelwert beide Enden verfehlt.

Eine untätige Sitzung kostet etwa 0,3 Kbit/s; ein minimiertes Clientfenster erzeugt gar keine Grafikdaten.
Textverarbeitung liegt bei 100–150 Kbit/s, grafikreiches Surfen bei 6–6,5 Mbit/s — ein Faktor von rund vierzig zwischen zwei Bürotätigkeiten.
Auflösung und Monitorzahl wirken zusätzlich und unabhängig von der Tätigkeit.
Ein einzelner großer Druckauftrag oder eine Dateiübertragung erzeugt eine Spitze, die mit dem Arbeitsprofil nichts zu tun hat.

Geplant wird für die gleichzeitige SpitzeWeil die Verteilung extrem schief ist — der größte Teil der Zeit kostet fast nichts, einzelne Minuten das Hundertfache —, führt eine Rechnung aus dem Mittelwert je Nutzer mal Nutzerzahl zuverlässig in die Irre. Gemessen wird an echten Verbindungen, und geplant wird für die Spitze, die tatsächlich gleichzeitig auftritt.

Zur Menge kommt die Gleichmäßigkeit. Paketverlust und schwankende Laufzeit zerstören das Erlebnis stärker als eine gleichmäßig etwas höhere Latenz, weil RDP seine Bildrate und Bildqualität laufend an die gemessenen Bedingungen anpasst. Eine Leitung, die im Mittel genügt und in Spitzen einbricht, erzeugt deshalb ein Bild, das ständig zwischen scharf und unscharf wechselt — und genau das melden Nutzer als unruhig, nicht als langsam.

Der Preis einer engen Freigabe

Dienst-Tags verwenden: Regeln veralten nicht — und man gibt eine von Microsoft gepflegte Adressmenge frei, deren Inhalt man nicht selbst kontrolliert.
FQDNs mit Platzhaltern: Für Diensteverkehr Pflicht — und ein Platzhalter ist per Definition weiter als eine Einzelfreigabe.
Agentnamen einzeln freigeben: Engste Variante — und sie muss je Region ermittelt und bei jeder Änderung nachgezogen werden.
Ausgehendes UDP zulassen: Ermöglicht den direkten Transport — und öffnet einen Portbereich, den man lieber geschlossen hätte.

Eine Netzfreigabe für eine Sitzungsplattform ist immer ein Kompromiss zwischen Enge und Haltbarkeit. Die engste Variante ist die, die am schnellsten veraltet — und eine veraltete Regel fällt nicht als Regel auf, sondern als Host, der sich nicht registriert.

Die Reihenfolge, die sich bewährtErst mit Dienst- und FQDN-Tags in Betrieb gehen, dann messen, was tatsächlich gebraucht wird, und erst danach — wenn überhaupt — verengen. Wer umgekehrt vorgeht, verbringt die Inbetriebnahme mit der Suche nach fehlenden Freigaben und kann am Ende nicht unterscheiden, was gefehlt hat und was nie nötig war.

Und eine Bemerkung zur Dokumentationspflicht: Weil die Ziele je Cloud, je Region und je Verkehrsart unterschiedlich sind, veraltet jede Freigabeliste, die nicht an ihre Quelle gebunden ist. In der Firewalldokumentation gehört deshalb nicht nur die Regel, sondern auch der Grund — welches Ziel für welchen Zweck, aus welcher Cloud und mit welchem Dienst-Tag. Ohne diesen Bezug traut sich in zwei Jahren niemand mehr, eine Regel zu entfernen, und die Freigabe wächst monoton.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität5 Primärquellen · zuletzt geprüft: 2026-09-13