Azure Firewall – Häufig gestellte Fragen

Azure Firewall ist ein verwalteter, cloudbasierter Netzwerksicherheitsdienst, der Ihre Azure Virtual Network-Ressourcen schützt. Es ist eine vollständig zustandsbehaftete Firewall als ein Dienst mit integrierter Hochverfügbarkeit und uneingeschränkter Cloudskalierbarkeit. Sie können Richtlinien zur Anwendungs- und Netzwerkkonnektivität übergreifend für Abonnements und virtuelle Netzwerke zentral erstellen, erzwingen und protokollieren.

Informationen zu Features von Azure Firewall finden Sie unter Azure Firewall-Features.

Sie können Azure Firewall in einem virtuellen Netzwerk bereitstellen, Kunden stellen Azure Firewall jedoch in der Regel in einem zentralen virtuellen Netzwerk bereit und verbinden andere virtuelle Netzwerke in einem Hub-and-Spoke-Modell damit. Sie können die Standardroute von den verbundenen virtuellen Netzwerken anschließend so festlegen, dass sie auf dieses zentrale virtuelle Firewall-Netzwerk verweist. Globales VNET-Peering wird unterstützt, aber aufgrund von potenziellen Leistungs- und Latenzproblemen in den Regionen nicht empfohlen. Für optimale Leistungen stellen Sie eine Firewall pro Region bereit.

Der Vorteil dieses Modells ist die Möglichkeit, die Kontrolle über mehrere Spoke-VNETs über verschiedene Abonnements hinweg zentral auszuüben. Es ergeben sich zudem Kosteneinsparungen, da Sie nicht in jedem VNet separat eine Firewall bereitstellen müssen. Die Kosteneinsparungen sollten anhand der zugeordneten Peeringkosten auf der Grundlage der Datenverkehrsmuster der Kunden gemessen werden.

Sie können Azure Firewall über das Azure-Portal, PowerShell, die REST-API oder Vorlagen einrichten. Siehe Tutorial: Bereitstellen und Konfigurieren von Azure Firewall über das Azure-Portal.

Azure Firewall unterstützt-Regeln und Regelsammlungen. Eine Regelsammlung ist eine Liste von Regeln mit gleicher Reihenfolge und Priorität. Regelsammlungen werden in der Reihenfolge ihrer Priorität ausgeführt. DNAT-Regelsammlungen sind Netzwerkregelsammlungen mit höherer Priorität, die höhere Priorität haben als Anwendungsregelsammlungen, und alle Regeln werden beendet.

Es gibt drei Arten von Regelsammlungen:

• Anwendungsregeln: Konfigurieren vollqualifizierter Domänennamen (Fully Qualified Domain Names, FQDNs), auf die von einem virtuellen Netzwerk aus zugegriffen werden kann.
• Netzwerkregeln: Konfigurieren von Regeln mit Quelladressen, Protokollen, Zielports und Zieladressen.
• NAT-Regeln: Konfigurieren Sie DNAT-Regeln, um eingehende Internet- oder Intranetverbindungen (Vorschau) zuzulassen.

Weitere Informationen finden Sie unter Konfigurieren der Firewall.

Azure Firewall unterstützt Filter für eingehenden und ausgehenden Datenverkehr. Der eingehende Schutz wird in der Regel für Nicht-HTTP-Protokolle wie RDP-, SSH- und FTP-Protokolle verwendet. Verwenden Sie für den eingehenden HTTP- und HTTPS-Schutz eine Webanwendungsfirewall wie Azure Web Application Firewall (WAF) oder die TLS-Auslagerungs- und Tiefenpaketüberprüfungsfunktionen von Azure Firewall Premium.

Ja, Azure Firewall Basic unterstützt erzwungenes Tunneln.

Azure Firewall ist zum Anzeigen und Analysieren von Firewallprotokollen in Azure Monitor integriert. Protokolle können an Log Analytics, Azure Storage oder Event Hubs gesendet werden. Sie können in Log Analytics oder von anderen Tools, wie Excel und Power BI, analysiert werden. Weitere Informationen finden Sie im Tutorial: Überwachen von Azure Firewall-Protokollen.

