Bekannte Probleme und Einschränkungen der Azure Firewall
In diesem Artikel werden die bekannten Probleme für die Azure Firewall aufgeführt. Er wird aktualisiert, wenn Probleme behoben werden.
Die Einschränkungen von Azure Firewall finden Sie unter Einschränkungen für Azure-Abonnements und Dienste, Kontingente und Beschränkungen.
Azure Firewall Standard
Für Azure Firewall Standard sind die folgenden Probleme bekannt:
Hinweis
Alle Probleme, die für „Standard“ gelten, treffen auch auf „Premium“ zu.
| Problem | BESCHREIBUNG | Minderung |
|---|---|---|
| Netzwerkfilterregeln für andere Protokolle als TCP/UDP (z.B. ICMP) funktionieren nicht für den Internetdatenverkehr | Netzwerkfilterregeln für andere Protokolle als TCP/UDP funktionieren nicht mit SNAT für Ihre öffentliche IP-Adresse. Nicht-TCP/UDP-Protokolle werden zwischen Spoke-Subnetzen und VNets unterstützt. | Azure Firewall verwendet Standard Load Balancer, das SNAT für IP-Protokolle derzeit nicht unterstützt. Wir prüfen Möglichkeiten, um dieses Szenario in einer zukünftigen Version zu unterstützen. |
| Fehlende PowerShell- und CLI-Unterstützung für ICMP | Azure PowerShell und CLI weisen keine Unterstützung von ICMP als gültiges Protokoll in Netzwerkregeln auf. | Es ist weiterhin möglich, ICMP über das Portal und die REST-API als Protokoll zu verwenden. Wir arbeiten daran, ICMP in Kürze in PowerShell und CLI hinzuzufügen. |
| Für FQDN-Tags muss ein Protokoll/Port festgelegt werden | Für Anwendungsregeln mit FQDN-Tags ist eine „Port: Protokoll“-Definition erforderlich. | Sie können https als port:-Protokollwert verwenden. Wir arbeiten daran, dieses Feld optional zu machen, wenn FQDN-Tags verwendet werden. |
| Das Verlagern einer Firewall in eine andere Ressourcengruppe oder ein anderes Abonnement wird nicht unterstützt | Das Verlagern einer Firewall in eine andere Ressourcengruppe oder ein anderes Abonnement wird nicht unterstützt. | Die Unterstützung dieser Funktionalität ist Teil unserer Roadmap. Um eine Firewall in eine andere Ressourcengruppe oder ein anderes Abonnement zu verschieben, müssen Sie die aktuelle Instanz löschen und in der neuen Ressourcengruppe bzw. im Abonnement neu erstellen. |
| Threat Intelligence-Warnungen sind möglicherweise maskiert. | Netzwerkregeln mit Ziel 80/443 für ausgehende Filterung maskieren Threat Intelligence-Warnungen, wenn diese für den Modus „Alert only“ (Nur Warnen) konfiguriert sind. | Erstellen Sie die ausgehende Filterung für 80/443 mithilfe von Anwendungsregeln. Oder ändern Sie den Threat Intelligence-Modus zu Alert and Deny (Warnen und Verweigern). |
| Azure Firewall-DNAT funktioniert für private IP-Ziele nicht. | Die Azure Firewall-DNAT-Unterstützung ist auf eingehenden/ausgehenden Internetdatenverkehr beschränkt. DNAT funktioniert derzeit nicht für private IP-Ziele. Beispiel: Spoke zu Spoke. | Es wird bereits nach einer Lösung gesucht. Private DNAT befindet sich derzeit in der privaten Vorschau. Sehen Sie sich den Artikel mit den Vorschaufeatures der Azure Firewall für die Ankündigung der öffentlichen Vorschau an. |
| Bei geschützten virtuellen Hubs können Verfügbarkeitszonen nur während der Bereitstellung konfiguriert werden. | Sie können keine Verfügbarkeitszonen konfigurieren, nachdem eine Firewall mit geschützten virtuellen Hubs bereitgestellt wurde. | Dies ist beabsichtigt. |
| SNAT für eingehende Verbindungen | Zusätzlich zu DNAT werden Verbindungen über die öffentliche IP-Adresse der Firewall (eingehend) per SNAT in eine der privaten öffentlichen IP-Adressen übersetzt. Diese Anforderung gilt derzeit (auch für Aktiv/Aktiv-NVAs), um symmetrisches Routing sicherzustellen. | Um die ursprüngliche Quelle für HTTP/S beizubehalten, können Sie XFF-Header verwenden. Verwenden Sie beispielsweise einen Dienst wie Azure Front Door oder Azure Application Gateway vor der Firewall. Sie können auch WAF als Teil von Azure Front Door verwenden und mit der Firewall verketten. |
| SQL-FQDN-Filterung wird nur im Proxymodus unterstützt (Port 1433) | Für Azure SQL-Datenbank, Azure Synapse Analytics und Azure SQL Managed Instance: Die SQL-FQDN-Filterung wird nur im Proxymodus unterstützt (Port 1433). Für Azure SQL-IaaS gilt: Wenn Sie keine Standardports verwenden, können Sie diese Ports in den Anwendungsregeln angeben. |
Für SQL im Umleitungsmodus (die Standardeinstellung beim Herstellen von Verbindungen innerhalb von Azure) können Sie den Zugriff stattdessen mit dem SQL-Diensttag in den Azure Firewall-Netzwerkregeln filtern. |
| Ausgehender SMTP-Datenverkehr an TCP-Port 25 ist blockiert. | Ausgehende E-Mail-Nachrichten, die direkt an externe Domänen (wie outlook.com und gmail.com) auf TCP-Port 25 gesendet werden, können von der Azure-Plattform blockiert werden. Dies ist das Standardverhalten der Plattform in Azure. Azure Firewall führt keine weiteren spezifischen Einschränkung ein. |
Verwenden Sie authentifizierte SMTP-Relaydienste, die in der Regel über TCP-Port 587 eine Verbindung herstellen, aber auch andere Ports unterstützen. Weitere Informationen finden Sie unter Behandeln von Problemen mit ausgehenden SMTP-Verbindungen in Azure. Eine weitere Möglichkeit besteht darin, Azure Firewall in einem EA-Standardabonnement (Enterprise Agreement) bereitzustellen. Azure Firewall in einem EA-Abonnement kann mit öffentlichen IP-Adressen über einen ausgehenden TCP-Port 25 kommunizieren. Derzeit kann es auch in anderen Abonnementtypen funktionieren, aber es ist nicht garantiert, dass es funktioniert. Für private IP-Adressen wie virtuelle Netzwerke, VPNs und Azure ExpressRoute unterstützt Azure Firewall eine ausgehende Verbindung an TCP-Port 25. |
| SNAT-Portauslastung | Azure Firewall unterstützt derzeit 2496 Ports pro öffentlicher IP-Adresse pro Instanz der Back-End-VM-Skalierungsgruppe. Standardmäßig gibt es zwei Instanzen der VM-Skalierungsgruppe. Es gibt also 4.992 Ports pro Flow (Ziel-IP, Zielport und Protokoll (TCP oder UDP). Die Firewall wird auf maximal 20 Instanzen hochskaliert. | Dies ist ein Plattformlimit. Sie können diese Limits umgehen, indem Sie Azure Firewall-Bereitstellungen mit mindestens fünf öffentlichen IP-Adressen für Bereitstellungen konfigurieren, die für SNAT-Auslastung anfällig sind. Dadurch werden die verfügbaren SNAT-Ports um das Fünffache erhöht. Verwenden Sie als Grundlage für die Zuordnung ein IP-Adresspräfix, um Downstreamberechtigungen zu vereinfachen. Für eine dauerhaftere Lösung können Sie ein NAT-Gateway bereitstellen, um die SNAT-Portlimits zu umgehen. Dieser Ansatz wird für virtuelle Netzwerkbereitstellungen unterstützt. Weitere Informationen finden Sie unter Skalieren von SNAT-Ports mit Azure Virtual Network NAT. |
| DNAT wird bei aktivierter Tunnelerzwingung nicht unterstützt. | Mit aktivierter Tunnelerzwingung bereitgestellte Firewalls können aufgrund des asymmetrischen Routings keinen eingehenden Zugriff über das Internet unterstützen. | Dies ist systembedingt und auf das asymmetrische Routing zurückzuführen. Der Rückgabepfad für eingehende Verbindungen verläuft über die lokale Firewall, der noch nicht bekannt ist, dass die Verbindung hergestellt wurde. |
| Abhängig von Ihrer FTP-Serverkonfiguration kann ausgehendes passives FTP für Firewalls mit mehreren öffentlichen IP-Adressen unter Umständen nicht verwendet werden. | Durch passives FTP werden unterschiedliche Verbindungen für Steuerungs- und Datenkanäle hergestellt. Wenn eine Firewall mit mehreren öffentlichen IP-Adressen ausgehende Daten sendet, wird nach dem Zufallsprinzip eine der öffentlichen IP-Adressen als Quell-IP-Adresse ausgewählt. Abhängig von Ihrer FTP-Serverkonfiguration funktioniert FTP möglicherweise nicht, wenn für Daten- und Steuerungskanäle unterschiedliche Quell-IP-Adressen verwendet werden. | Eine explizite SNAT-Konfiguration ist geplant. In der Zwischenzeit können Sie Ihren FTP-Server so konfigurieren, dass er Daten- und Kontrollkanäle von verschiedenen Quell-IP-Adressen akzeptiert (siehe ein Beispiel für IIS). Erwägen Sie in einem solchen Fall alternativ die Verwendung einer einzelnen IP-Adresse. |
| Abhängig von Ihrer FTP-Serverkonfiguration kann eingehendes passives FTP möglicherweise nicht verwendet werden. | Durch passives FTP werden unterschiedliche Verbindungen für Steuerungs- und Datenkanäle hergestellt. Eingehende Verbindungen an Azure Firewall werden per SNAT in eine der privaten Firewall-IP-Adressen übersetzt, um symmetrisches Routing sicherzustellen. Abhängig von Ihrer FTP-Serverkonfiguration funktioniert FTP möglicherweise nicht, wenn für Daten- und Steuerungskanäle unterschiedliche Quell-IP-Adressen verwendet werden. | Die Beibehaltung der ursprünglichen Quell-IP-Adresse wird zurzeit untersucht. In der Zwischenzeit können Sie den FTP-Server so konfigurieren, dass er Daten- und Steuerungskanäle von verschiedenen Quell-IP-Adressen akzeptiert. |
| Aktives FTP funktioniert nicht, wenn der FTP-Client einen FTP-Server über das Internet erreichen muss. | Aktives FTP verwendet einen PORT-Befehl vom FTP-Client, der dem FTP-Server mitteilt, welche IP-Adresse und welcher Port für den Datenkanal verwendet werden soll. Dieser PORT-Befehl verwendet die private IP-Adresse des Clients, die nicht geändert werden kann. Clientseitiger Datenverkehr, der die Azure Firewall durchquert, wird für internetbasierte Kommunikation per NAT übersetzt, sodass der PORT-Befehl vom FTP-Server als ungültig angesehen wird. | Dies ist eine allgemeine Einschränkung von aktivem FTP bei Verwendung von clientseitiger NAT. |
| Für die Metrik „NetworkRuleHit“ fehlt eine Protokolldimension. | Die Metrik „ApplicationRuleHit“ ermöglicht protokollbasiertes Filtern, diese Funktion fehlt jedoch in der entsprechenden Metrik vom Typ „NetworkRuleHit“. | Es wird bereits nach einer Lösung gesucht. |
| NAT-Regeln mit Ports zwischen 64000 und 65535 werden nicht unterstützt. | Azure Firewall lässt beliebige Ports im Bereich 1-65535 in Netzwerk- und Anwendungsregeln zu. NAT-Regeln unterstützen jedoch nur Ports im Bereich 1-63999. | Dies ist eine aktuelle Beschränkung. |
| Konfigurationsaktualisierungen können durchschnittlich fünf Minuten dauern. | Eine Aktualisierung der Azure Firewall-Konfiguration kann durchschnittlich zwischen drei und fünf Minuten dauern, und parallele Aktualisierungen werden nicht unterstützt. | Es wird bereits nach einer Lösung gesucht. |
| Azure Firewall verwendet SNI-TLS-Header zum Filtern von HTTPS- und MSSQL-Datenverkehr. | Wenn die Browser- oder Serversoftware die Erweiterung für die Servernamensanzeige (Server Name Indication, SNI) nicht unterstützt, kann keine Verbindung über Azure Firewall hergestellt werden. | Falls SNI von der Browser- oder Serversoftware nicht unterstützt wird, kann die Verbindung ggf. mithilfe einer Netzwerkregel (anstelle einer Anwendungsregel) gesteuert werden. Eine Liste der Software, die SNI unterstützt, finden Sie unter Server Name Indication. |
| Firewallrichtlinientags können nicht über das Portal oder ARM-Vorlagen (Azure Resource Manager) hinzugefügt werden. | Für die Azure Firewall-Richtlinie gilt eine Patchunterstützungseinschränkung, die verhindert, dass Sie über das Azure-Portal oder ARM-Vorlagen ein Tag hinzufügen können. Der folgende Fehler wird erzeugt: Die Tags für die Ressource konnten nicht gespeichert werden. | Es wird bereits nach einer Lösung gesucht. Alternativ können Sie das Azure PowerShell-Cmdlet Set-AzFirewallPolicy verwenden, um Tags zu aktualisieren. |
| IPv6 wird derzeit nicht unterstützt | Wenn Sie einer Regel eine IPv6-Adresse hinzufügen, tritt ein Firewallfehler auf. | Verwenden Sie nur IPv4-Adressen. Die IPv6-Unterstützung wird geprüft. |
| Das Aktualisieren mehrerer IP-Gruppen schlägt mit einem Konfliktfehler fehl. | Wenn Sie zwei oder mehr IP-Gruppen aktualisieren, die an dieselbe Firewall angefügt sind, wechselt eine der Ressourcen in den Fehlerzustand. | Dies ist ein bekanntes Problem/eine bekannte Einschränkung. Wenn Sie eine IP-Gruppe aktualisieren, wird für alle Firewalls, an die die IP-Gruppe angefügt ist, ein Update ausgelöst. Wenn ein Update zu einer zweiten IP-Gruppe gestartet wird, während sich die Firewall noch im Status Aktualisieren befindet, schlägt die Aktualisierung der IP-Gruppe fehl. Um den Fehler zu vermeiden, müssen IP-Gruppe n, die an dieselbe Firewall angefügt sind, nacheinander aktualisiert werden. Lassen Sie zwischen den Updates genügend Zeit, damit die Firewall den Status Aktualisieren beenden kann. |
| Das Entfernen von RuleCollectionGroup-Elementen mit ARM-Vorlagen wird nicht unterstützt. | Das Entfernen eines RuleCollectionGroup-Elements mittels ARM-Vorlagen wird nicht unterstützt und führt zu einem Fehler. | Dies ist kein unterstützter Vorgang. |
| Wenn die DNAT-Regel allen (*) Datenverkehr zulässt, erfolgt auch eine Quellnetzwerk-Adressübersetzung (Source Network Address Translation, SNAT). | Wenn eine DNAT-Regel alle (*) Quell-IP-Adressen zulässt, stimmt eine implizite Netzwerkregel mit dem VNet-VNet-Datenverkehr überein, sodass immer eine SNAT erfolgt. | Dies ist eine aktuelle Beschränkung. |
| Das Hinzufügen einer DNAT-Regel zu einem geschützten virtuellen Hub mit einem Sicherheitsanbieter wird nicht unterstützt. | Dies führt zu einer asynchronen Route für den an den Sicherheitsanbieter zurückgegebenen DNAT-Datenverkehr. | Wird nicht unterstützt. |
| Fehler, die beim Erstellen von mehr als 2.000 Regelsammlungen auftreten können. | Die maximale Anzahl von Regelsammlungen für NAT/Anwendung oder Netzwerk beträgt 2.000 (Resource Manager-Begrenzung). | Dies ist eine aktuelle Beschränkung. |
| XFF-Kopfzeile in HTTP/S | Die XFF-Header werden mit der ursprünglichen Quell-IP-Adresse überschrieben, wie sie von der Firewall gesehen wird. Dies gilt für die folgenden Anwendungsfälle: - HTTP-Anfragen - HTTPS-Anfragen mit TLS-Abschluss |
Es wird bereits nach einer Lösung gesucht. |
| Die Firewall kann nicht mit Verfügbarkeitszonen mit einer neu erstellten öffentlichen IP-Adresse bereitgestellt werden. | Wenn Sie eine Firewall mit Verfügbarkeitszonen bereitstellen, können Sie keine neu erstellte öffentliche IP-Adresse verwenden. | Erstellen Sie zunächst eine neue zonenredundante öffentliche IP-Adresse, und weisen Sie diese zuvor erstellte IP-Adresse während der Firewallbereitstellung zu. |
| Die private Azure-DNS-Zone wird von Azure Firewall nicht unterstützt | Die private Azure-DNS-Zone funktioniert nicht mit der Azure Firewall, unabhängig von den Azure Firewall-DNS-Einstellungen. | Um den gewünschten Zustand der Verwendung eines privaten DNS-Servers zu erreichen, verwenden Sie den Azure Firewall-DNS-Proxy anstelle einer privaten Azure-DNS-Zone. |
| Physische Zone 2 in Japan, Osten ist für Firewallbereitstellungen nicht verfügbar. | Sie können keine neue Firewall mit physischer Zone 2 bereitstellen. Wenn Sie eine vorhandene Firewall beenden, die in physischer Zone 2 bereitgestellt wird, kann sie nicht neu gestartet werden. Weitere Informationen finden Sie unter Physische und logische Verfügbarkeitszonen. | Stellen Sie für neue Firewalls die verbleibenden Verfügbarkeitszonen bereit, oder verwenden Sie eine andere Region. Informationen zum Konfigurieren einer vorhandenen Firewall finden Sie unter Wie kann ich Verfügbarkeitszonen nach der Bereitstellung konfigurieren?. |
Azure Firewall Premium
Für Azure Firewall Premium sind die folgenden Probleme bekannt:
| Problem | BESCHREIBUNG | Minderung |
|---|---|---|
| ESNI-Unterstützung für FQDN-Auflösung in HTTPS | Verschlüsselte SNI wird im HTTPS-Handshake nicht unterstützt | Derzeit unterstützt nur Firefox ESNI über die benutzerdefinierte Konfiguration. Zur Problemumgehung wird empfohlen, dieses Feature zu deaktivieren. |
| Authentifizierung mit Clientzertifikat wird nicht unterstützt | Clientzertifikate werden verwendet, um ein gegenseitiges Vertrauen hinsichtlich der Identität zwischen dem Client und dem Server aufzubauen. Clientzertifikate werden während einer TLS-Aushandlung verwendet. Die Azure-Firewall handelt eine Verbindung mit dem Server erneut aus und hat keinen Zugriff auf den privaten Schlüssel der Clientzertifikate. | Keine |
| QUIC/HTTP3 | QUIC ist die neue Hauptversion von HTTP. Dabei handelt es sich um ein UDP-basiertes Protokoll über 80 (PLAN) und 443 (SSL). Die FQDN/URL/TLS-Inspektion wird nicht unterstützt. | Konfigurieren Sie die Übergabe von UDP 80/443 als Netzwerkregeln. |
| Nicht vertrauenswürdige, vom Kunden signierte Zertifikate | Vom Kunden signierte Zertifikate werden von der Firewall nicht als vertrauenswürdig eingestuft, sobald sie von einem intranetbasierten Webserver empfangen werden. | Es wird bereits nach einer Lösung gesucht. |
| Falsche Quell-IP-Adresse in Warnungen mit IDPS für HTTP (ohne TLS-Inspektion). | Wenn HTTP-Nur-Text-Datenverkehr verwendet wird und IDPS eine neue Warnung ausgibt und das Ziel eine öffentliche IP-Adresse ist, ist die angezeigte Quell-IP-Adresse falsch (die interne IP-Adresse wird anstelle der ursprünglichen IP-Adresse angezeigt). | Es wird bereits nach einer Lösung gesucht. |
| Zertifikatverteilung | Nachdem ein Zertifizierungsstellenzertifikat auf die Firewall angewendet wurde, kann es zwischen 5-10 Minuten dauern, bis das Zertifikat wirksam wird. | Es wird bereits nach einer Lösung gesucht. |
| Unterstützung für TLS 1.3 | TLS 1.3 wird teilweise unterstützt. Der TLS-Tunnel vom Client zur Firewall basiert auf TLS 1.2 und der von der Firewall zum externen Webserver auf TLS 1.3. | Updates werden derzeit untersucht. |
| Ablauf des TLSi-Zertifikats der Zwischenzertifizierungsstelle | In einigen einzelnen Fällen kann das Zertifikat der Zwischenzertifizierungsstelle zwei Monate vor dem ursprünglichen Ablaufdatum ablaufen. | Erneuern Sie das Zertifikat der Zwischenzertifizierungsstelle zwei Monate vor dem ursprünglichen Ablaufdatum. Es wird bereits nach einer Lösung gesucht. |