【Azure Firewall】VNet Peering構成で通信が不安定？不要なUDRが引き起こす非対称ルーティングの罠

Azure Firewall（AFW）を Hub VNet に配置し、Spoke VNet（WebサーバーやデータベースなどのVM）へ VNet Peering 経由でトラフィックを通す構成は非常に一般的です。

しかし、構成変更や環境構築の際、「通信が成功したり失敗したりする」「接続が約50%の確率でタイムアウトする」 といった原因不明のトラブルに直面することはありませんか？

この記事では、AFW の SNAT（送信元 IP 変換）挙動と Spoke VM 側の UDR（ユーザー定義ルート）の設定によって発生する非対称ルーティング（Asymmetric Routing）のメカニズムと、その正しい解決策を分かりやすく解説します。

発生する現象

Spoke VM へのアクセス時、接続が不安定になる（成功したり失敗したりを繰り返す）。
AzFWは複数インスタンス構成（例：2インスタンス）の場合、およそ 50% の確率で通信がドロップする。

原因：SNAT環境下での「不要な折り返し UDR」

この問題の根本原因は、Spoke サブネット側に 戻り通信で「宛て（例: 送信元CLientのSubnet10.10.10.0/24）の Next Hop を AFW Frontend IP (ILB) に指定した UDR」 が明示的に追加されていることにあります。

1. 本来の正常な通信フロー（UDR なし）

AFW で Application Rule を適用する（または Network Rule で全 SNAT を有効化している）場合、パケットの送信元 IP（Src IP）は 「実際に処理を行った個別の AFW インスタンス A の IP」 に SNAT されます。

【行き】 Client → AFW Frontend IP (ILB) → AFW インスタンス A (SNAT実行) → Peering → Spoke VM
【戻り】 Spoke VM → Peering (システムルート) → AFW インスタンス A → Client

Spoke VM から見ると、パケットは 「AFW インスタンス A の固有 IP」 から届きます。そのため戻り通信は、Azure の標準機能である VNet Peering のシステムルートに従ってダイレクトに AFW インスタンス A へ返却されます。同じインスタンスに到達するためセッションテーブルと合致し、通信は正常に成立します。

2. トラブルが発生する通信フロー（不要な UDR あり）

ここで Spoke サブネットに AFW サブネット宛ての UDR を設定してしまうと、戻りパケットが強制的に内部ロードバランサー（ILB）へ引き戻されます。

【行き】 Client → AFW Frontend IP (ILB) → AFW インスタンス A (SNAT実行) → Peering → Spoke VM
【戻り】 Spoke VM → UDR により  AFW Frontend IP (ILB) → (ILB が インスタンス B へ振り分け) → 通信ドロップ！

戻りパケットが AzFWのILB へ強制送出される。
ILB はロードバランシングハッシュにより、パケットを別個のインスタンス B へ割り振る可能性がある。
インスタンス B は「行き」のセッション情報を持っていないため、ステートフル機能によって非対称パケットと判定され、通信を拒否（Deny / Drop） する。

AzFWインスタンスが 2 台の場合、統計上は約 50% の確率で「行きと同一のインスタンス A」に偶然戻って成功するため、「たまに成功する不安定な障害」として表面化します。

ルーティングの優先度（最長一致の原則）

「デフォルトルート（0.0.0.0/0）が存在するから影響するのでは？」と疑問に思うかもしれません。
しかし、Azure のルーティングは最長一致（Longest Prefix Match）で判定されるため、プレフィックス長の異なるルールでは動作が異なります。

0.0.0.0/0（UDR / プレフィックス /0）：
プレフィックスが最も長いため優先度は最低です。個別の AFW インスタンス宛て（/24 等）の通信には影響せず、Peering のシステムルート（/24）が優先されます。
10.10.10.0/24（UDR / プレフィックス /24）：
Peering のシステムルートとプレフィックス長（/24）が同じになるため、UDR（ユーザー定義ルート）がシステムルートを上書き（オーバーライド） してしまいます。

結論と設計のベストプラクティス

SNAT が有効な構成では戻り通信をAFW へ向ける UDR は不要
Application Rule や全 SNAT 設定を使用している場合、Spoke サブネットに AFW に向けた折り返し UDR を設定してはいけません。

不要な UDR を削除し、VNet Peering のデフォルトシステムルートに任せることで、戻り通信は常に正しい AFW インスタンスへ戻り、非対称ルーティング問題を根本解決できます。