Azure Firewall ist ein verwalteter, cloudbasierter Netzwerksicherheitsdienst zum Schutz Ihrer VNet-Ressourcen. Es ist eine vollständig zustandsbehaftete Firewall-as-a-Service mit integrierter Hochverfügbarkeit und uneingeschränkter Cloudskalierbarkeit. Es ist bereits in SECaaS-Anbieter (Security-as-a-Service) von Drittanbietern integriert, um erweiterte Sicherheit für Ihr virtuelles Netzwerk und Ihre Internetverbindungen von Zweigstellen bereitzustellen. Weitere Informationen zur Netzwerksicherheit in Azure finden Sie unter Azure-Netzwerksicherheit.

Die Web Application Firewall (WAF) ist ein Feature von Application Gateway, das zentralisierten Schutz des eingehenden Datenverkehrs für Ihre Webanwendungen vor allgemeinen Exploits und Sicherheitsrisiken bietet. Azure Firewall bietet Schutz für eingehenden Datenverkehr für Nicht-HTTP/S-Protokolle (z.B. RDP, SSH, FTP), Schutz auf Netzwerkebene für eingehenden Datenverkehr für alle Ports und Protokolle sowie Schutz auf Anwendungsebene für ausgehenden HTTP/S-Datenverkehr.

Der Azure Firewall-Dienst ergänzt die Funktionen der Netzwerksicherheitsgruppen. Zusammen bieten sie eine bessere „Defense-in-Depth“-Netzwerksicherheit. Netzwerksicherheitsgruppen bieten verteilte Datenverkehrsfilterung auf Netzwerkebene, um den Datenverkehr auf Ressourcen in virtuellen Netzwerken in jedem Abonnement zu beschränken. Azure Firewall ist eine vollständig zustandsbehaftete, zentrale Netzwerkfirewall als Dienst, die Schutz auf Netzwerk- und Anwendungsebene für verschiedene Abonnements und virtuelle Netzwerke bietet.

Azure Firewall ist ein verwalteter Dienst mit mehreren Schutzebenen, z. B. Plattformschutz mit NSGs auf NIC-Ebene (nicht sichtbar). NSGs auf Subnetzebene sind in AzureFirewallSubnet nicht erforderlich und deaktiviert, um zu verhindern, dass es zu Dienstunterbrechungen kommt.

Für den sicheren Zugriff auf PaaS-Dienste werden Dienstendpunkte empfohlen. Sie können Dienstendpunkte im Azure Firewall-Subnetz aktivieren und diese im verbundenen virtuellen Spoke-Netzwerk deaktivieren. Auf diese Weise profitieren Sie von beiden Features: von der Dienstendpunktsicherheit und der zentralen Protokollierung des gesamten Datenverkehrs.

Informationen hierzu finden Sie unter Azure Firewall – Preise.

Sie können Azure PowerShell verwenden, um Methoden zuzuordnen und die Zuordnung dafür aufzuheben (Zuordnen und Zuordnung aufheben). Bei einer Firewall, die für die Tunnelerzwingung konfiguriert ist, muss etwas anders vorgegangen werden.

Beispiel für eine NICHT für die Tunnelerzwingung konfigurierte Firewall:

# Stop an existing firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet,@($publicip1,$publicip2))

Set-AzFirewall -AzureFirewall $azfw

Bei einer für die Tunnelerzwingung konfigurierten Firewall ist der Prozess zum Anhalten der gleiche. Für den Start muss der Firewall jedoch die öffentliche IP-Adresse für die Verwaltung erneut zugewiesen werden:

# Stop an existing firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip= Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip2 = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip2)
$azfw | Set-AzFirewall

Für eine Firewall in einer Architektur mit einem geschützten virtuellen Hub ist die Vorgehensweise zum Beenden identisch, aber zum Starten muss die ID des virtuellen Hubs verwendet werden:

# Stop and existing firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall

