【ハマりポイント】AppGW + Azure Firewall + Private Endpoint 構成で Health Probe が失敗した話と解決策

Posted at 2026-08-12

【ハマりポイント】AppGW + Azure Firewall + Private Endpoint 構成で Health Probe が失敗した話と解決策

Azure 上でセキュリティを高めた Web アプリケーション基盤を構築する際、Application Gateway (AppGW)、Azure Firewall、Private Endpoint (PE) を組み合わせて Web App を公開する構成はよく使われます。

今回、「ルーティング（UDR）も NSG も問題なく、Azure Firewall Log でも Allow となっているのに、AppGW の Health Probe が失敗して Backend が Unhealthy になる」という現象に遭遇しました。

最終的には Azure Firewall のルールを Network Rule から Application Rule に変更（＝SNATを有効化）することで解決 したため、その原因と学びを共有します。

ネットワーク構成と発生した問題

今回構築していた構成は以下の通りです。

全体構成

[ Client ]
    │
    ▼
[ Application Gateway ] (AppGW Subnet: 10.0.1.0/24)
    │
    ▼  (UDR: 10.0.2.0/24 -> Azure Firewall)
[ Azure Firewall ]     (FW Subnet: 10.0.0.4)
    │
    ▼  (Target IP: 10.0.2.10)
[ Private Endpoint ]   (PE Subnet: 10.0.2.0/24)
    │
    ▼
[ Web App (Backend) ]

発生したエラー

Application Gateway の Backend Health が Unhealthy となり、以下のエラーが出力されていました。

AppGW 側のエラー:
ngx_http_upstream_check_err_ServerNotReachable
クライアント側の表示:
Cannot connect to backend server. Check whether any NSG/UDR/Firewall is blocking access.

一見すると問題なさそうに見えた理由

構築時の確認では、ネットワーク設定に落ち度がないように見えていました。

往路の UDR（AppGW Subnet）:
10.0.2.0/24 宛（PEのサブネット）の通信は Azure Firewall（10.0.0.4）へ転送するよう設定。
復路の UDR（PE Subnet）:
10.0.1.0/24 宛（AppGWのサブネット）の通信も Azure Firewall（10.0.0.4）へ返すよう設定。
Azure Firewall ログ:
TCP request from 10.0.1.4 to 10.0.2.10:443 Action: Allow と出力されており、FW までは正常に到達し通過していた。

UDR による対称ルーティングが組まれており、ログ上も Allow であるため、「非対称ルーティング（Asymmetric Routing）は起きていないはず」と考えてドハマりしました。

原因と解決策：なぜ Network Rule ではダメだったのか？

原因：Network Rule と Application Rule の SNAT 挙動の違い

Azure Firewall のルール種別による 送信元 IP アドレス変換（SNAT）の挙動 が影響していました。

ルール種別	送信元 IP アドレスの変換（SNAT）
Network Rule	デフォルトでは SNAT されない（元の送信元 IP を維持）
Application Rule	常に SNAT される（送信元 IP が Azure Firewall の IP に置換される）

Network Rule の場合、送信元 IP が AppGW（10.0.1.4）のまま Private Endpoint に届きます。Private Endpoint 側のネットワーク構成やプラットフォームの応答挙動によっては、戻りのパケットが意図した経路を辿らなかったり、AppGW 側でセッションが正常に認識されず、TCP ハンドシェイクや TLS 接続が途中で失敗することがあります。

Microsoft の公式ドキュメントでも、Private Endpoint 宛の通信を Azure Firewall で検査・制御する場合は Application Rule の使用が推奨 されています。

試したことと結果

Azure Firewall のルール設定を変更し、NSG を調整しました。

ルール変更: Azure Firewall.
Azure Firewall のルールを Network Rule から Application Rule に変更。
NSG 設定調整: Private Endpoint Subnet.
Application Rule の使用により送信元 IP が Azure Firewall に変換されるため、Private Endpoint Subnet の NSG で Azure Firewall の IP（10.0.0.4）からの 443 通信を許可。

変更後の結果

設定変更後、即座に Application Gateway の Backend Health が Healthy に変化し、Health Probe が成功してサービスが復旧しました！

この事例から学んだ 3 つのポイント

[!IMPORTANT]
1. UDR が正しく設定されていても通信失敗は起こり得る
往路・復路の UDR を正しく設定して対称ルーティングを意識していても、L4（Network Rule）レベルの透過通信では Private Endpoint 特有の制限やプラットフォームの挙動に引っかかるケースがあります。

[!NOTE]
2. Azure Firewall Log の Action: Allow は接続成功を保証しない
ログの Allow は「Firewall がパケットを通過させた」ことしか示していません。その先のハンドシェイク完了や Health Probe の成功まで保証するものではないため、ログだけで「FW は原因から除外」と判断するのは危険です。

[!TIP]
3. Private Endpoint 宛通信は Application Rule (SNAT) を優先検討する
Private Endpoint を経由する構成で Azure Firewall を挟む場合は、最初から Application Rule（または Network Rule での明示的な SNAT 設定） を検討するのが最も安定します。

まとめ

現象: AppGW + AzFW + PE 構成で、UDR/NSG/FWログが正常に見えるのに Health Probe が失敗する。
原因: Network Rule 使用時の SNAT 非適用に起因する通話不全。
解決策: Azure Firewall のルールを Application Rule に変更して送信元 IP を SNAT する。

「設定はすべて合っているはずなのに AppGW から Private Endpoint への Health Probe が通らない…」と悩んだ際は、Azure Firewall の SNAT 挙動（Application Rule への切り替え） をぜひ疑ってみてください！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up