Partager via

Problèmes connus et limitations du Pare-feu Azure

Cet article répertorie les problèmes connus liés au Pare-feu Azure et est mis à jour à mesure qu’ils sont résolus.

Pour connaître les limitations du service Pare-feu Azure, voir Abonnement Azure et limites, quotas et contraintes de service.

Important

Contraintes de capacité

Les zones suivantes connaissent actuellement des contraintes de capacité pour les références SKU standard et premium :

Zones Restrictions Recommandation
- Zone physique 2 en Europe Nord
- Zone physique 3 en Asie Sud-Est		 – 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 ?

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 est destinée aux entreprises : elle est donc limitée aux versions Standard et Premium du pare-feu. 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 étudions les possibilités de prendre en charge ce scénario dans une prochaine version.
Lorsqu’un pare-feu Azure est désalloué, puis alloué à nouveau, il peut parfois être affecté à une nouvelle adresse IP privée qui diffère de celle précédente. Après le processus de désallocation et d’application 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 qui est différente de celle précédente, elle provoque des problèmes de routage. Les itinéraires définis par l’utilisateur (UDR) existants configurés avec l’ancienne adresse IP privée doivent être reconfigurés pour refléter 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 configurations de serveur proxy DNS du Pare-feu Azure dans la stratégie parent ne sont pas héritées par les stratégies enfant. Les modifications apportées à la stratégie parent du Pare-feu Azure entraînent des échecs de résolution DNS pour les règles de nom de domaine complet (FQDN) au sein des stratégies enfant liées à la stratégie parent. Pour éviter ce problème, configurez les paramètres du proxy DNS directement sur les stratégies enfant au lieu d’utiliser l’héritage de la stratégie parent. Un correctif est en cours d’examen pour permettre aux stratégies enfants d’hériter des configurations DNS depuis la stratégie parent.
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 actuellement à rendre ce champ facultatif lorsque des 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é figure 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. C'est voulu.
SNAT sur les connexions entrantes Les règles DNAT entrantes nécessitent toujours SNAT pour le trafic retour. Pour conserver la source d’origine pour HTTP/S, configurez les clients ou le proxy (en local ou dans le cloud) pour injecter l’adresse IP d’origine dans les en-têtes XFF . Le Pare-feu Azure conserve toujours les adresses IP dans l’en-tête XFF et ajoute également le cas IP du pare-feu à l’en-tête XFF lors du traitement des règles d’application pour le trafic HTTP et le trafic HTTPS terminé par TLS.
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. Il s’agit du comportement par défaut de la plateforme 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 il n’est 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 existe 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. Il s’agit d’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. Ceci multiplie par cinq le nombre de ports SNAT disponibles. 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. Cette approche est prise 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. Ils ont ce comportement par défaut en raison du routage asymétrique. Le chemin de retour des connexions entrantes passe par le pare-feu local, qui n’a pas vu 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). En guise d’alternative, utilisez une seule adresse IP dans ce cas de figure.
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. Cette commande PORT utilise l’adresse IP privée du client que vous ne pouvez pas changer. 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. Il s’agit d’une limitation générale du FTP actif lorsqu’il est utilisé avec une traduction d’adresses réseau (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. Il s’agit d’une limitation actuelle.
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. Ceci n’est pas une opération prise en charge.
La règle DNAT permettant de tout (*) SNAT le trafic. 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. Il s’agit d’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. Cela se traduit par un itinéraire asynchrone pour le trafic DNAT de retour, qui est dirigé vers le 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). Il s’agit d’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.

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 recommandée consiste à désactiver cette fonctionnalité.
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 Les certificats signés par le client ne sont pas approuvés par le pare-feu lorsqu’ils proviennent d’un serveur web intranet. Un correctif est en cours d’étude.
Adresse IP source erronée dans les alertes avec système IDPS pour HTTP (sans inspection TLS). Lorsque le trafic HTTP en texte brut est utilisé, que le système IDPS émet une nouvelle alerte et que la destination est une adresse IP publique, l’adresse IP source affichée est incorrecte (l’adresse IP interne est affichée à la place de l’adresse IP 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.

Étapes suivantes