$virtualhub = get-azvirtualhub -ResourceGroupName "RG name of vHUB" -name "vHUB name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Azfw RG Name"
$azfw.Allocate($virtualhub.Id)
$azfw | Set-AzFirewall

Wenn Sie Zuordnungen erteilen und aufheben, wird die Firewall-Abrechnung entsprechend gestartet oder pausiert.

Es wird empfohlen, Verfügbarkeitszonen während der anfänglichen Firewallbereitstellung zu konfigurieren. In einigen Fällen ist es jedoch möglich, Verfügbarkeitszonen nach der Bereitstellung zu ändern. Folgende Voraussetzungen müssen erfüllt sein:

• Die Firewall wird in einem VNet bereitgestellt. Dies wird bei Firewalls, die in einem geschützten virtuellen Hub bereitgestellt werden, nicht unterstützt.
• Die Region der Firewall unterstützt Verfügbarkeitszonen.
• Alle angefügten öffentlichen IP-Adressen werden mit Verfügbarkeitszonen bereitgestellt. Stellen Sie auf der Eigenschaftenseite der einzelnen öffentlichen IP-Adressen sicher, dass das Feld Verfügbarkeitszonen vorhanden ist und mit denselben Zonen konfiguriert ist, die Sie für die Firewall konfiguriert haben.

Die Neukonfiguration von Verfügbarkeitszonen kann nur durchgeführt werden, wenn Sie die Firewall neu starten. Nachdem Sie die Firewall zugeordnet haben, verwenden Sie direkt vor dem Starten der Firewall mit Set-AzFirewall den folgenden Azure PowerShell-Befehl, um die Eigenschaft Zones der Firewall zu ändern:

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip= Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip2 = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip2)
$azFw.Zones=1,2,3
$azfw | Set-AzFirewall

Die Einschränkungen des Azure Firewall-Diensts finden Sie unter Einschränkungen für Azure-Abonnements und Dienste, Kontingente und Einschränkungen.

Ja, Sie können Azure Firewall in einem virtuellen Hubnetzwerk verwenden, um den Datenverkehr zwischen mehreren virtuellen Spoke-Netzwerken weiterzuleiten und zu filtern. Subnetze in jedem der virtuellen Spoke-Netzwerke müssen über eine UDR verfügen, die auf die Azure Firewall als Standardgateway verweist, damit dieses Szenario ordnungsgemäß funktioniert.

Ja. Die Konfiguration der UDRs zur Umleitung des Datenverkehrs zwischen Subnetzen im gleichen VNET erfordert jedoch zusätzliche Anstrengungen. Während die Verwendung des VNET-Adressbereichs als Zielpräfix für den UDR ausreicht, wird auch der gesamte Datenverkehr von einem Computer zu einem anderen Computer im gleichen Subnetz über die Azure Firewall-Instanz geleitet. Um dies zu vermeiden, fügen Sie eine Route für das Subnetz in den UDR mit dem Typ VNET für den nächsten Hop ein. Das Verwalten dieser Routen kann umständlich und fehleranfällig sein. Die empfohlene Methode für die interne Netzwerksegmentierung ist die Verwendung von Netzwerksicherheitsgruppen, die keine UDRs erfordern.

Azure Firewall bietet kein SNAT, wenn die Ziel-IP-Adresse ein privater IP-Adressbereich gemäß IANA RFC 1918 oder IANA RFC 6598 für private Netzwerke ist. Wenn Ihre Organisation einen öffentlichen IP-Adressbereich für private Netzwerke verwendet, leitet Azure Firewall den Datenverkehr per SNAT an eine der privaten IP-Adressen der Firewall in AzureFirewallSubnet weiter. Sie können Azure Firewall so konfigurieren, dass Ihr öffentlicher IP-Adressbereich nicht per SNAT weitergeleitet wird. Weitere Informationen finden Sie unter Azure Firewall SNAT – private Adressbereiche.

Darüber hinaus wird von Anwendungsregeln verarbeiteter Datenverkehr immer durch SNAT übersetzt. Wenn Sie die ursprüngliche Quell-IP-Adresse in Ihren Protokollen für FQDN-Datenverkehr anzeigen möchten, können Sie Netzwerkregeln mit dem Ziel-FQDN verwenden.

