Azure Firewall の既知の問題と制限事項
この記事では、Azure Firewall の既知の問題を一覧で示します。 問題が解決されると内容が更新されます。
Azure Firewall の制限事項については、「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照してください。
Azure Firewall Standard
Azure Firewall Standard には、次の既知の問題があります。
注意
Standard に該当する問題は、Premium にも該当します。
| 問題 | 説明 | 対応策 |
|---|---|---|
| プライベート IP アドレスの DNAT サポートが Standard および Premium バージョンに限定されている | Azure Firewall プライベート IP アドレスでの DNAT のサポートはエンタープライズ向けであるため、Standard および Premium ファイアウォール バージョンに限定されています。 | なし |
| TCP/UDP 以外のプロトコル (ICMP など) に関するネットワーク フィルタリング規則が、インターネットへのトラフィックで機能しない | TCP/UDP 以外のプロトコルに関するネットワーク フィルタリング規則は、パブリック IP アドレスへの SNAT で機能しません。 TCP/UDP 以外のプロトコルは、スポーク サブネットと VNet との間でサポートされます。 | Azure Firewall では Standard Load Balancer が使用されます。現在 Standard Load Balancer では、IP プロトコルの SNAT はサポートされていません。 Microsoft は、将来のリリースでこのシナリオに対応できるよう方法を模索しています。 |
| PowerShell と CLI では ICMP がサポートされない | Azure PowerShell と CLI は、ネットワーク ルールの有効なプロトコルとして ICMP をサポートしていません。 | それでも、ポータルと REST API を介して ICMP をプロトコルとして使用することが可能です。 近いうちに PowerShell と CLI に ICMP を追加するよう取り組んでいます。 |
| FQDN タグで port:protocol を設定する必要がある | FQDN タグを使用するアプリケーション ルールには、port:protocol の定義が必要です。 | port:protocol 値として、https を使用できます。 FQDN タグの使用時にこのフィールドを省略可能にするため、取り組みを進めています。 |
| ファイアウォールを別のリソース グループまたはサブスクリプションへ移動することはサポートされていません | ファイアウォールを別のリソース グループまたはサブスクリプションへ移動することはサポートされていません。 | この機能は今後サポートされる予定です。 ファイアウォールを別のリソース グループまたはサブスクリプションに移動するには、現在のインスタンスを削除して、新しいリソース グループまたはサブスクリプション内に再作成する必要があります。 |
| 脅威インテリジェンス アラートがマスクされる場合がある | アラートのみのモードに構成されている場合、送信フィルター処理用の宛先 80/443 のネットワーク ルールによって脅威インテリジェンス アラートがマスクされます。 | アプリケーション ルールを使用して 80/443 の送信フィルター処理を作成します。 または、脅威インテリジェンス モードを [Alert and Deny](アラートと拒否) に変更します。 |
| セキュリティ保護付き仮想ハブでは、デプロイ中にのみ可用性ゾーンを構成できます。 | セキュリティ保護付き仮想ハブを備えたファイアウォールがデプロイされた後に、Availability Zones を構成することはできません。 | これは仕様です。 |
| 受信接続での SNAT | DNAT に加えて、ファイアウォールのパブリック IP アドレスを使用した (受信) 接続は SNAT によっていずれかのファイアウォールのプライベート IP に変換されます。 対称的なルーティングを実現するために、現在このような要件が (アクティブ/アクティブ NVA に対しても) 適用されます。 | HTTP/S の元の送信元を保持するには、XFF ヘッダーを使用することを検討します。 たとえば、ファイアウォールの直前に Azure Front Door や Azure Application Gateway などのサービスを使用します。 Azure Front Door とチェーンの一部としてファイアウォールに WAF を追加することもできます。 |
| 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 トラフィックがブロックされている | TCP ポート 25 で外部ドメイン (outlook.com や gmail.com など) に直接送信されるアウトバウンド電子メール メッセージは Azure プラットフォームによってブロックされます。 これは、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 の枯渇による影響を受けやすいデプロイについては、パブリック IP アドレスを 5 つ以上使用して Azure Firewall のデプロイを構成することをお勧めします。 そうすれば、使用できる SNAT ポートは 5 倍になります。 ダウンストリームのアクセス許可を簡素化するために、IP アドレス プレフィックスから割り当ててください。 より永続的なソリューションを得るには、NAT ゲートウェイをデプロイして SNAT ポートの制限を克服できます。 この方法は、仮想ネットワークのデプロイでサポートされています。 詳細については、「Azure Virtual Network NAT を使用した SNAT ポートのスケーリング」を参照してください。 |
| 強制トンネリングが有効になっている場合、DNAT はサポートされない | 強制トンネリングが有効になった状態でデプロイされているファイアウォールは、非対称ルーティングのため、インターネットからの受信アクセスをサポートできません。 | これは、非対称ルーティングのための仕様です。 受信接続のリターン パスは、確立された接続が検出されていないオンプレミスのファイアウォールを経由します。 |
| FTP サーバーの構成によっては、複数のパブリック IP アドレスがあるファイアウォールでは、アウトバウンド パッシブ FTP が機能しない場合がある。 | パッシブ FTP は、コントロールとデータのチャネルに対して異なる接続を確立します。 複数のパブリック IP アドレスを持つファイアウォールは、送信データを送信するときに、ソース IP アドレスとしてパブリック IP アドレスの 1 つをランダムに選択します。 データ チャネルとコントロール チャネルとで異なる送信元 IP アドレスが使用されていると、FTP サーバーの構成によっては FTP が失敗する場合があります。 | 明示的な SNAT 構成が計画されています。 その間は、異なる送信元 IP アドレスからのデータ チャネルとコントロール チャネルを受け入れるように FTP サーバーを構成することができます (IIS の例を参照)。 ただし、このケースでは、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 サーバーによって無効と見なされます。 | これは、クライアント側 NAT と一緒に使用する場合のアクティブ FTP の一般的な制限です。 |
| NetworkRuleHit メトリックにプロトコル ディメンションがない | ApplicationRuleHit メトリックでは、プロトコルに基づいたフィルター処理が許可されていますが、対応する NetworkRuleHit メトリックにこの機能がありません。 | 解決策を調査中です。 |
| 64000 から 65535 の範囲のポートを使用した NAT ルールはサポートされません。 | Azure Firewall では、ネットワーク ルールとアプリケーション ルールで 1 から 65535 の範囲の任意のポートを使用できますが、NAT ルールでサポートされるのは、1 から 63999 の範囲のポートのみです。 | これは現在の制限です。 |
| 構成の更新に平均 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 のサポートは調査中です |
| 複数の IP グループを更新すると、競合エラーが発生して失敗します。 | 同じファイアウォールにアタッチされている複数の IP グループを更新すると、いずれかのリソースがエラー状態になります。 | これは既知の問題および制限です。 IP グループを更新すると、IP グループがアタッチされているすべてのファイアウォールで更新がトリガーされます。 ファイアウォールがまだ "更新中" の状態であるときに 2 番目の IP グループへの更新が開始された場合、IP グループの更新は失敗します。 この失敗を回避するには、同じファイアウォールにアタッチされている IP グループを一度に 1 つずつ更新する必要があります。 各更新の間に十分な時間を確保して、ファイアウォールが "更新中" の状態を終了できるようにします。 |
| ARM テンプレートを使用した RuleCollectionGroups の削除はサポートされていません。 | ARM テンプレートを使用した RuleCollectionGroup の削除はサポートされていないため、エラーが発生します。 | これは、サポートされている操作ではありません。 |
| any (*) を許可する DNAT ルールではトラフィックが SNAT (送信元ネットワーク アドレス変換) されます。 | DNAT ルールによって送信元 IP アドレスとして any (*) が許可される場合、暗黙的なネットワーク ルールによって VNet-VNet トラフィックが照合され、トラフィックが常に SNAT されます。 | これは現在の制限です。 |
| セキュリティ プロバイダーを使用してセキュリティ保護付き仮想ハブに DNAT ルールを追加することはサポートされていません。 | これは結果的に、返される DNAT トラフィックの非同期ルートになり、これがセキュリティ プロバイダーに送信されます。 | サポートされていません。 |
| 2,000 個を超えるルール コレクションを作成するときにエラーが発生した。 | NAT/アプリケーションまたはネットワークのルール コレクションの最大数は、2000 個です (Resource Manager の制限)。 | これは現在の制限です。 |
| HTTP/S の XFF ヘッダー | XFF ヘッダーが、ファイアウォールから見た元の送信元 IP アドレスで上書きされます。 これは、次のユース ケースで関係します。 - HTTP 要求 - TLS での HTTPS 要求の強制終了 |
解決策を調査中です。 |
| 新しく作成したパブリック IP アドレスを使用して Availability Zones でファイアウォールをデプロイできない | Availability Zones でファイアウォールをデプロイする場合、新しく作成したパブリック IP アドレスは使用できません。 | まず新しいゾーン冗長パブリック IP アドレスを作成してから、ファイアウォールのデプロイ中にこの事前に作成した IP アドレスを割り当てます。 |
| 北ヨーロッパの物理ゾーン 2 は、ファイアウォールのデプロイでは使用できません。 | 物理ゾーン 2 を使用して新しいファイアウォールをデプロイすることはできません。 さらに、物理ゾーン 2 にデプロイされている既存のファイアウォールを停止した場合は、再起動できません。 詳細については、「物理ゾーンと可用性ゾーン」を参照してください。 | 新しいファイアウォールの場合は、残りの可用性ゾーンを使用してデプロイするか、別のリージョンを使用します。 既存のファイアウォールを構成する方法については、「デプロイ後に可用性ゾーンを構成するにはどうすればよいですか?」を参照してください。 |
Azure Firewall Premium
Azure Firewall Premium には、次の既知の問題があります。
| 問題 | 説明 | 対応策 |
|---|---|---|
| HTTPS の FQDN 解決での ESNI のサポート | 暗号化された SNI は HTTPS ハンドシェイクではサポートされていません。 | 現在、Firefox のみでカスタム構成を通じて ESNI がサポートされています。 回避策として、この機能を無効にすることをお勧めします。 |
| クライアント証明書認証はサポートされていません | クライアント証明書は、クライアントとサーバー間で相互の ID の信頼を構築するために使用されます。 クライアント証明書は、TLS ネゴシエーション中に使用されます。 Azure Firewall がサーバーとの接続を再ネゴシエートしていて、クライアント証明書の秘密キーにアクセスできません。 | None |
| QUIC/HTTP3 | QUIC は、新たなメジャー バージョンの HTTP です。 これは、80 (PLAN) と 443 (SSL) を介する UDP ベースのプロトコルです。 FQDN/URL/TLS 検査はサポートされていません。 | ネットワーク規則として UDP 80/443 を通るように構成します。 |
| 顧客の署名入り証明書が信頼されない | 顧客の署名入り証明書は、イントラネット ベースの Web サーバーから受信されると、ファイアウォールによって信頼されません。 | 解決策を調査中です。 |
| HTTP (TLS 検査なし) での IDPS によるアラートの送信元 IP アドレスが間違っている。 | プレーン テキスト HTTP トラフィックが使用されていて、IDPS によって新しいアラートが発行されるとき、宛先がパブリック IP アドレスであれば、間違った発信元の IP アドレスが表示されます (元の 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 証明書を更新します。 解決策を調査中です。 |