Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de changer d’annuaire.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer d’annuaire.
Cet article vous aide à comprendre les problèmes et limitations connus actuels dans le Pare-feu Azure. Nous mettons à jour ces informations à mesure que les problèmes sont résolus. Vérifiez donc régulièrement l’état le plus récent.
Avant de déployer le Pare-feu Azure ou de résoudre les problèmes existants, passez en revue ces problèmes connus pour éviter les problèmes courants et planifier les solutions de contournement appropriées.
Pour connaître les limites du service pare-feu Azure, consultez les limites, quotas et contraintes d’abonnement Azure.
Contraintes de capacité actuelles
Les zones suivantes rencontrent actuellement des contraintes de capacité :
| Région/Zones | Référence (SKU) | Restrictions | Recommandation |
|---|---|---|---|
| Zone physique 1 et zone 4 dans USA Est 2 EUAP | De base, Standard et Premium | - Vous ne pouvez pas déployer un nouveau pare-feu Azure dans la zone 1 et la zone 4. | Nous vous recommandons de déployer un nouveau pare-feu Azure dans les zones de disponibilité restantes ou d’utiliser une autre région. Pour configurer un pare-feu existant, consultez Comment configurer les zones de disponibilité après le déploiement ? |
|
-
Zone physique 2 en Europe Nord - Zone physique 3 en Asie Sud-Est |
Standard et Premium | – Vous ne pouvez pas déployer un nouveau pare-feu Azure dans la zone 3 en Asie du Sud-Est ou dans la zone 2 en Europe du Nord.
– Si vous arrêtez un pare-feu Azure existant qui est déployé dans ces zones, il ne peut pas être redémarré. Pour plus d’informations, consultez Zones de disponibilité physiques et logiques. |
Nous vous recommandons de déployer un nouveau pare-feu Azure dans les zones de disponibilité restantes ou d’utiliser une autre région. Pour configurer un pare-feu existant, consultez Comment configurer les zones de disponibilité après le déploiement ? |
| Zone physique 3 dans la région USA Centre Sud | De base, Standard et Premium | - Vous ne pouvez pas déployer un nouveau pare-feu Azure dans la zone 3.
Date estimée disponible : 31 mars 2026 |
Nous vous recommandons de déployer un nouveau pare-feu Azure dans les zones de disponibilité restantes ou d’utiliser une autre région. Pour configurer un pare-feu existant, consultez Comment configurer les zones de disponibilité après le déploiement ? |
| Zone physique 2 en Espagne Centre | De base, Standard et Premium | - Vous ne pouvez pas déployer un nouveau pare-feu Azure dans la zone 2.
Date estimée disponible : 31 décembre 2026 |
Nous vous recommandons de déployer un nouveau pare-feu Azure dans les zones de disponibilité restantes ou d’utiliser une autre région. Pour configurer un pare-feu existant, consultez Comment configurer les zones de disponibilité après le déploiement ? |
| US Gov Virginie | Premium | - Il n’existe aucune capacité pour la référence SKU Azure Firewall Premium dans US Gov Virginia, les déploiements zonaux et nonzonaux sont bloqués. | Déployez la référence SKU Standard du Pare-feu Azure ou déployez la référence SKU Premium dans une autre région. |
| Zone physique 3 au US Gov Virginie | De base et Standard | - Les déploiements zonaux sont bloqués dans la zone physique 3 à Virginie du gouvernement américain.
- Vous devez sélectionner manuellement les zones disponibles pour le déploiement réussi, en créant une expérience de déploiement non optimale. |
Sélectionnez les zones 1 et 2 pour les déploiements zonaux ou utilisez une autre région. |
| Zone physique 2 dans la région USA Ouest 2 | De base, Standard et Premium | - Vous ne pouvez pas déployer un nouveau pare-feu Azure dans la zone 2. | Nous vous recommandons de déployer un nouveau pare-feu Azure dans les zones de disponibilité restantes ou d’utiliser une autre région. Pour configurer un pare-feu existant, consultez Comment configurer les zones de disponibilité après le déploiement ? |
Avertissement
Si vous arrêtez un déploiement de Pare-feu Azure existant dans l’une de ces régions limitées à la capacité, vous ne pourrez peut-être pas le redémarrer en raison de limitations de capacité en cours. Planifiez en conséquence avant d’arrêter les instances de pare-feu dans ces régions.
Problèmes connus du Pare-feu Azure Standard
Les problèmes connus de Pare-feu Azure Standard sont les suivants :
| Problème | Descriptif | Limitation des risques |
|---|---|---|
| Prise en charge de DNAT pour les adresses IP privées limitée aux versions Standard et Premium | La prise en charge de DNAT sur l’adresse IP privée du Pare-feu Azure n’est disponible que dans les versions standard et premium du pare-feu, et non dans la version de base. | Aucune |
| Le processus de désallocation et d’allocation du Pare-feu Azure n’est pas pris en charge lorsque les règles DNAT IP privées sont configurées | Le processus d’allocation du pare-feu Azure échoue lorsque les règles DNAT privées sont configurées | 1. Libérer le Pare-feu Azure 2. Supprimez toutes les règles DNAT IP privées 3. Allouez le Pare-feu Azure et attendez que l’adresse IP privée soit remplie 4. Reconfigurer les règles DNAT d’adresse IP privée avec l’adresse IP privée appropriée |
| Les règles de filtrage réseau pour les protocoles autres que TCP/UDP (par exemple ICMP) ne fonctionnent pas pour le trafic lié à Internet. | Les règles de filtrage réseau des protocoles autres que TCP/UDP ne fonctionnent pas avec SNAT pour votre adresse IP publique. Les protocoles non-TCP/UDP sont pris en charge entre les sous-réseaux spokes et les VNets. | Le service Pare-feu Azure utilise Standard Load Balancer, qui ne prend pas en charge SNAT pour les protocoles IP pour le moment. Nous explorons les options permettant de prendre en charge les protocoles non TCP/UDP pour le trafic lié à Internet dans une prochaine version. |
| Lorsqu’un pare-feu Azure est désalloué, puis alloué à nouveau, il peut être affecté à une nouvelle adresse IP privée | Après le processus de désallocation et d’allocation du Pare-feu Azure, une adresse IP privée est affectée dynamiquement depuis le sous-réseau du Pare-feu Azure. Lorsqu’une nouvelle adresse IP privée est affectée différente de celle précédente, elle provoque des problèmes de routage. | Vous devez reconfigurer les itinéraires définis par l’utilisateur (UDR) existants avec la nouvelle adresse IP privée. Un correctif est en cours d’examen pour conserver l’adresse IP privée après le processus d’allocation. |
| Les stratégies de pare-feu enfant n’héritent pas des paramètres DNS des stratégies parentes. | Lorsque vous modifiez les paramètres DNS dans une stratégie de pare-feu parente, les stratégies enfant qui y sont liées peuvent échouer à résoudre les noms de domaine dans leurs règles. | Configurez les paramètres DNS directement sur chaque stratégie enfant au lieu de vous appuyer sur la stratégie parente. Nous travaillons sur un correctif pour autoriser l’héritage des paramètres DNS. |
| Absence de support ICMP dans PowerShell et CLI | Azure PowerShell et l’interface CLI ne prennent pas en charge le protocole ICMP en tant que protocole valide dans les règles de réseau. | Il est toujours possible d’utiliser le protocole ICMP par le biais du portail et de l’API REST. Nous travaillons actuellement à ajouter à PowerShell et à l’interface de ligne de commande la prise en charge du protocole ICMP. |
| Les balises FQDN requièrent qu'un protocole et un port soient spécifiés | Les règles d’application avec des balises FQDN requièrent une définition port : protocole. | Vous pouvez utiliser https en tant que valeur port : protocole. Nous travaillons à rendre le port : champ de protocole facultatif lorsque les balises FQDN sont utilisées. |
| Le déplacement d’un pare-feu vers un autre groupe de ressources ou un autre abonnement n’est pas pris en charge | Le déplacement d’un pare-feu vers un autre groupe de ressources ou un autre abonnement n’est pas pris en charge. | La prise en charge de cette fonctionnalité est sur notre feuille de route. Pour déplacer un pare-feu vers un autre groupe de ressources ou un autre abonnement, vous devez supprimer l’instance actuelle et la recréer dans le nouveau groupe de ressources ou le nouvel abonnement. |
| Les alertes liées aux renseignements sur les menaces pourraient être masquées | Les règles de réseau ayant pour destination 80/443 pour le filtrage sortant masquent les alertes de renseignement sur les menaces lorsqu'elles sont configurées uniquement en mode alerte. | Créez un filtrage sortant pour 80/443 à l’aide de règles d’application. Ou modifiez le mode d’intelligence contre les menaces pour alerter et rejeter. |
| Avec des hubs virtuels sécurisés, les zones de disponibilité ne peuvent être configurées que pendant le déploiement. | Vous ne pouvez pas configurer des zones de disponibilité après le déploiement d’un pare-feu avec des hubs virtuels sécurisés. | Par conception. |
| SNAT sur les connexions entrantes | Les règles DNAT entrantes modifient toujours l’adresse IP source pour le trafic de retour. | Pour suivre l’adresse IP du client d’origine pour le trafic web, configurez vos clients ou serveurs proxy pour inclure l’adresse IP d’origine dans les en-têtes XFF . Le Pare-feu Azure conserve ces adresses IP dans l’en-tête XFF et ajoute l’adresse IP du pare-feu à l’en-tête XFF lors du traitement des règles de trafic web. |
| Prise en charge du filtrage FQDN SQL uniquement en mode proxy (port 1433) | Pour Azure SQL Database, Azure Synapse Analytics et Azure SQL Managed Instance : Le filtrage FQDN SQL est pris en charge uniquement en mode proxy (port 1433). Pour Azure SQL IaaS : Si vous utilisez des ports non standard, vous pouvez spécifier ces ports dans les règles d'application. |
Pour SQL en mode de redirection (l’option par défaut si vous vous connectez à partir d’Azure), vous pouvez à la place filtrer l’accès par le biais de l’étiquette du service SQL, dans le cadre des règles de réseau du Pare-feu Azure. |
| Le trafic SMTP sortant sur le port TCP 25 est bloqué | La plateforme Azure bloque les messages électroniques sortants envoyés directement aux domaines externes (comme outlook.com et gmail.com) sur le port TCP 25. Le blocage du trafic SMTP sortant sur le port 25 est le comportement de plateforme par défaut dans Azure. Le Pare-feu Azure n’introduit aucune restriction plus spécifique. |
Utilisez des services de relais SMTP authentifiés, qui se connectent généralement via le port TCP 587, mais prennent également en charge d’autres ports. Pour plus d’informations, consultez Résoudre les problèmes de connectivité SMTP sortante dans Azure. Une autre option consiste à déployer le Pare-feu Azure dans un abonnement Contrat Entreprise (EA) standard. Le Pare-feu Azure dans un abonnement EA peut communiquer avec des adresses IP publiques en utilisant le port TCP 25 sortant. Il peut fonctionner dans d’autres types d’abonnement, mais pas garanti. Pour les adresses IP privées, telles que les réseaux virtuels, les réseaux privés virtuels et Azure ExpressRoute, le Pare-feu Azure prend en charge une connexion sortante sur le port TCP 25. |
| Insuffisance de ports SNAT | Actuellement, le Pare-feu Azure prend en charge 2 496 ports par adresse IP publique par instance de groupe de machines virtuelles identiques back-end. Par défaut, il y a deux instances d'ensemble de machines virtuelles. Il y a donc 4 992 ports par flux (adresse IP de destination, port de destination et protocole (TCP ou UDP). Le pare-feu peut évoluer jusqu’à 20 instances maximum. | L’épuisement des ports SNAT est une limitation de plateforme. Vous pouvez contourner les limites en configurant les déploiements de Pare-feu Azure avec un minimum de cinq adresses IP publiques pour les déploiements sujets à une insuffisance de ports SNAT. L’ajout d’adresses IP publiques augmente les ports SNAT disponibles de cinq fois. Effectuez l’allocation à partir d’un préfixe d’adresse IP pour simplifier les autorisations en aval. Pour une solution plus permanente, vous pouvez déployer une passerelle NAT pour surmonter les limites du port SNAT. Le déploiement de passerelle NAT est pris en charge pour les déploiements de réseaux virtuels. Pour plus d’informations, consultez Mettre à l’échelle les ports SNAT avec la table NAT de réseau virtuel Azure. |
| DNAT n’est pas pris en charge avec l’option Tunnelisation forcée activée | Les pare-feu déployés, dont l’option Tunneling forcé est activée, ne peuvent pas prendre en charge l’accès entrant depuis Internet compte tenu du routage asymétrique. | L'absence de prise en charge de DNAT avec le tunneling forcé est délibérée en raison du routage asymétrique. Le chemin d’accès de retour pour les connexions entrantes passe par le pare-feu local, qui ne voit pas la connexion établie. |
| Le FTP passif sortant est susceptible de ne pas fonctionner pour les pare-feu ayant plusieurs adresses IP publiques, selon la configuration de votre serveur FTP. | Le mode FTP passif établit des connexions différentes pour les canaux de contrôle et ceux de données. Lorsqu’un pare-feu disposant de plusieurs adresses IP publiques envoie des données sortantes, il sélectionne de manière aléatoire une de ses adresses IP publiques comme adresse IP source. FTP peut échouer quand les canaux de données et de contrôle utilisent des adresses IP sources différentes, selon la configuration de votre serveur FTP. | Une configuration SNAT explicite est prévue. En attendant, vous pouvez configurer votre serveur FTP pour accepter des canaux de données et de contrôle à partir d’adresses IP sources différentes (consultez cet exemple pour IIS). Vous pouvez également envisager d’utiliser une adresse IP unique lorsque vous rencontrez des problèmes de connectivité FTP. |
| Le FTP passif entrant est susceptible de ne pas fonctionner, selon la configuration de votre serveur FTP. | Le mode FTP passif établit des connexions différentes pour les canaux de contrôle et ceux de données. Les connexions entrantes sur le Pare-feu Azure font l’objet d’une traduction SNAT en une des adresses IP privées du pare-feu afin de garantir un routage symétrique. FTP peut échouer quand les canaux de données et de contrôle utilisent des adresses IP sources différentes, selon la configuration de votre serveur FTP. | La conservation de l’adresse IP source d’origine est en cours d’examen. En attendant, vous pouvez configurer votre serveur FTP pour accepter des canaux de données et de contrôle à partir d’adresses IP sources différentes. |
| Active FTP ne fonctionne pas lorsque le client FTP doit atteindre un serveur FTP via Internet. | Le FTP actif utilise une commande PORT du client FTP qui indique au serveur FTP l’IP et le port à utiliser pour le canal de données. La commande PORT utilise l’adresse IP privée du client qui ne peut pas être modifiée. Le trafic côté client traversant le pare-feu Azure est NAT pour les communications basées sur Internet, ce qui rend la commande PORT considérée comme non valide par le serveur FTP. | L’échec du FTP Actif est une limitation générale du Protocole FTP Actif lorsqu’il est utilisé avec NAT côté client. |
| Il manque une dimension de protocole à la métrique NetworkRuleHit | La métrique ApplicationRuleHit autorise le protocole basé sur le filtrage, mais cette fonctionnalité est absente de la métrique NetworkRuleHit correspondante. | Un correctif est en cours d’étude. |
| Les règles NAT avec des ports entre 64000 et 65535 ne sont pas prises en charge | Le Pare-feu Azure autorise tous les ports de la plage 1-65535 dans les règles de réseau et d’application. Toutefois, les règles NAT prennent uniquement en charge les ports de la plage 1-63999. | La restriction sur les ports de règle NAT est une des limitations actuelles. |
| Les mises à jour de la configuration peuvent prendre en moyenne 5 minutes. | Une mise à jour de configuration du Pare-feu Azure peut prendre trois à cinq minutes en moyenne ; les mises à jour parallèles ne sont pas prises en charge. | Un correctif est en cours d’étude. |
| Le pare-feu Azure utilise des en-têtes SNI TLS pour filtrer le trafic HTTPS et MSSQL | Si le logiciel du navigateur ou du serveur ne prend pas en charge l’extension SNI, vous ne pouvez pas vous connecter via le Pare-feu Azure. | Si le navigateur ou le logiciel du serveur ne prend pas en charge SNI, il est possible de contrôler la connexion en utilisant une règle de réseau au lieu d’une règle d’application. Consultez Indication du nom du serveur (SNI) pour découvrir les logiciels qui prennent en charge SNI. |
| Impossible d’ajouter des étiquettes de stratégie de pare-feu à l’aide du portail ou des modèles Azure Resource Manager (ARM) | La stratégie de pare-feu Azure a une limitation du support des correctifs qui ne permet pas d’ajouter des balises à l’aide du portail Azure ou des modèles ARM. L’erreur suivante est générée : Nous n’avons pas pu enregistrer les étiquettes de la ressource. | Un correctif est en cours d’étude. Vous pouvez aussi utiliser l’applet de commande Azure PowerShell Set-AzFirewallPolicy pour mettre à jour les balises. |
| IPv6 n’est pas pris en charge actuellement | Si vous ajoutez une adresse IPv6 à une règle, le pare-feu échoue. | Utilisez uniquement des adresses IPv4. La prise en charge d’IPv6 est en cours d’examen. |
| La suppression de RuleCollectionGroups à l’aide de modèles ARM n’est pas prise en charge. | La suppression d’un RuleCollectionGroup à l’aide de modèles ARM n’est pas prise en charge et entraîne un échec. | La suppression de RuleCollectionGroups à l’aide de modèles ARM n’est pas une opération prise en charge. |
| La règle DNAT permettant de tout (*) autoriser renvoie le trafic SNAT. | Si une règle DNAT autorise tout (*) en tant qu’adresse IP source, une règle de réseau implicite met en correspondance le trafic VNet-VNet, puis soumet systématiquement le trafic à cette règle SNAT. | Le comportement SNAT automatique pour les règles DNAT avec n’importe quelle source est une limitation actuelle. |
| L’ajout d’une règle DNAT à un hub virtuel sécurisé à l’aide d’un fournisseur de sécurité n’est pas pris en charge. | Lorsque vous ajoutez une règle DNAT à un hub virtuel sécurisé avec un fournisseur de sécurité, il génère un itinéraire asynchrone pour le trafic DNAT retourné, qui va au fournisseur de sécurité. | Non pris en charge. |
| Une erreur s’est produite lors de la création de plus de 2 000 collections de règles. | Le nombre maximal de collections de règles NAT/Application ou Réseau est de 2000 (limite de Resource Manager). | La limite de collecte de règles de 2 000 est une limitation actuelle. |
| Impossible de déployer un pare-feu avec des zones de disponibilité avec une adresse IP publique nouvellement créée | Quand vous déployez un pare-feu avec des zones de disponibilité, vous ne pouvez pas utiliser une adresse IP publique nouvellement créée. | Commencez par créer une nouvelle adresse IP publique redondante dans une zone, puis affectez cette adresse IP créée précédemment lors du déploiement du pare-feu. |
| L’association d’une adresse IP publique au Pare-feu Azure n’est pas prise en charge dans un scénario interlocataire. | Si vous créez une adresse IP publique dans le locataire A, vous ne pouvez pas l’associer à un pare-feu déployé dans le locataire B. | Aucun. |
| Les machines virtuelles derrière le Pare-feu Azure ne peuvent pas se connecter aux destinations de règle DNAT à l’aide de l’adresse IP publique du pare-feu | Lorsque les machines virtuelles acheminent le trafic via le Pare-feu Azure et tentent de se connecter aux ressources configurées avec des règles DNAT à l’aide de l’adresse IP publique du pare-feu, la connexion échoue. L’échec de connexion se produit parce que le Pare-feu Azure ne permet pas d'acheminer le trafic des machines virtuelles internes vers son adresse IP publique pour les destinations des règles DNAT. | Une solution pour cette limitation est actuellement en cours de développement. |
Problèmes connus liés au Pare-feu Azure Premium
Remarque
Tout problème qui s’applique à Standard s’applique également à Premium.
Les problèmes connus du Pare-feu Azure Premium sont les suivants :
| Problème | Descriptif | Limitation des risques |
|---|---|---|
| Prise en charge ESNI pour la résolution FQDN dans HTTPS | Le chiffrement SNI n’est pas pris en charge dans l’établissement d'une liaison HTTPS. | Aujourd’hui, seul Firefox prend en charge ESNI via une configuration personnalisée. La solution de contournement suggérée consiste à désactiver la fonctionnalité ESNI. |
| L’authentification de la certification du client n’est pas prise en charge | Les certificats clients sont utilisés pour créer une approbation d’identité mutuelle entre le client et le serveur. Les certificats clients sont utilisés lors d’une négociation TLS. Le Pare-feu Azure renégocie une connexion avec le serveur et n’a pas accès à la clé privée des certificats clients. | Aucune |
| QUIC/HTTP3 | QUIC est la nouvelle version majeure de HTTP. Il s’agit d’un protocole basé sur UDP sur 80 (PLAN) et 443 (SSL). L’inspection FQDN/URL/TLS n’est pas prise en charge. | Configurez le passage UDP 80/443 en tant que règles de réseau. |
| Certificats signés par le client non approuvés | Le pare-feu ne fait pas confiance aux certificats signés par le client lorsqu’il les reçoit d’un serveur web basé sur intranet. | Un correctif est en cours d’étude. |
| IDPS affiche une adresse IP source incorrecte pour les alertes HTTP sans inspection TLS | Quand IDPS génère des alertes pour le trafic HTTP en texte brut vers des adresses IP publiques, elle affiche l’adresse IP interne au lieu de l’adresse IP source d’origine. | Un correctif est en cours d’étude. |
| Propagation du certificat | Après l'application d'un certificat CA sur le pare-feu, le certificat peut prendre de 5 à 10 minutes pour être pris en compte. | Un correctif est en cours d’étude. |
| Prise en charge du protocole TLS 1.3 | Le protocole TLS 1.3 est partiellement pris en charge. Le tunnel TLS entre le client et le pare-feu est basé sur le protocole TLS 1.2, et celui entre le pare-feu et le serveur web externe est basé sur le protocole TLS 1.3. | Des mises à jour sont à l’étude. |
| Expiration du certificat d’autorité de certification intermédiaire TLSi | Dans de rares cas, le certificat d’autorité de certification intermédiaire peut expirer deux mois avant la date d’expiration d’origine. | Renouvelez le certificat d’autorité de certification intermédiaire deux mois avant la date d’expiration d’origine. Un correctif est en cours d’étude. |