Tunnelerzwingung wird beim Erstellen einer neuen Firewall unterstützt. Sie können eine vorhandene Firewall nicht für die Tunnelerzwingung konfigurieren. Weitere Informationen finden Sie unter Azure Firewall-Tunnelerzwingung.

Azure Firewall muss über eine direkte Internetverbindung verfügen. Wenn Ihr Subnetz „AzureFirewallSubnet“ eine Standardroute zu Ihrem lokalen Netzwerk über BGP erfasst, müssen Sie diese mit der benutzerdefinierten Route 0.0.0.0/0 überschreiben. Legen Sie dabei den Wert NextHopType auf Internet fest, um die direkte Internetkonnektivität beizubehalten.

Wenn für Ihre Konfiguration die Erzwingung eines Tunnels zu einem lokalen Netzwerk erforderlich ist und Sie die Ziel-IP-Präfixe für Ihre Internetziele ermitteln können, können Sie diese Bereiche mit dem lokalen Netzwerk als nächsten Hop über eine benutzerdefinierte Route im Subnetz „AzureFirewallSubnet“ konfigurieren. Oder Sie können BGP verwenden, um diese Routen zu definieren.

Ja.

• Die Firewall und das VNet müssen sich in derselben Ressourcengruppe befinden.
• Die öffentliche IP-Adresse kann sich in einer beliebigen Ressourcengruppe befinden.
• Die Firewall, das VNet und die öffentliche IP-Adresse müssen sich im gleichen Abonnement befinden.

• URL: Sternchen funktionieren, wenn sie ganz rechts oder ganz links platziert werden. Wenn sie sich auf der linken Seite befinden, können sie nicht Teil des FQDN sein.
• FQDN: Sternchen funktionieren, wenn sie ganz links platziert werden.
• ALLGEMEIN: Die Sternchen auf der linken Seite bedeuten, dass buchstäblich alles, was links davon steht, übereinstimmt, d. h. mehrere Subdomänen und/oder potenziell unerwünschte Domänennamenvariationen gelten als übereinstimmend (siehe folgende Beispiele).

Beispiele:

Wenn eine Konfigurationsänderung angewendet wird, versucht Azure Firewall alle zugrunde liegenden Back-End-Instanzen zu aktualisieren. In seltenen Fällen kann bei der Aktualisierung einer dieser Back-End-Instanzen mit der neuen Konfiguration ein Fehler auftreten und der Aktualisierungsvorgang mit dem Bereitstellungsstatus „Fehler“ angehalten werden. Azure Firewall ist noch funktionsfähig, die angewendete Konfiguration befindet sich jedoch unter Umständen in einem inkonsistenten Zustand, in dem einige Instanzen die vorherige Konfiguration und andere den aktualisierten Regelsatz verwenden. Versuchen Sie in diesem Fall, die Konfiguration noch einmal zu aktualisieren, bis der Vorgang erfolgreich war und für Ihre Firewall der Bereitstellungsstatus Erfolgreich angezeigt wird.

Azure Firewall besteht aus mehreren Back-End-Knoten in einer aktiv/aktiv-Konfiguration. Für jede geplante Wartung gibt es Verbindungsausgleichslogik zum ordnungsgemäßen Aktualisieren von Knoten. Updates sind für jede Azure-Region außerhalb der Geschäftszeiten geplant, um das Risiko einer Unterbrechung weiter einzuschränken. Bei nicht geplanten Problemen wird ein neuer Knoten instanziiert, um den fehlerhaften Knoten zu ersetzen. Die Konnektivität zum neuen Knoten wird in der Regel innerhalb von 10 Sekunden nach dem Zeitpunkt des Fehlers wieder hergestellt.

