この記事は、 Azure Firewall の現在の既知の問題と制限事項を理解するのに役立ちます。 問題が解決されると、この情報が更新されるため、最新の状態を定期的に確認してください。
Azure Firewall をデプロイする前に、または既存のデプロイのトラブルシューティングを行う前に、これらの既知の問題を確認して一般的な問題を回避し、適切な回避策を計画してください。
Azure Firewall サービスの制限については、 Azure サブスクリプションとサービスの制限、クォータ、制約に関するページを参照してください。
現在の容量の制約
現在、次のゾーンで容量の制約が発生しています。
| リージョン/ゾーン | SKU | 制限 | 推奨 |
|---|---|---|---|
| 米国東部 2 EUAP の物理ゾーン 1 とゾーン 4 | Basic、Standard、Premium | - ゾーン 1 とゾーン 4 に新しい Azure Firewall をデプロイすることはできません。 | 新しい Azure Firewall を残りの可用性ゾーンにデプロイするか、別のリージョンを使用することをお勧めします。 既存のファイアウォールを構成する方法については、「デプロイ後に可用性ゾーンを構成するにはどうすればよいですか?」を参照してください。 |
|
-
北ヨーロッパの物理ゾーン 2 - 東南アジアの物理ゾーン 3 |
Standard と Premium | - 東南アジアのゾーン 3 または北ヨーロッパのゾーン 2 に新しい Azure Firewall をデプロイすることはできません。
- これらのゾーンにデプロイされている既存のファイアウォールを停止した場合は、再起動できません。 詳細については、「物理ゾーンと可用性ゾーン」を参照してください。 |
新しい Azure Firewall を残りの可用性ゾーンにデプロイするか、別のリージョンを使用することをお勧めします。 既存のファイアウォールを構成する方法については、「デプロイ後に可用性ゾーンを構成するにはどうすればよいですか?」を参照してください。 |
| 米国中南部の物理ゾーン 3 | Basic、Standard、Premium | - ゾーン 3 に新しい Azure Firewall をデプロイすることはできません。
利用可能な予定日: 2026 年 3 月 31 日 |
新しい Azure Firewall を残りの可用性ゾーンにデプロイするか、別のリージョンを使用することをお勧めします。 既存のファイアウォールを構成する方法については、「デプロイ後に可用性ゾーンを構成するにはどうすればよいですか?」を参照してください。 |
| スペイン中央の物理ゾーン 2 | Basic、Standard、Premium | - ゾーン 2 に新しい Azure Firewall をデプロイすることはできません。
利用可能な予定日: 2026 年 12 月 31 日 |
新しい Azure Firewall を残りの可用性ゾーンにデプロイするか、別のリージョンを使用することをお勧めします。 既存のファイアウォールを構成する方法については、「デプロイ後に可用性ゾーンを構成するにはどうすればよいですか?」を参照してください。 |
| US Gov バージニア | Premium | - US Gov バージニアでは、Azure Firewall Premium SKU の容量はゼロであり、ゾーンデプロイと非ゾーンデプロイの両方がブロックされます。 | Azure Firewall Standard SKU をデプロイするか、Premium SKU を別のリージョンにデプロイします。 |
| 米国政府バージニア州の物理ゾーン 3 | Basic および Standard | - ゾーン展開は、米国政府バージニア州の物理ゾーン 3 でブロックされます。
- デプロイを正常に行うには、使用可能なゾーンを手動で選択する必要があります。最適でないデプロイ エクスペリエンスが作成されます。 |
ゾーン展開のゾーン 1 とゾーン 2 を選択するか、別のリージョンを使用します。 |
| 米国西部 2 の物理ゾーン 2 | Basic、Standard、Premium | - ゾーン 2 に新しい Azure Firewall をデプロイすることはできません。 | 新しい Azure Firewall を残りの可用性ゾーンにデプロイするか、別のリージョンを使用することをお勧めします。 既存のファイアウォールを構成する方法については、「デプロイ後に可用性ゾーンを構成するにはどうすればよいですか?」を参照してください。 |
Warnung
これらの容量制限付きリージョンのいずれかで既存の Azure Firewall デプロイを停止した場合、継続的な容量制限により、もう一度開始できない可能性があります。 これらのリージョンでファイアウォール インスタンスを停止する前に、適宜計画してください。
Azure Firewall Standard の既知の問題
Azure Firewall Standard には、次の既知の問題があります。
| 問題 | 説明 | 軽減策 |
|---|---|---|
| プライベート IP アドレスの DNAT サポートが Standard および Premium バージョンに限定されている | Azure Firewall プライベート IP アドレスでの DNAT のサポートは、Standard および Premium Firewall のバージョンでのみ使用でき、Basic バージョンでは使用できません。 | なし |
| プライベート IP DNAT 規則が構成されている場合、Azure Firewall の割り当て解除プロセスと割り当てプロセスはサポートされません。 | プライベート DNAT 規則が構成されている場合、Azure Firewall の割り当てプロセスが失敗する | 1. Azure Firewall 2 の割り当てを解除します。 すべてのプライベート IP DNAT 規則 3 を削除します。 Azure Firewall を割り当て、プライベート IP が 4 に設定されるまで待ちます。 適切なプライベート IP アドレスを使用してプライベート IP DNAT 規則を再構成する |
| TCP/UDP 以外のプロトコル (ICMP など) に関するネットワーク フィルタリング規則が、インターネットへのトラフィックで機能しない | TCP/UDP 以外のプロトコルに関するネットワーク フィルタリング規則は、パブリック IP アドレスへの SNAT で機能しません。 TCP/UDP 以外のプロトコルは、スポーク サブネットと VNet との間でサポートされます。 | Azure Firewall では Standard Load Balancer が使用されます。現在 Standard Load Balancer では、IP プロトコルの SNAT はサポートされていません。 今後のリリースでは、インターネットにバインドされたトラフィックに対して TCP/UDP 以外のプロトコルをサポートするオプションを検討しています。 |
| Azure Firewall の割り当てが解除され、再び割り当てられると、新しいプライベート IP アドレスが割り当てられる可能性があります | Azure Firewall の割り当て解除と割り当てプロセスの後、プライベート IP アドレスは Azure Firewall サブネットから動的に割り当てられます。 前とは異なる新しいプライベート IP アドレスが割り当てられると、ルーティングの問題が発生します。 | 新しいプライベート IP アドレスを使用して、既存のユーザー定義ルート (UDR) を再構成する必要があります。 割り当てプロセス後もプライベート IP アドレスを保持するための修正プログラムが調査中です。 |
| 子ファイアウォール ポリシーは、親ポリシーから DNS 設定を継承しません。 | 親ファイアウォール ポリシーで DNS 設定を変更すると、そのポリシーにリンクされている子ポリシーで、規則内のドメイン名が解決されない場合があります。 | 親ポリシーに依存するのではなく、各子ポリシーで DNS 設定を直接構成します。 DNS 設定の継承を許可する修正プログラムに取り組んでいます。 |
| PowerShell と CLI では ICMP がサポートされない | Azure PowerShell と CLI は、ネットワーク ルールの有効なプロトコルとして ICMP をサポートしていません。 | それでも、ポータルと REST API を介して ICMP をプロトコルとして使用することが可能です。 近いうちに PowerShell と CLI に ICMP を追加するよう取り組んでいます。 |
| FQDN タグで port:protocol を設定する必要がある | FQDN タグを使用するアプリケーション ルールには、port:protocol の定義が必要です。 | port:protocol 値として、https を使用できます。 FQDN タグを使用する場合は、port: protocol フィールドを省略可能にするように取り組んでいます。 |
| ファイアウォールを別のリソース グループまたはサブスクリプションへ移動することはサポートされていません | ファイアウォールを別のリソース グループまたはサブスクリプションへ移動することはサポートされていません。 | この機能のサポートは、ロードマップ上にあります。 ファイアウォールを別のリソース グループまたはサブスクリプションに移動するには、現在のインスタンスを削除して、新しいリソース グループまたはサブスクリプション内に再作成する必要があります。 |
| 脅威インテリジェンス アラートがマスクされる場合がある | アラートのみのモードに構成されている場合、送信フィルター処理用の宛先 80/443 のネットワーク ルールによって脅威インテリジェンス アラートがマスクされます。 | アプリケーション ルールを使用して 80/443 の送信フィルター処理を作成します。 または、脅威インテリジェンス モードを [Alert and Deny](アラートと拒否) に変更します。 |
| セキュリティ保護付き仮想ハブでは、デプロイ中にのみ可用性ゾーンを構成できます。 | セキュリティ保護付き仮想ハブを備えたファイアウォールがデプロイされた後に、Availability Zones を構成することはできません。 | 設計による。 |
| 受信接続での SNAT | 受信 DNAT 規則は、リターン トラフィックの送信元 IP アドレスを常に変更します。 | Web トラフィックの元のクライアント IP を追跡するには、 XFF ヘッダーに元の IP を含むようにクライアントまたはプロキシ サーバーを構成します。 Azure Firewall では、これらの IP アドレスが XFF ヘッダーに保持され、Web トラフィック ルールの処理時にファイアウォール IP が XFF ヘッダーに追加されます。 |
| SQL の FQDN のフィルター処理がプロキシ モードでのみサポートされる (ポート 1433) | Azure SQL Database、Azure Synapse Analytics、Azure SQL Managed Instance の場合: SQL の FQDN のフィルター処理は、プロキシ モードのみでサポートされます (ポート 1433)。 Azure SQL IaaS の場合: 標準以外のポートを使っている場合は、アプリケーション ルールでそれらのポートを指定できます。 |
リダイレクト モードの SQL (Azure 内から接続する場合の既定) では、代わりに Azure Firewall ネットワーク ルールの一部として SQL サービス タグを使ってアクセスをフィルター処理できます。 |
| TCP ポート 25 でアウトバウンド SMTP トラフィックがブロックされている | Azure プラットフォームは、TCP ポート 25 の外部ドメイン (outlook.com や gmail.com など) に直接送信されるアウトバウンド電子メール メッセージをブロックします。 ポート 25 での送信 SMTP トラフィックのブロックは、Azure の既定のプラットフォーム動作です。 Azure Firewall では、これ以上具体的な制限は導入されません。 |
認証済みの SMTP リレー サービスを使用してください。これは、通常は TCP ポート 587 を経由して接続しますが、他のポートもサポートします。 詳細については、Azure でのアウトバウンド SMTP 接続問題のトラブルシューティングに関するページを参照してください。 もう 1 つの選択肢は、標準 Enterprise Agreement (EA) サブスクリプションに Azure Firewall をデプロイすることです。 EA サブスクリプション内の Azure Firewall は、アウトバウンド TCP ポート 25 を使用してパブリック IP アドレスと通信できます。 他の種類のサブスクリプションで動作する可能性がありますが、保証されません。 仮想ネットワーク、VPN、Azure ExpressRoute のようなプライベート IP アドレスの場合、Azure Firewall は TCP ポート 25 でのアウトバウンド接続をサポートしています。 |
| SNAT ポートの枯渇 | Azure Firewall では現在、バックエンドの仮想マシン スケール セット インスタンス 1 つにつき、パブリック IP アドレスごとに 2,496 個のポートがサポートされます。 既定では、2 つの仮想マシン スケール セット インスタンスがあります。 そのため、フローごと (接続先 IP、接続先ポート、プロトコル (TCP または UDP)) に 4,992 個のポートがあります。 ファイアウォールは、最大 20 インスタンスまでスケールアップします。 | SNAT ポートの枯渇はプラットフォームの制限です。 この制限を回避するには、SNAT の枯渇による影響を受けやすいデプロイについては、パブリック IP アドレスを 5 つ以上使用して Azure Firewall のデプロイを構成することをお勧めします。 パブリック IP アドレスを追加すると、使用可能な SNAT ポートが 5 倍になります。 ダウンストリームのアクセス許可を簡素化するために、IP アドレス プレフィックスから割り当ててください。 より永続的なソリューションを得るには、NAT ゲートウェイをデプロイして SNAT ポートの制限を克服できます。 NAT ゲートウェイのデプロイは、仮想ネットワークのデプロイでサポートされています。 詳細については、「Azure Virtual Network NAT を使用した SNAT ポートのスケーリング」を参照してください。 |
| 強制トンネリングが有効になっている場合、DNAT はサポートされない | 強制トンネリングが有効になった状態でデプロイされているファイアウォールは、非対称ルーティングのため、インターネットからの受信アクセスをサポートできません。 | 強制トンネリングでの DNAT サポートの欠如は、非対称ルーティングが原因で設計されています。 受信接続の戻りパスは、確立された接続が表示されないオンプレミスのファイアウォールを経由します。 |
| FTP サーバーの構成によっては、複数のパブリック IP アドレスがあるファイアウォールでは、アウトバウンド パッシブ FTP が機能しない場合がある。 | パッシブ FTP は、コントロールとデータのチャネルに対して異なる接続を確立します。 複数のパブリック IP アドレスを持つファイアウォールは、送信データを送信するときに、ソース IP アドレスとしてパブリック IP アドレスの 1 つをランダムに選択します。 データ チャネルとコントロール チャネルとで異なる送信元 IP アドレスが使用されていると、FTP サーバーの構成によっては FTP が失敗する場合があります。 | 明示的な SNAT 構成が計画されています。 その間は、異なる送信元 IP アドレスからのデータ チャネルとコントロール チャネルを受け入れるように FTP サーバーを構成することができます (IIS の例を参照)。 または、FTP 接続の問題が発生した場合は、1 つの IP アドレスを使用することを検討してください。 |
| FTP サーバーの構成によっては、インバウンド パッシブ FTP が機能しない場合があります。 | パッシブ FTP は、コントロールとデータのチャネルに対して異なる接続を確立します。 対称的なルーティングを実現するために、Azure Firewall へのインバウンド接続は、ファイアウォールのいずれかのプライベート IP アドレスに SNAT 変換されます。 データ チャネルとコントロール チャネルとで異なる送信元 IP アドレスが使用されていると、FTP サーバーの構成によっては FTP が失敗する場合があります。 | 元の送信元 IP アドレスの保持機能を調査中です。 その間は、異なる送信元 IP アドレスからのデータ チャネルとコントロール チャネルを受け入れるように FTP サーバーを構成することができます。 |
| FTP クライアントがインターネット上の FTP サーバーに到達する必要がある場合、アクティブ FTP は機能しません。 | アクティブ FTP では、FTP クライアントからの PORT コマンドを使用して、データ チャネルに使用する IP とポートを FTP サーバーに指示します。 PORT コマンドは、変更できないクライアントのプライベート IP を利用します。 Azure Firewall を通過するクライアント側のトラフィックは、インターネット ベースの通信用に NAT 変換されます。そのため、PORT コマンドは FTP サーバーによって無効と見なされます。 | アクティブ FTP 障害は、クライアント側 NAT で使用される場合の Active FTP の一般的な制限です。 |
| NetworkRuleHit メトリックにプロトコル ディメンションがない | ApplicationRuleHit メトリックでは、プロトコルに基づいたフィルター処理が許可されていますが、対応する NetworkRuleHit メトリックにこの機能がありません。 | 解決策を調査中です。 |
| 64000 から 65535 の範囲のポートを使用した NAT ルールはサポートされません。 | Azure Firewall では、ネットワーク ルールとアプリケーション ルールで 1 から 65535 の範囲の任意のポートを使用できますが、NAT ルールでサポートされるのは、1 から 63999 の範囲のポートのみです。 | NAT 規則ポートの制限は、現在の制限事項です。 |
| 構成の更新に平均 5 分かかる場合がある | Azure Firewall 構成の更新は平均で 3 から 5 分かかる場合があり、並列更新はサポートされていません。 | 解決策を調査中です。 |
| Azure Firewall では、HTTPS トラフィックと MSSQL トラフィックのフィルター処理に SNI TLS ヘッダーが使用される | ブラウザーまたはサーバー ソフトウェアが Server Name Indicator (SNI) 拡張機能をサポートしていない場合は、Azure Firewall 経由で接続することがはできません。 | ブラウザーまたはサーバー ソフトウェアが SNI をサポートしていない場合は、アプリケーション ルールではなくネットワーク ルールを使用して接続を制御できる場合があります。 SNI をサポートするソフトウェアについては、「Server Name Indication」を参照してください。 |
| ポータルまたは Azure Resource Manager (ARM) テンプレートを使用してファイアウォール ポリシー タグを追加できない | Azure Firewall ポリシーにはパッチ サポートの制限があり、Azure portal または ARM テンプレートを使用してタグを追加することはできません。 "リソースのタグを保存できませんでした" というエラーが発生します。 | 解決策を調査中です。 または、Azure PowerShell のコマンドレット Set-AzFirewallPolicy を使用してタグを更新することもできます。 |
| IPv6 は現在、サポートされていない | IPv6 アドレスをルールに追加した場合、ファイアウォールのエラーが発生します。 | IPv4 アドレスのみを使用してください。 IPv6 のサポートは調査中です |
| ARM テンプレートを使用した RuleCollectionGroups の削除はサポートされていません。 | ARM テンプレートを使用した RuleCollectionGroup の削除はサポートされていないため、エラーが発生します。 | ARM テンプレートを使用して RuleCollectionGroups を削除することは、サポートされている操作ではありません。 |
| DNAT 規則で 任意 の (*) を許可すると、SNAT トラフィックが行われます。 | DNAT ルールが送信元 IP アドレスとして 任意 の (*) を許可する場合、暗黙的なネットワーク 規則は VNet-VNet トラフィックと一致し、常にトラフィックを SNAT します。 | 任意のソースでの DNAT ルールの自動 SNAT 動作は、現在の制限事項です。 |
| セキュリティ プロバイダーを使用してセキュリティ保護付き仮想ハブに DNAT ルールを追加することはサポートされていません。 | セキュリティ プロバイダーを使用してセキュリティで保護された仮想ハブに DNAT ルールを追加すると、返される DNAT トラフィックの非同期ルートが作成され、セキュリティ プロバイダーに送信されます。 | サポートされていません。 |
| 2,000 個を超えるルール コレクションを作成するときにエラーが発生した。 | NAT/アプリケーションまたはネットワークのルール コレクションの最大数は、2000 個です (Resource Manager の制限)。 | 現在、規則コレクションの上限は2,000個です。 |
| 新しく作成したパブリック IP アドレスを使用して Availability Zones でファイアウォールをデプロイできない | Availability Zones でファイアウォールをデプロイする場合、新しく作成したパブリック IP アドレスは使用できません。 | まず新しいゾーン冗長パブリック IP アドレスを作成してから、ファイアウォールのデプロイ中にこの事前に作成した IP アドレスを割り当てます。 |
| テナント間のシナリオでは、パブリック IP アドレスと Azure Firewall の関連付けはサポートされていません。 | テナント A にパブリック IP アドレスを作成した場合、テナント B にデプロイされたファイアウォールに関連付けることはできません。 | なし。 |
| Azure Firewall の背後にある VM は、ファイアウォールのパブリック IP を使用して DNAT 規則の宛先に接続できません | VM が Azure Firewall 経由でトラフィックをルーティングし、ファイアウォールのパブリック IP アドレスを使用して DNAT 規則で構成されたリソースに接続しようとすると、接続は失敗します。 接続エラーが発生するのは、Azure Firewall では、内部 VM から DNAT ルールの宛先のファイアウォールの独自のパブリック IP アドレスへのトラフィックのヘア ピン留めをサポートしていないためです。 | この制限の解決策は現在開発中です。 |
Azure Firewall Premium の既知の問題
メモ
Standard に該当する問題は、Premium にも該当します。
Azure Firewall Premium には、次の既知の問題があります。
| 問題 | 説明 | 軽減策 |
|---|---|---|
| HTTPS の FQDN 解決での ESNI のサポート | 暗号化された SNI は HTTPS ハンドシェイクではサポートされていません。 | 現在、Firefox のみでカスタム構成を通じて ESNI がサポートされています。 推奨される回避策は、ESNI 機能を無効にすることです。 |
| クライアント証明書認証はサポートされていません | クライアント証明書は、クライアントとサーバー間で相互の ID の信頼を構築するために使用されます。 クライアント証明書は、TLS ネゴシエーション中に使用されます。 Azure Firewall がサーバーとの接続を再ネゴシエートしていて、クライアント証明書の秘密キーにアクセスできません。 | なし |
| QUIC/HTTP3 | QUIC は、新たなメジャー バージョンの HTTP です。 これは、80 (PLAN) と 443 (SSL) を介する UDP ベースのプロトコルです。 FQDN/URL/TLS 検査はサポートされていません。 | ネットワーク規則として UDP 80/443 を通るように構成します。 |
| 顧客の署名入り証明書が信頼されない | ファイアウォールは、イントラネット ベースの Web サーバーから顧客が署名した証明書を受信しても信頼しません。 | 解決策を調査中です。 |
| IDPS が TLS 検査なしで HTTP アラートの間違ったソース IP アドレスを表示する | IDPS は、パブリック IP アドレスへのプレーン テキスト HTTP トラフィックのアラートを生成するときに、元のソース IP アドレスではなく内部 IP アドレスを表示します。 | 解決策を調査中です。 |
| 証明書の伝播 | CA 証明書がファイアウォールに適用された後、証明書が有効になるまでに 5 分から 10 分かかる場合があります。 | 解決策を調査中です。 |
| TLS 1.3 のサポート | TLS 1.3 は部分的にサポートされています。 クライアントからファイアウォールへの TLS トンネルは TLS 1.2 に基づいており、ファイアウォールから外部 Web サーバーへは TLS 1.3 に基づいています。 | 更新を調査中です。 |
| TLSi 中間 CA 証明書の有効期限 | 一部の特殊なケースでは、中間 CA 証明書は、元の有効期限の 2 か月前に期限切れになる可能性があります。 | 元の有効期限の 2 か月前に中間 CA 証明書を更新します。 解決策を調査中です。 |