In den meisten Azure-Schulungen taucht Azure Firewall nur in ihrer einfachsten Form auf: eine Instanz im Hub-VNet, gepeerte Spokes, eine benutzerdefinierte Routentabelle leitet ausgehenden Internetverkehr durch die Firewall. Das reicht für die Grundlagen – erklärt aber nicht, was passiert, sobald ein VPN-Gateway im selben Hub dazukommt, BGP ins Spiel kommt oder ein Kunde fragt, warum sein On-Premises-Firewall-Log die falsche Quell-IP zeigt.
Dieser Artikel klärt die Details, die in der Praxis regelmäßig für Verwirrung sorgen: SNAT-Verhalten, Regelverarbeitungsreihenfolge und das Zusammenspiel von UDR und BGP.
Innenleben: ein Backend wie bei einem VM Scale Set
Nach außen zeigt sich Azure Firewall als eine einzige Ressource mit einer festen privaten IP-Adresse im AzureFirewallSubnet und einer oder mehreren Public IPs. Dahinter steckt aber kein einzelnes Gerät: Microsoft betreibt den Dienst laut eigener FAQ auf Azure Virtual Machines – vergleichbar mit einem Scale-Set-Backend, nur ohne eigenes sichtbares VMSS-Objekt im Portal. Die Firewall startet mit zwei VM-Instanzen und skaliert automatisch nach, sobald Durchsatz oder CPU-Auslastung im Schnitt 60 % oder die Verbindungsauslastung 80 % erreichen; ein Scale-Out dauert fünf bis sieben Minuten. Jede Instanz verkraftet maximal 250.000 aktive Verbindungen – das Gesamtlimit der Firewall ergibt sich aus diesem Wert multipliziert mit der Anzahl der Backend-VMs. Fällt eine Instanz ungeplant aus, ersetzt die Plattform sie in etwa 10 Sekunden; bei geplanter Wartung laufen 90 Sekunden Connection Draining (45 Sekunden ohne neue Verbindungen, danach TCP-Reset).
Zeigt der Antwortverkehr dann tatsächlich manchmal die IP eines einzelnen VM-Knotens statt der dokumentierten Firewall-IP? Offiziell bestätigt Microsoft das nicht – die Dokumentation behandelt die private IP-Adresse durchgehend als eine feste, einzelne Adresse der Ressource, die Sie als Next Hop in Ihren UDRs verwenden. Der einzige dokumentierte Fall, in dem sich diese Adresse überhaupt ändert, ist ein vollständiger Deallocate/Allocate-Zyklus der Firewall – danach kann eine neue private IP zugewiesen werden, was bestehende UDRs bricht. Ein indirekter Hinweis auf das Mehrknoten-Backend steckt aber in der vorgeschriebenen Subnetzgröße: Microsoft verlangt für das AzureFirewallSubnet mindestens ein /26 – deutlich mehr Adressraum, als eine einzelne IP bräuchte. Der naheliegende Grund: Jede Backend-Instanz bezieht beim Scale-Out eine eigene Adresse aus diesem Subnetz. Wer so etwas in einem Paketmitschnitt beobachtet, sieht vermutlich einen echten Effekt der internen Architektur – nur eben einen, den Microsoft nicht als reguläres, garantiertes Kundenverhalten dokumentiert.
Die drei Regeltypen – und warum ihre Reihenfolge fix ist
Azure Firewall kennt drei Regeltypen, die jeweils nur in eine Richtung wirken:
| Regeltyp | Richtung | Zweck |
|---|---|---|
| DNAT-Regeln | Nur eingehend | Portweiterleitung von der Public IP der Firewall auf eine private Ziel-IP |
| Netzwerkregeln | Beide Richtungen | Layer-3/4-Filterung nach IP, Port, Protokoll – auch die Freigabe nach einer DNAT-Übersetzung |
| Anwendungsregeln | Nur ausgehend | Layer-7-Filterung nach FQDN/URL, ausschließlich für ausgehenden Verkehr |
Entscheidend ist: Diese Reihenfolge – erst alle DNAT-Regeln, dann alle Netzwerkregeln, dann alle Anwendungsregeln – gilt unabhängig von den Prioritätsnummern einzelner Rule Collections. Priorität entscheidet nur, in welcher Reihenfolge Regeln innerhalb eines Typs ausgewertet werden, nicht zwischen den Typen. Für eingehenden Web-Traffic hat das eine direkte Konsequenz: Weil Anwendungsregeln nur ausgehend wirken, kann Azure Firewall eingehenden HTTP/HTTPS-Verkehr nicht auf Layer 7 prüfen. Dafür ist Application Gateway mit Web Application Firewall vorgesehen – ein Punkt, der in Prüfungsvorbereitungen häufig zu kurz kommt.
SNAT: Wann die Firewall die Quell-IP versteckt – und wann nicht
Für ausgehenden Verkehr über Netzwerkregeln SNATet Azure Firewall standardmäßig alles außer Zielen in privaten Adressbereichen: RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) und RFC 6598 (100.64.0.0/10, Carrier-Grade NAT). Anwendungsregeln SNATen dagegen immer, unabhängig vom Ziel. Genau dieses Detail erklärt, warum Traffic zwischen gepeerten VNets ohne SNAT bei der Ziel-VM ankommt, während Internetverkehr über eine der Public IPs der Firewall läuft.
Problematisch wird es, wenn On-Premises-Netzwerke registrierte, nicht-private IP-Bereiche verwenden: Ohne Anpassung SNATet die Firewall auch diesen Verkehr, und die On-Premises-Firewall sieht nicht mehr die echte Quelladresse. Die Lösung heißt „SNAT private IP ranges“ – eine explizite Liste von Zielbereichen, für die kein SNAT stattfinden soll, ergänzt um die eigenen On-Premises-Präfixe. Seit einiger Zeit gibt es dafür auch eine automatisierte Variante über Azure Route Server, die relevante Bereiche alle 30 Minuten selbst lernt.
UDR gegen BGP: Wer gewinnt, wenn Firewall und VPN-Gateway im selben Hub stehen
Sobald ein VPN-Gateway im Hub-VNet BGP-Routen von On-Premises lernt, tauchen diese automatisch in den Routentabellen benachbarter Subnetze auf – vorausgesetzt, „Propagate gateway routes“ ist aktiv (Standardeinstellung). Für das Zusammenspiel mit einer benutzerdefinierten Route auf dasselbe Ziel gilt eine feste Rangfolge:
- Bei identischer Präfixlänge gewinnt immer die benutzerdefinierte Route (UDR) gegen die BGP-Route, und die BGP-Route gegen die Systemroute.
- Bei unterschiedlicher Präfixlänge entscheidet zuerst Longest-Prefix-Match – die spezifischere Route gewinnt, unabhängig von ihrer Quelle.
- Eine Ausnahme gibt es für Systemrouten zu VNet, Peerings und Service-Endpunkten: Sie gewinnen immer, selbst gegen eine spezifischere BGP-Route.
Praktisch bedeutet das: Eine UDR im AzureFirewallSubnet lässt sich gezielt einsetzen, um Verkehr zu einem On-Premises-Ziel bewusst über die Firewall statt direkt über das Gateway zu erzwingen – oder umgekehrt. Wichtig für jede Hub-Konfiguration: Route Propagation darf auf dem GatewaySubnet selbst nicht deaktiviert werden, sonst funktioniert das Gateway nicht mehr.
Forced Tunneling und das Management-Interface
Sobald die Default-Route im AzureFirewallSubnet nicht ins Internet, sondern zu einer On-Premises-Appliance zeigt (Forced Tunneling), braucht die Firewall einen zweiten, von dieser Route unabhängigen Pfad für ihre eigene Plattformkommunikation – Health-Checks, Updates, Telemetrie. Dafür gibt es ein separates Management-Subnetz mit eigener Public IP, die ausschließlich die Azure-Plattform nutzt, nie der Kundenverkehr. Ohne dieses Management-Interface ist DNAT im Forced-Tunneling-Modus außerdem grundsätzlich nicht unterstützt, weil der Rückverkehr sonst asymmetrisch laufen würde.
Ein Begriff, der oft falsch sitzt: Split Tunneling
Wer ausgehenden Internetverkehr über die Firewall und On-Premises-Verkehr über das VPN-Gateway routet, betreibt kein „Split Tunneling“ im technischen Sinn. Dieser Begriff ist in der Azure-Dokumentation reserviert für Point-to-Site-VPN-Clients, bei denen nur Firmenverkehr durch den Tunnel läuft und Internetverkehr direkt vom Client abgeht. Das zielbasierte Routing im Hub-Netzwerk – Internet über Firewall, On-Premises über Gateway – ist schlicht eine benutzerdefinierte Routenentscheidung nach Zieladresse. Die Unterscheidung lohnt sich in jedem Kurs, weil Teilnehmer den Begriff aus dem klassischen VPN-Kontext mitbringen und leicht falsch anwenden.
💡 Tipp: Sie wollen dieses Zusammenspiel aus Routing, NAT und Firewall-Design nicht nur verstehen, sondern in einer echten Umgebung konfigurieren? → Zum Kursangebot
Quellen: Microsoft Learn – Azure Firewall FAQ, Microsoft Learn – Azure Firewall known issues and limitations, Microsoft Learn – Azure Firewall rule processing logic, Microsoft Learn – Azure Firewall SNAT private IP address ranges, Microsoft Learn – Azure Firewall forced tunneling, Microsoft Learn – Azure Firewall Management NIC, Microsoft Learn – Azure virtual network traffic routing