Für jede geplante Wartung gibt es Verbindungsausgleichslogik zum ordnungsgemäßen Aktualisieren von Back-End-Knoten. Azure Firewall wartet 90 Sekunden lang darauf, dass bestehende Verbindungen geschlossen werden. In den ersten 45 Sekunden akzeptiert der Back-End-Knoten keine neuen Verbindungen, und in der verbleibenden Zeit reagiert er mit RST auf alle eingehenden Pakete. Bei Bedarf können Clients automatisch eine neue Verbindung mit einem anderen Back-End-Knoten herstellen.

Ja. Ein Firewallname ist auf 50 Zeichen beschränkt.

Der Azure Firewall-Dienst muss mehr VM-Instanzen bereitstellen, als er skaliert. Ein /26-Adressraum stellt sicher, dass für die Firewall genügend IP-Adressen vorhanden sind, um der Skalierung gerecht zu werden.

Nein. Azure Firewall benötigt kein Subnetz, das größer als /26 ist.

Die anfängliche Durchsatzkapazität von Azure Firewall beträgt 2,5–3 GBit/s, und sie skaliert auf 30 GBit/s für Standard-SKU und 100 GBit/s für Premium-SKU. Es wird automatisch basierend auf CPU-Auslastung, Durchsatz und Anzahl der Verbindungen skaliert.

Azure Firewall skaliert schrittweise, wenn der durchschnittliche Durchsatz oder die CPU-Auslastung bei 60 % oder die Anzahl der Verbindungen bei 80 % liegt. Zum Beispiel beginnt der Dienst mit dem Aufskalieren, wenn er 60 % des maximalen Durchsatzes erreicht. Die maximalen Durchsatzzahlen variieren je nach Firewall-SKU und aktivierten Features. Weitere Informationen finden Sie unter Azure Firewall-Leistung.

Das Aufskalieren dauert zwischen fünf und sieben Minuten.

Sorgen Sie bei Leistungstests dafür, mindestens 10 bis 15 Minuten zu testen, und richten Sie neue Verbindungen ein, um neu erstellte Firewallknoten nutzen zu können.

Wenn für eine Verbindung ein Leerlauftimeout (vier Minuten lang keine Aktivität) vorliegt, beendet Azure Firewall die Verbindung ordnungsgemäß, indem ein TCP-RST-Paket gesendet wird.

Während des Abskalierens (Herunterskalierens) von VM-Skalierungsgruppen oder bei Flottensoftwareupgrades kann es zum Herunterfahren einer Azure Firewall-VM-Instanz kommen. In diesen Fällen werden neue eingehende Verbindungen per Lastenausgleich zu den verbleibenden Firewallinstanzen und nicht zur heruntergefahrenen Firewallinstanz weitergeleitet. Nach 45 Sekunden beginnt die Firewall, vorhandene Verbindungen durch Senden von TCP-RST-Paketen abzulehnen. Nach weiteren 45 Sekunden wird die Firewall-VM heruntergefahren. Weitere Informationen finden Sie unter TCP-Zurücksetzung und Leerlauftimeout für Load Balancer.

Nein. Standardmäßig blockiert Azure Firewall den Zugriff auf Active Directory. Konfigurieren Sie das Diensttag „AzureActiveDirectory“, um den Zugriff zuzulassen. Weitere Informationen finden Sie unter Azure Firewall-Diensttags.

Ja, Sie können dafür Azure PowerShell verwenden:

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

Ein TCP-Ping stellt tatsächlich keine Verbindung mit dem Ziel-FQDN her. Azure Firewall lässt keine Verbindung mit einer Ziel-IP-Adresse/einem FQDN zu, es sei denn, es gibt eine explizite Regel, die diese zulässt.

TCP-Ping ist ein besonderer Anwendungsfall: Wenn keine Zulassungsregel vorhanden ist und der TCP-Ping die IP-Zieladresse/den FQDN nicht erreichen kann, wird die TCP-Pinganforderung von der Firewall selbst beantwortet. In diesem Fall wird das Ereignis nicht protokolliert. Wenn eine Netzwerkregel vorhanden ist, die den Zugriff auf die IP-Zieladresse bzw. den FQDN zulässt, erreicht die Pinganforderung den Zielserver, und die Antwort wird an den Client zurückgeleitet. Dieses Ereignis wird im Protokoll für Netzwerkregeln protokolliert.

