Problèmes connus et limitations du Pare-feu Azure
Cet article répertorie les problèmes connus liés au Pare-feu Azure. Il est mis à jour au fur et à mesure que les problèmes sont résolus.
Pour connaître les limitations du service Pare-feu Azure, voir Abonnement Azure et limites, quotas et contraintes de service.
Pare-feu Azure Standard
Les problèmes connus de Pare-feu Azure Standard sont les suivants :
Notes
Tout problème qui s’applique à Standard s’applique également à Premium.
| Problème | Description | Limitation des risques |
|---|---|---|
| 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 autres que TCP/UDP sont pris en charge entre les sous-réseaux du rayon et les réseaux virtuels. | 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. |
| Protocole ICMP non pris en charge par PowerShell et l’interface de ligne de commande | 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 une définition protocole : port | 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 Threat intelligence peuvent être masquées | Les règles de réseau avec la destination 80/443 pour le filtrage sortant masque les alertes intelligentes de menaces lorsqu’elles sont configurées pour en mode alerte uniquement. | 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. |
| La fonction DNAT du Pare-feu Azure ne fonctionne pas pour les destinations IP privées | La prise en charge de la fonction DNAT du Pare-feu Azure est limitée aux sorties/entrées Internet. Actuellement, DNAT ne fonctionne pas pour les destinations IP privées. Par exemple, spoke-à-spoke. | Un correctif est en cours d’étude. La technique de DNAT (Destination Network Address Translation) privée est actuellement en préversion privée. Parcourez l’article Fonctionnalités du Pare-feu Azure en préversion pour l’annonce de préversion publique. |
| 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 les zones de disponibilité après le déploiement d’un pare-feu avec des hubs virtuels sécurisés. | C'est la procédure normale. |
| SNAT sur les connexions entrantes | En plus de DNAT, les connexions via l’adresse IP publique du pare-feu (entrante) sont traduites vers l’une des adresses IP privées du pare-feu. Cette exigence actuelle (également pour les appliances virtuelles réseau Active/Active) permet d’assurer la symétrie du routage. | Pour préserver la source originale pour HTTP/S, pensez à utiliser les en-têtes XFF. Par exemple, utilisez un service tel que Azure Front Door ou Azure Application Gateway devant le pare-feu. Vous pouvez également ajouter le pare-feu d’applications web en tant qu’Azure Front Door et l’associer au pare-feu. |
| 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é | Les e-mails sortants envoyés directement à des domaines externes (comme outlook.com et gmail.com) sur le port TCP 25 peuvent être bloqués par la plateforme Azure. Il s’agit du comportement par défaut de la plateforme dans Azure. Le Pare-feu Azure n’introduit aucune autre restriction 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 Pare-feu Azure dans un abonnement Contrat Entreprise (EA) standard. Pare-feu Azure dans un abonnement EA peut communiquer avec des adresses IP publiques en utilisant un port TCP 25 sortant. Actuellement, il peut également fonctionner dans d’autres types d’abonnement, mais son fonctionnement 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 du port TCP 25. |
| Insuffisance de ports SNAT | Actuellement, Pare-feu Azure prend en charge 2496 ports par adresse IP publique par instance de groupe de machines virtuelles identiques back-end. Par défaut, il existe deux instances de groupe de machines virtuelles identiques. Il existe donc 4992 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 Tunneling forcé 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 ; cela dépend de 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 lorsque les canaux de données et de contrôle utilisent des adresses IP sources différentes ; cela dépend de 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 ; cela dépend de 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 lorsque les canaux de données et de contrôle utilisent des adresses IP sources différentes ; cela dépend de 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 configuration peuvent prendre cinq minutes en moyenne | 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 logiciel du navigateur ou du serveur ne prend pas en charge SNI, il est possible que vous puissiez 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 limite de prise en charge des correctifs qui vous empêche d’ajouter une étiquette à 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 mise à jour de plusieurs groupes d'adresses IP échoue en générant une erreur de conflit. | Quand vous mettez à jour au moins deux groupes IP joints au même pare-feu, l’une des ressources passe en état d’échec. | Il s'agit d'un problème/d'une limitation connu(e). Quand vous mettez à jour un groupe IP, une mise à jour est déclenchée sur tous les pare-feux auxquels ce groupe IP est joint. Si la mise à jour d’un deuxième groupe IP est lancée alors que le pare-feu est toujours à l’état Mise à jour, la mise à jour du groupe IP échoue. Pour éviter l’échec, les groupes IP joints au même pare-feu doivent être mis à jour un par un. Prévoyez suffisamment de temps entre les mises à jour pour permettre au pare-feu de sortir de l'état Mise à jour. |
| 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 (*) 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. | 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 accède au fournisseur de sécurité. | Non pris en charge. |
| Une erreur s’est produite lors de la création de plus de 2000 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. |
| En-tête XFF dans HTTP/S | Les en-têtes XFF sont remplacés par l’adresse IP source d’origine, telle que la voit le pare-feu. Cela s’applique aux cas d’usage suivants : - Requêtes HTTP - Requêtes HTTPs avec terminaison TLS |
Un correctif est en cours d’étude. |
| 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. |
| La zone DNS privée Azure n’est pas prise en charge avec Pare-feu Azure | La zone DNS privée Azure ne fonctionne pas avec le Pare-feu Azure, quels que soient les paramètres DNS du Pare-feu Azure. | Pour obtenir l’état souhaité de l’utilisation d’un serveur DNS privé, utilisez Pare-feu Azure proxy DNS au lieu d’une zone DNS privée Azure. |
| La zone physique 2 dans la région Japon Est n’est pas disponible pour les déploiements de pare-feu. | Vous ne pouvez pas déployer un nouveau pare-feu avec la zone physique 2. En outre, si vous arrêtez un pare-feu existant déployé dans la zone physique 2, il ne peut pas être redémarré. Pour plus d’informations, consultez Zones de disponibilité physiques et logiques. | Pour les nouveaux pare-feu, déployez avec les zones de disponibilité restantes ou utilisez une autre région. Pour configurer un pare-feu existant, consultez Comment puis-je configurer des zones de disponibilité après le déploiement ?. |
Pare-feu Azure Premium
Les problèmes connus du Pare-feu Azure Premium sont les suivants :
| Problème | Description | Limitation des risques |
|---|---|---|
| Prise en charge ESNI pour la résolution de nom de domaine complet 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. | Aucun |
| 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 d’autorité de certification sur le pare-feu, la prise en compte du certificat peut prendre de 5 à 10 minutes. | 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. |