Application Gateway：Public/Privateリスナーを同一ポートで利用する際のNSG要件と罠
Application Gateway v2を運用している環境で、既存のパブリックリスナーに加えてプライベートリスナーを追加しようとした際、以下のようなエラーに遭遇することがあります。
Failed to save application gateway changes
Application Gateway とネットワーク セキュリティ グループの構成が競合しているため、変更を保存できませんでした。
このエラーは、次のようにパブリックとプライベートのフロントエンドIPで同じポート（例: 80/TCP）を共有している構成で頻発します。
-
Public Frontend IP:
20.1.1.1(Port 80) -
Private Frontend IP:
10.0.0.10(Port 80)
本記事では、なぜこのエラーが発生するのか、そしてNSGにどのような設定が必要になるのかを分かりやすく解説します。
1. 従来のNSG設定（これまでの前提）
一般的なApplication GatewayのNSG設定では、サブネット全体を宛先とする次のような「受信許可ルール」を構成するのが主流です。
| 方向 | ソース | 宛先 (Destination) | ポート | アクション |
|---|---|---|---|---|
| Inbound | Any |
Application Gateway Subnet (例: 10.0.1.0/24) |
80, 443
|
Allow |
この構成では、NSGは「Application Gatewayが配置されているサブネット宛ての通信」を一括で許可しています。
2. なぜNSGの競合エラーが発生するのか？
Public ListenerとPrivate Listenerが同じポートを共有した場合、Application Gatewayの受信トラフィックの評価方法が変わります。
例えば、どちらのリスナーもポート 80 を使用している場合、Application Gatewayは以下の2つを厳密に区別してリスナーを選択する必要があります。
-
20.1.1.1:80(Public) -
10.0.0.10:80(Private)
そのため、Azureは受信トラフィックの宛先を従来の 「Application Gateway Subnet」 ではなく、「各フロントエンド IP (Frontend IP)」 ベースで評価するよう仕様が変化します。
Microsoft公式の見解
アクティブなパブリックおよびプライベート リスナーを同じポート番号で構成すると、Application Gateway は受信フローの宛先をフロントエンド IP として扱います。
結果として、サブネット宛ての許可ルールだけではAzure側の検証をパスできず、前述のエラーが発生してしまいます。
3. 必要となる具体的なNSGルール
上記仕様変更に伴い、NSGにはサブネット宛てとは別に、個別のフロントエンドIP宛ての許可ルールを追加する必要があります。
例として、以下のIP・ポートを使用している場合の追加設定を示します。
- Public Frontend:
20.1.1.1 - Private Frontend:
10.0.0.10 - 共通ポート:
80
① Public Frontend 用のルール
| 項目 | 設定値 |
|---|---|
| Direction | Inbound |
| Source | Any |
| Destination |
20.1.1.1 (パブリックIP) |
| Protocol | TCP |
| Port | 80 |
| Action | Allow |
② Private Frontend 用のルール
| 項目 | 設定値 |
|---|---|
| Direction | Inbound |
| Source | Any |
| Destination |
10.0.0.10 (プライベートIP) |
| Protocol | TCP |
| Port | 80 |
| Action | Allow |
4. よくある誤解と注意点
💡 注意点1：従来の「サブネット宛てルール」は削除してもいいのか？
答えは No です。
既存の Destination = Application Gateway Subnet のルールは削除せず、そのまま残しておく必要があります。今回必要になるのは、既存ルールの代替ではなく「追加要件」です。
💡 注意点2：「ポートを共有していないリスナー」への影響
もう一つハマりやすいポイントとして、一部のポート（例: 80）だけでPublic/Privateの共有を行っていたとしても、同じApp Gateway内に一度でも「Public + Private + 同一ポート」の組み合わせが存在するだけで、App Gateway全体がフロントエンドIPベースでの検証に切り替わります。
そのため、80番ポートを共有したことで、共有していない他のポート（例: 443など）についても、Frontend IP宛ての許可ルールを求められるケースがあるため注意してください。
まとめ
Application GatewayでPublic ListenerとPrivate Listenerに同じポート番号を使用する場合のチェックリストです。
-
現象: 構成変更時に
Failed to save application gateway changesエラーが発生する。 - 原因: 同一ポートの共有により、NSGの宛先評価が「サブネット」から「各フロントエンドIP」に変わるため。
-
対策: NSGに
Destination = Public Frontend IPおよびDestination = Private Frontend IPの受信許可ルールを追加する。
App Gatewayの設計やスケール変更時にNSGの競合エラーが出たら、まずはNSGの宛先がサブネット単位になっていないか、フロントエンドIP単位のルールが必要になっていないかを確認しましょう！