Azure 上で既存 VNet と新規 VNet をピアリングしたのに通信ができず、「ルートテーブルやファイアウォールのどこを直せばいいのか分からない…」というケースはとても多いです。本記事では、172.20.0.0/16 と 172.21.0.0/16 の 2 つの VNet 間で ping が通らない具体的な事例をもとに、Azure VNet ピアリングと UDR（ユーザー定義ルート）、仮想ファイアウォールの設定ポイントを、実務目線で詳しく解説します。
シナリオ概要：2 つの Azure VNet 間で通信できない
まずは今回の構成と、よくあるハマりポイントを整理します。
構成イメージ
【VNet1（既存環境）】
アドレス空間：172.20.0.0/16
サブネット： /24 単位で複数
配置：AVD（Azure Virtual Desktop）VM、旧 仮想ファイアウォール（EOL）
【VNet2（新 FW 用 VNet）】
アドレス空間：172.21.0.0/16
配置：新しい仮想ファイアウォール
（LAN 側 IP の例：172.21.1.4）
【要件】
- 旧 FW 廃止後は、172.20.* 上の AVD などから
新 FW（172.21.1.4）経由で外部・他ネットワークへ通信させたい
- 2 つの VNet 間のピアリングは「Connected」
- しかし 172.20.* から 172.21.1.4 への ping が通らない
「VNet ピアリングは Connected だし、アドレス空間も被っていない。あとは UDR を書けばいいはずなのに、なぜか疎通しない」という状況は、Azure ネットワークでは典型的なトラブルです。
構成を表で整理
| 項目 | VNet1（既存） | VNet2（新 FW 用） |
|---|---|---|
| アドレス空間 | 172.20.0.0/16 | 172.21.0.0/16 |
| 代表サブネット | 例：172.20.1.0/24（AVD） | 例：172.21.1.0/24（FW LAN） |
| 主なリソース | AVD、旧 仮想 FW | 新 仮想 FW（172.21.1.4 等） |
| VNet ピアリング | 双方向で作成済み（状態：Connected） | |
| 現象 | 172.20.* → 172.21.1.4 に ping が届かない | |
Azure VNet ピアリングの基本をざっくりおさらい
原因に入る前に、「ピアリングさえ張れば全部通る」と思い込んでいるとハマります。VNet ピアリングの挙動をざっくり整理しておきましょう。
- VNet ピアリングは「VNet 同士のルーティング」を自動でつないでくれる機能
- しかし、仮想アプライアンス（FW や NVA）経由で転送されるトラフィックを扱うには、追加設定が必要
- 具体的には、以下 2 点がキモ
- ピアリング設定で 転送トラフィックを許可（Allow forwarded traffic）
- 仮想アプライアンスの NIC で IP 転送（IP forwarding） を有効化
また、VM がどの経路を使うかは、ルート テーブル（UDR）とシステム ルートの組み合わせで決まります。VNet ピアリングはあくまで 「向こうの VNet のプレフィックスを知っている」状態にしてくれるだけで、「必ず FW を経由させる」ことまではやってくれません。
| 機能 | 役割 | 今回のシナリオでのポイント |
|---|---|---|
| VNet ピアリング | VNet 間のルート情報を共有し、トラフィックを直接通す | FW を経由させる場合は「転送トラフィックを許可」が必須 |
| IP 転送 | NIC が受信したパケットを別の宛先へルーティング・転送できるようにする | FW の NIC で無効だと、受け取ったパケットがそこで「終端」されてしまう |
| UDR（ユーザー定義ルート） | 特定の宛先プレフィックスに対する次ホップを上書きする | 172.21.0.0/16 へのトラフィックを新 FW IP に向ける設定が必要 |
通信できないときに疑うべき典型パターン
Azure VNet 間通信で「ピアリングは OK なのに通信できない」とき、実務では次の 3 つをまず疑います。
| パターン | よくある原因 | 今回のケースとの関係 |
|---|---|---|
| パターン A | FW NIC の IP 転送が無効 | 新ファイアウォールの NIC 設定で IP 転送がオフだと、VNet 間の転送ができない |
| パターン B | UDR の宛先・次ホップ IP が誤り、もしくは未設定 | 172.20.* サブネットに 172.21.0.0/16 へのルートがなく、デフォルトルートで違う場所に行っている |
| パターン C | NSG / OS ファイアウォールで ICMP（ping）が拒否されている | 実は TCP 80/443 などは通るが、ping だけ落ちているケースが多い |
この 3 つを丁寧に潰していくと、ほとんどの VNet 間疎通トラブルは解消できます。
解決策：VNet 間通信を有効にする具体的な手順
ここからは、実際に何を設定すればよいかを、手順ベースで解説します。
アドレス空間の重複がないことを確認する
最初に必ず確認すべきなのが アドレス空間の重複です。VNet のアドレス範囲が重複していると、ピアリングを張っても正しくルーティングできません。
- VNet1：172.20.0.0/16
- VNet2：172.21.0.0/16
この例ではきれいに分かれているので問題ありませんが、実際の現場では「/24 ベースで設計していると思っていたら、どこかで /16 が混ざっていた」などのミスが起きがちです。Azure ポータルの VNet 設定画面で必ず再確認しましょう。
VNet ピアリングを正しく設定する
ピアリングは 各 VNet から相手 VNet に 1 本ずつ、計 2 本必要です。どちらも状態が「Connected」になっていることを確認したうえで、次の設定を見直します。
| 設定項目 | 推奨設定 | 補足 |
|---|---|---|
| 仮想ネットワーク アクセスを許可 | 有効 | これが無効だと VNet 間のトラフィック自体が拒否される |
| 転送トラフィックを許可（Allow forwarded traffic） | 有効 | FW/NVA など「経由する」トラフィックを許可する必須設定 |
| リモート ゲートウェイの使用 | 構成に応じて片側のみ | サイト間 VPN と組み合わせる場合などに利用。両側同時オンは不可。 |
特に「転送トラフィックを許可」は、仮想ファイアウォールを挟む構成では必須です。ここが無効のままだと、FW がルーティングしたトラフィックがピアリングを越えられません。
新ファイアウォール NIC の IP 転送を有効化する
次に、新ファイアウォールが接続されている NIC の IP 転送 を有効化します。Azure ポータルで以下のように操作します。
- 新 FW の NIC を開く
- 「IP 構成」または「設定」メニュー内の「IP 転送」を選択
- 「有効」に変更して保存
IP 転送を有効にしない場合、その NIC は「自分あてのパケット」しか処理せず、他のサブネット / VNet への転送ができません。結果として、AVD から FW へパケットが届いても、そこで止まってしまいます。
ユーザー定義ルート (UDR) を作成して新 FW を経由させる
次に、172.20.* 側のサブネットから新 FW（172.21.1.4 など）を経由するように、UDR を設定します。
代表的な設定例は以下の通りです。
| 項目 | 値（例） | 説明 |
|---|---|---|
| 宛先プレフィックス | 172.21.0.0/16 | 新 FW の VNet（VNet2）のアドレス範囲 |
| 次ホップの種類 | Virtual appliance | 仮想アプライアンス（FW/NVA）を指定 |
| 次ホップ アドレス | 172.21.1.4 | 新 FW の LAN 側 NIC IP（例） |
このルート テーブルを、172.20.* 側の各サブネット（AVD がいるサブネットなど）に関連付けます。
外部インターネットも新 FW 経由にしたい場合は、宛先プレフィックスを 0.0.0.0/0 にするパターンもあります。その場合は、ノン FW トラフィック（例えば管理用 VM など）を別サブネットに分けるなど、設計上の整理が必要です。
また、逆方向の通信が必要な場合（172.21.* 上のサーバーから 172.20.* の AVD にアクセスしたいなど）、VNet2 側のサブネットに対しても同様に UDR を設定します。
NSG と OS ファイアウォールを確認する
ping が通らないトラブルの中で、実はかなりの割合を占めるのが NSG／OS ファイアウォールによる ICMP のブロックです。
- NSG の受信ルールに「Allow ICMP Any」などがなければ ping は通らない
- Windows ファイアウォールの既定設定では、外部からの ICMP を拒否していることが多い
そのため、疎通確認は ICMP だけに頼らないことが重要です。
- Windows：
Test-NetConnection 172.21.1.4 -Port 443 - Linux：
nc -vz 172.21.1.4 443など
実際の業務では RDP（3389）、SSH（22）、HTTPS（443）など 実際に使うポート番号で通信確認する方が信頼性が高いです。ping が通らなくても、業務的には問題ないケースも少なくありません。
有効なルート／セキュリティ ルールをポータルで確認する
Azure では、VM の NIC 画面から 「有効なルート」「有効なセキュリティ ルール」を確認できます。ここを見ると、迷子になったルートや意図しない NSG が一目瞭然です。
確認のポイントは次の通りです。
- 有効なルート
- 宛先 172.21.0.0/16 に対して「次ホップ：Virtual appliance（172.21.1.4）」が表示されているか
- もし System ルートが優先されているなら、UDR が適用されていないか、優先度の問題を疑う
- 有効なセキュリティ ルール
- 受信方向で、AVD → 新 FW へのポートが許可されているか
- 拒否ルール（Deny）が上位に来ていないか
「頭では理解しているつもりでも、実際どのルールが効いているか分からない」ときは、まずここを見る癖をつけるとトラブルシュートがかなり楽になります。
アドレス空間を後から変更する場合の注意点
ピアリング済みの VNet に対してアドレス空間を追加・削除したくなることはよくありますが、Azure の仕様上、ピアリングが張られた状態では VNet のアドレス範囲を変更できません。
変更が必要な場合は次の手順になります。
- 対象 VNet のピアリングを一度削除
- アドレス空間を追加・削除
- 改めてピアリングを作り直し（設定値を再確認）
運用中環境では影響範囲が大きいため、メンテナンス時間を確保して計画的に行うことをおすすめします。
トラブルシューティングを効率化するチェック手順
ここまでのポイントを踏まえて、実際に現場でやるときの「おすすめ診断フロー」をまとめます。
| ステップ | 確認内容 | 具体的な操作・コマンド例 |
|---|---|---|
| 1 | アドレス空間を確認 | Azure ポータルで VNet1・VNet2 のアドレス範囲を確認し、重複がないかチェック |
| 2 | ピアリングの状態とオプション | ピアリングが双方向で「Connected」になっているか、「転送トラフィックを許可」が有効かを確認 |
| 3 | FW NIC の IP 転送 | 新 FW の NIC 設定で「IP 転送」が有効になっているか確認 |
| 4 | UDR の内容と紐づけ先 | 宛先 172.21.0.0/16、次ホップ 172.21.1.4 などのルートが、AVD サブネットに関連付けられているか確認 |
| 5 | 有効なルートを確認 | AVD VM の NIC から「有効なルート」を開き、該当の UDR が実際に効いているかを確認 |
| 6 | NSG／OS FW の確認 | NSG と Windows/Linux ファイアウォールで、対象ポート（例：443, 3389 など）が許可されているか確認 |
| 7 | 実通信による疎通確認 | Test-NetConnection や nc を使って、業務で使うポートでの通信を確認 |
DNS と名前解決の落とし穴
VNet ピアリングをしても、DNS 名解決は自動では連携されません。IP アドレスでは通信できているのに、ホスト名では繋がらない、という相談も非常に多いです。
- Active Directory DNS を使う場合：両 VNet から参照できる DNS サーバーを用意し、ゾーンやフォワーダーを適切に設定
- Azure DNS Private Zones／Private Resolver を利用する場合：両 VNet をリンクし、名前解決経路を統一
「ping ホスト名」で切り分けをしようとして、実は DNS が原因だった、というパターンもよくあるため、IP で繋がるか／名前でも繋がるかを分けて確認することが重要です。
暗号化・重複アドレスが絡む場合は VNet‑to‑VNet VPN も検討
今回のケースはプレーンな VNet ピアリングで解決できますが、以下のような要件がある場合は VNet‑to‑VNet VPN の検討も視野に入ります。
- 異なるサブスクリプション・テナント間で暗号化された通信が必須
- オンプレミスと同様に、重複アドレス空間を扱いたい
- ネットワーク境界でより厳密な制御が必要
VNet ピアリングは「同じ組織内のネットワークをフラットに近づける」イメージ、VNet‑to‑VNet VPN は「拠点間 VPN に近い」イメージで使い分けると整理しやすくなります。
AVD（Azure Virtual Desktop）環境特有の注意ポイント
今回のように AVD が VNet1 側に多数存在する状況では、以下の点に注意すると移行がスムーズになります。
- 段階的なルート切り替え：
- テスト用サブネットを用意し、まず一部の AVD から新 FW 経由に変更
- 問題なければ他サブネットにも UDR を徐々に展開
- セッションホストの NSG 設計：
- AVD の管理ポート（RDP など）を許可する NSG と、ユーザー トラフィックを制御する NSG を分けると運用しやすい
- 監査・ログ：
- 新 FW 側でのトラフィックログ（Flow Logs や FW ログ）を有効化し、移行時のトラブルを追いやすくする
よくある質問と補足
Q. VNet ピアリングがあれば、UDR は必ず必要ですか？
A. 必ずしも必要ではありません。
「VM 同士が VNet 間で直接通信するだけ」であれば、システム ルートとピアリングだけで通信できます。
しかし、今回のように すべてのトラフィックを新 FW 経由にしたい 場合、UDR でルートを上書きしないと、VM から見た「次ホップ」が旧 FW やインターネットゲートウェイのままになってしまいます。
Q. ping が通らないのに、RDP や HTTPS は通るのはなぜ？
A. 多くの場合、NSG または OS ファイアウォールが ICMP を拒否しているだけです。
Azure の NSG では、既定で ICMP を明示的に許可していないと ping が通らない構成がよくあります。「ping が通らない ＝ ネットワークが切れている」と短絡せず、TCP ポートでの疎通確認も必ず行いましょう。
Q. FW の IP 転送を有効化するのは危険ではありませんか？
A. IP 転送は「その NIC がルータとして振る舞えるようにする」設定であり、FW 製品のポリシーがザルになるわけではありません。
むしろ、IP 転送を有効にしないと FW として本来の働き（トラフィックを受けて別ネットワークへ転送する）ができません。セキュリティは FW のポリシーや NSG 側でしっかり制御しましょう。
今回のケースの最終結果
実際のトラブルでは、次の対応を行うことで問題は解決しました。
- 新ファイアウォールの NIC で IP 転送を有効化
- 172.20.* の各サブネットに対し、UDR を適用
- 宛先プレフィックス：172.21.0.0/16
- 次ホップの種類：Virtual appliance
- 次ホップ IP：新 FW の LAN 側 IP（例：172.21.1.4）
- NSG で ICMP 許可ルールを追加、もしくはテスト用に一時的な許可ルールを作成
これにより、172.20.* ↔ 172.21.* 間の双方向通信が可能となり、AVD から新ファイアウォール経由で外部への通信も通るようになりました。
まとめ：Azure VNet 間で通信できないときのチェックリスト
最後に、本記事の内容をチェックリストとして整理します。トラブル時の「一枚紙」としても活用できます。
| カテゴリ | チェック項目 | 確認結果（メモ用） |
|---|---|---|
| アドレス設計 | VNet 間でアドレス空間が重複していないか | |
| ピアリング | 双方向でピアリング済みか（状態：Connected） | |
| ピアリング | 「仮想ネットワーク アクセスを許可」「転送トラフィックを許可」が有効か | |
| FW 設定 | FW の LAN 側 NIC で IP 転送が有効か | |
| UDR | 宛先 172.21.0.0/16 → 次ホップ 新 FW IP のルートが存在し、該当サブネットに紐づいているか | |
| ルート | VM NIC の「有効なルート」で、期待した UDR が適用されているか | |
| NSG | 必要なポート（RDP/SSH/HTTPS 等）が NSG で許可されているか | |
| OS FW | Windows/Linux の OS ファイアウォールで、対象ポートが許可されているか | |
| DNS | IP では疎通できるか、名前解決も期待通りに動いているか |
Azure のネットワークは、一見すると複雑ですが、「アドレス空間」「ピアリング」「IP 転送」「UDR」「NSG」の 5 つを順番に確認していけば、ほとんどの VNet 間疎通トラブルはロジカルに解決できます。本記事の内容をベースに、自社環境に合わせてチェック項目をカスタマイズし、トラブルシューティングの標準手順として活用してみてください。
コメント