Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieser Artikel hilft Ihnen, die aktuellen bekannten Probleme und Einschränkungen in azure Firewall zu verstehen. Wir aktualisieren diese Informationen, da Probleme behoben werden. Überprüfen Sie daher regelmäßig nach dem neuesten Status.
Bevor Sie Azure Firewall bereitstellen oder vorhandene Bereitstellungen behandeln, überprüfen Sie diese bekannten Probleme, um häufige Probleme zu vermeiden und geeignete Problemumgehungen zu planen.
Informationen zu Azure Firewall-Dienstbeschränkungen finden Sie unter Azure-Abonnement- und Dienstbeschränkungen, Kontingente und Einschränkungen.
Aktuelle Kapazitätsbeschränkungen
Die folgenden Zonen weisen derzeit Kapazitätsbeschränkungen auf:
| Region/Zonen | Artikelnummer (SKU) | Beschränkungen | Empfehlung |
|---|---|---|---|
| Physische Zone 1 und Zone 4 in Ost-US 2 EUAP | Basic, Standard und Premium | – Sie können keine neue Azure Firewall in Zone 1 und Zone 4 bereitstellen. | Es wird empfohlen, eine neue Azure Firewall in den verbleibenden Verfügbarkeitszonen bereitzustellen oder eine andere Region zu verwenden. Informationen zum Konfigurieren einer vorhandenen Firewall finden Sie unter Wie kann ich Verfügbarkeitszonen nach der Bereitstellung konfigurieren? |
|
-
Physische Zone 2 in Nordeuropa - Physische Zone 3 in Asien, Südosten |
Standard und Premium | – Sie können keine neue Azure Firewall in Zone 3 in Asien, Südosten oder Zone 2 in Nordeuropa bereitstellen.
– Wenn Sie eine vorhandene Azure Firewall beenden, die in dieser Zone bereitgestellt wird, kann sie nicht neu gestartet werden. Weitere Informationen finden Sie unter Physische und logische Verfügbarkeitszonen. |
Es wird empfohlen, eine neue Azure Firewall in den verbleibenden Verfügbarkeitszonen bereitzustellen oder eine andere Region zu verwenden. Informationen zum Konfigurieren einer vorhandenen Firewall finden Sie unter Wie kann ich Verfügbarkeitszonen nach der Bereitstellung konfigurieren? |
| Physische Zone 3 in Süd-Zentral-USA | Basic, Standard und Premium | – Sie können keine neue Azure Firewall in Zone 3 bereitstellen.
Geschätztes Datum verfügbar: 31. März 2026 |
Es wird empfohlen, eine neue Azure Firewall in den verbleibenden Verfügbarkeitszonen bereitzustellen oder eine andere Region zu verwenden. Informationen zum Konfigurieren einer vorhandenen Firewall finden Sie unter Wie kann ich Verfügbarkeitszonen nach der Bereitstellung konfigurieren? |
| Physische Zone 2 in Spanien Zentral | Basic, Standard und Premium | – Sie können keine neue Azure-Firewall in Zone 2 bereitstellen.
Geschätztes Datum verfügbar: 31. Dezember 2026 |
Es wird empfohlen, eine neue Azure Firewall in den verbleibenden Verfügbarkeitszonen bereitzustellen oder eine andere Region zu verwenden. Informationen zum Konfigurieren einer vorhandenen Firewall finden Sie unter Wie kann ich Verfügbarkeitszonen nach der Bereitstellung konfigurieren? |
| US-Regierung Virginia | Premium | – Es gibt keine Kapazität für die Azure Firewall Premium-SKU in US Gov Virginia, sowohl zonale als auch nicht-zonale Bereitstellungen sind gesperrt. | Stellen Sie die Azure Firewall Standard-SKU bereit, oder stellen Sie Premium-SKU in einer anderen Region bereit. |
| Physische Zone 3 in US Gov Virginia | Basic und Standard. | - Zonal-Bereitstellungen werden in der physischen Zone 3 in US Gov Virginia blockiert.
– Sie müssen die verfügbaren Zonen manuell auswählen, um eine erfolgreiche Bereitstellung zu gewährleisten, was zu einer suboptimalen Bereitstellungserfahrung führt. |
Wählen Sie die Zonen 1 und 2 für Zonenbereitstellungen aus, oder verwenden Sie eine andere Region. |
| Physische Zone 2 in West-US 2 | Basic, Standard und Premium | – Sie können keine neue Azure-Firewall in Zone 2 bereitstellen. | Es wird empfohlen, eine neue Azure Firewall in den verbleibenden Verfügbarkeitszonen bereitzustellen oder eine andere Region zu verwenden. Informationen zum Konfigurieren einer vorhandenen Firewall finden Sie unter Wie kann ich Verfügbarkeitszonen nach der Bereitstellung konfigurieren? |
Warnung
Wenn Sie eine vorhandene Azure Firewall-Bereitstellung in einer dieser kapazitätsbeschränkten Regionen beenden, können Sie sie möglicherweise aufgrund laufender Kapazitätsbeschränkungen nicht erneut starten. Planen Sie entsprechend, bevor Sie Firewallinstanzen in diesen Regionen beenden.
Bekannte Probleme mit Azure Firewall Standard
Für Azure Firewall Standard sind die folgenden Probleme bekannt:
| Problem | BESCHREIBUNG | Minderung |
|---|---|---|
| Die DNAT-Unterstützung für private IP-Adressen ist auf die Standard- und Premium-Versionen beschränkt. | Die Unterstützung für DNAT auf der privaten IP-Adresse von Azure Firewall ist nur in den Versionen Standard und Premium Firewall verfügbar, nicht in der Basic-Version. | Keine |
| Vorgang der Zuweisung und Freigabe für Azure Firewall wird nicht unterstützt, wenn private IP-DNAT-Regeln konfiguriert sind | Der Azure Firewall-Zuordnungsprozess schlägt fehl, wenn private DNAT-Regeln konfiguriert sind. | 1. Aufheben der Azure Firewall-Zuordnung 2. Löschen Sie alle privaten IP DNAT-Regeln 3. Weisen Sie der Azure-Firewall Ressourcen zu, und warten Sie, bis die private IP-Adresse zugewiesen wird 4. Neukonfigurieren der privaten IP-DNAT-Regeln mit der entsprechenden privaten IP-Adresse |
| 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 untersuchen Optionen zur Unterstützung von Nicht-TCP/UDP-Protokollen für internetgebundenen Datenverkehr in einer zukünftigen Version. |
| Wenn eine Azure Firewall freigegeben und dann erneut zugeordnet wird, kann ihr möglicherweise eine neue private IP-Adresse zugewiesen werden. | Nach dem Deallocation- und Zuordnungsprozess der Azure-Firewall wird eine private IP-Adresse dynamisch aus dem Azure Firewall-Subnetz zugewiesen. Wenn eine neue private IP-Adresse zugewiesen wird, die sich von der vorherigen unterscheidet, verursacht sie Routingprobleme. | Sie müssen die vorhandenen benutzerdefinierten Routen (User Defined Routes, UDRs) mit der neuen privaten IP-Adresse neu konfigurieren. Ein Fix wird untersucht, um die private IP-Adresse nach dem Zuordnungsprozess beizubehalten. |
| Untergeordnete Firewallrichtlinien erben keine DNS-Einstellungen von übergeordneten Richtlinien. | Wenn Sie DNS-Einstellungen in einer übergeordneten Firewallrichtlinie ändern, können untergeordnete Richtlinien, die damit verknüpft sind, domänennamen in ihren Regeln möglicherweise nicht auflösen. | Konfigurieren Sie DNS-Einstellungen direkt für jede Kind-Richtlinie, anstatt sich auf die Eltern-Richtlinie zu verlassen. Wir arbeiten an einem Fix, um die Vererbung von DNS-Einstellungen zuzulassen. |
| 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, das Port-Protokollfeld 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 liegt in 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). |
| 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. | Absichtlich. |
| SNAT für eingehende Verbindungen | Eingehende DNAT-Regeln ändern immer die IP-Quelladresse für den Rückverkehr. | Um die ursprüngliche Client-IP für Den Webdatenverkehr nachzuverfolgen, konfigurieren Sie Ihre Clients oder Proxyserver so, dass sie die ursprüngliche IP in XFF-Header einschließen. Azure Firewall behält diese IP-Adressen im XFF-Header bei und fügt die Firewall-IP zum XFF-Header hinzu, wenn Webdatenverkehrsregeln verarbeitet werden. |
| 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. | Die Azure-Plattform blockiert ausgehende E-Mails, die direkt an externe Domänen (wie outlook.com und gmail.com) über TCP-Port 25 gesendet werden. Das Blockieren ausgehender SMTP-Datenverkehr an Port 25 ist das Standardplattformverhalten in Azure. Azure Firewall führt keine spezifischere 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. Es funktioniert möglicherweise in anderen Abonnementtypen, aber nicht garantiert. 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 2.496 Ports pro öffentlicher IP-Adresse und Back-End-VM-Skalierungsgruppeninstanz. Standardmäßig gibt es zwei Instanzen von Virtual Machine Scale Sets. Es gibt also 4.992 Ports pro Flow (Ziel-IP-Adresse, Zielport und Protokoll (TCP oder UDP)). Die Firewall wird auf maximal 20 Instanzen hochskaliert. | Die SNAT-Portausschöpfung ist eine Plattformeinschränkung. 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. Durch das Hinzufügen weiterer öffentlicher IP-Adressen werden die SNAT-Ports um fünfmal 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. Die NAT-Gatewaybereitstellung 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. | Der Mangel an DNAT-Unterstützung bei erzwungener Tunnelung ist aufgrund asymmetrischer Routings beabsichtigt. Der Rückgabepfad für eingehende Verbindungen durchläuft die lokale Firewall, wodurch die Verbindung nicht hergestellt wird. |
| 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). Alternativ können Sie bei Problemen mit der FTP-Konnektivität eine einzelne IP-Adresse verwenden. |
| 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. Der PORT-Befehl verwendet die private IP 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. | Fehler bei aktivem FTP ist eine allgemeine Einschränkung von aktivem FTP, wenn es mit clientseitigem NAT verwendet wird. |
| 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. | Die Einschränkung für NAT-Regelports ist eine aktuelle Einschrä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. |
| Firewall-Richtlinien-Tags können nicht über das Portal oder Azure Resource Manager (ARM)-Vorlagen 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 Entfernen von RuleCollectionGroups 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. | Das Entfernen von RuleCollectionGroups mithilfe von ARM-Vorlagen 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 any (*) als Quell-IP-Adresse zulässt, wird eine implizite Netzwerkregel den VNet-VNet-Datenverkehr abgleichen und immer SNAT auf den Datenverkehr anwenden. | Das automatische SNAT-Verhalten für DNAT-Regeln mit beliebiger Quelle ist eine bestehende Einschränkung. |
| Das Hinzufügen einer DNAT-Regel zu einem geschützten virtuellen Hub mit einem Sicherheitsanbieter wird nicht unterstützt. | Wenn Sie einem gesicherten virtuellen Hub mit einem Sicherheitsanbieter eine DNAT-Regel hinzufügen, führt sie zu einer asynchronen Route für den zurückgegebenen DNAT-Datenverkehr, der an den Sicherheitsanbieter weitergeleitet 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). | Das Limit von 2.000 Regelsammlungen ist eine aktuelle Einschränkung. |
| 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. |
| Das Zuordnen einer öffentlichen IP-Adresse zu Azure Firewall wird in einem mandantenübergreifenden Szenario nicht unterstützt. | Wenn Sie eine öffentliche IP-Adresse im Mandanten A erstellen, können Sie sie keiner Firewall zuordnen, die in Mandanten B bereitgestellt wird. | Keiner. |
| VMs hinter Azure Firewall können keine Verbindung mit DNAT-Regelzielen herstellen, indem die öffentliche IP-Adresse der Firewall verwendet wird | Wenn VMs Datenverkehr über die Azure Firewall weiterleiten und versuchen, mithilfe der öffentlichen IP-Adresse der Firewall eine Verbindung mit Ressourcen herzustellen, die mit DNAT-Regeln konfiguriert sind, schlägt die Verbindung fehl. Der Verbindungsausfall tritt auf, weil die Azure-Firewall keinen Hairpinning-Datenverkehr von internen VMs an die eigene öffentliche IP-Adresse der Firewall für Ziele von DNAT-Regeln unterstützt. | Eine Lösung für diese Einschränkung befindet sich derzeit in der Entwicklung. |
Bekannte Probleme mit Azure Firewall Premium
Hinweis
Alle Probleme, die für „Standard“ gelten, treffen auch auf „Premium“ zu.
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. Vorgeschlagene Problemumgehung besteht darin, das ESNI-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 Überprüfung von FQDN/URL/TLS wird nicht unterstützt. | Konfigurieren Sie die Übergabe von UDP 80/443 als Netzwerkregeln. |
| Nicht vertrauenswürdige, vom Kunden signierte Zertifikate | Die Firewall vertraut kundensignierten Zertifikaten nicht, wenn sie von einem intranetbasierten Webserver empfangen werden. | Es wird bereits nach einer Lösung gesucht. |
| IDPS zeigt falsche Quell-IP-Adresse für HTTP-Warnungen ohne TLS-Inspektion an. | Wenn IDPS Warnungen für Nur-Text-HTTP-Datenverkehr zu öffentlichen IP-Adressen generiert, wird die interne IP-Adresse anstelle der ursprünglichen Quell-IP-Adresse angezeigt. | Es wird bereits nach einer Lösung gesucht. |
| Zertifikatverteilung | Nachdem ein Zertifizierungsstellenzertifikat auf die Firewall angewendet wurde, kann es zwischen 5 bis 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. | Aktualisierungen 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. |