Ja. Weitere Informationen finden Sie unter Grenzwerte für Azure-Abonnements, -Dienste und -Kontingente sowie allgemeine Beschränkungen.

Nein, das Verschieben einer IP-Gruppe in eine andere Ressourcengruppe wird zurzeit nicht unterstützt.

Das Standardverhalten einer Netzwerkfirewall besteht darin, TCP-Verbindungen aufrechtzuerhalten und sie sofort zu schließen, wenn es keine Aktivität gibt. Das TCP-Leerlauftimeout von Azure Firewall beträgt vier Minuten. Diese Einstellung kann nicht benutzerseitig konfiguriert werden. Sie können sich jedoch an den Azure-Support wenden, um das Leerlauftimeout für eingehende und ausgehende Verbindungen auf bis zu 15 Minuten zu erhöhen. Das Leerlauftimeout für Ost-West-Datenverkehr kann nicht geändert werden.

Wenn die Dauer einer Inaktivitätsperiode den Timeoutwert überschreitet, gibt es keine Garantie dafür, dass die TCP- oder HTTP-Sitzung aufrechterhalten wird. Eine gängige Methode zur Aufrechterhaltung von Verbindungen ist TCP-Keep-Alive. Dadurch bleibt die Verbindung länger aktiv. Weitere Informationen finden Sie in den .NET-Beispielen.

Ja, aber Sie müssen die Firewall im Modus „Tunnelerzwingung“ konfigurieren. Diese Konfiguration erstellt eine Verwaltungsschnittstelle mit einer öffentlichen IP-Adresse, die von Azure Firewall für ihre Vorgänge verwendet wird. Diese öffentliche IP-Adresse ist für Verwaltungsdatenverkehr vorgesehen. Sie wird ausschließlich von der Azure-Plattform verwendet und kann nicht für andere Zwecke verwendet werden. Das Tenant Datapath-Netzwerk kann ohne öffentliche IP-Adresse konfiguriert werden, und der Internet-Datenverkehr kann zu einer anderen Firewall getunnelt oder vollständig blockiert werden.

Azure Firewall speichert Kundendaten in der Region, in der sie bereitgestellt werden, und verschiebt sie nicht aus dieser Region.

Ja. Weitere Informationen finden Sie unter Sichern von Azure Firewall und der Azure Firewall-Richtlinie mit Logic Apps.

Nein, derzeit wird Azure Firewall in geschützten virtuellen Hubs (vWAN) in Katar nicht unterstützt.

Azure Firewall verwendet Azure Virtual Machines als Basis, die eine feste Begrenzung der Anzahl von Verbindungen aufweisen. Die Gesamtzahl der aktiven Verbindungen pro virtuellen Computer beträgt 250k.

Das Gesamtlimit pro Firewall ist das VM-Verbindungslimit (250 000) x die Anzahl der VMs im Back-End-Pool der Firewall. Azure Firewall beginnt mit zwei VMs und wird basierend auf der CPU-Auslastung und dem Durchsatz aufskaliert.

Azure Firewall verwendet derzeit TCP/UDP-Quellports für ausgehenden SNAT-Datenverkehr ohne Leerlaufzeit. Wenn eine TCP/UDP-Verbindung geschlossen wird, wird der verwendete TCP-Port sofort als verfügbar für anstehende Verbindungen angesehen.

Als Problemumgehung für bestimmte Architekturen können Sie NAT-Gateway mit Azure Firewall bereitstellen und skalieren, um einen breiteren Pool von SNAT-Ports für Variabilität und Verfügbarkeit bereitzustellen.

Das spezifische NAT-Verhalten hängt von der Konfiguration der Firewall und der Art von NAT ab, die konfiguriert ist. Die Firewall verfügt beispielsweise über DNAT-Regeln für den eingehenden Datenverkehr und über Netzwerkregeln und Anwendungsregeln für den ausgehenden Datenverkehr durch die Firewall.

Weitere Informationen finden Sie unter Azure Firewall NAT-Verhalten.