Azure VPN ゲートウェイをアクティブ‑スタンバイからアクティブ‑アクティブへ切り替える際、「3 つ目のパブリック IP が必要」というエラーに遭遇するケースがあります。本稿では、この“第3のパブリック IP”問題の正体を、設計背景・発生条件・回避策・手順・運用上の注意点まで掘り下げて解説します。ポータル操作に加え、PowerShell・CLI・IaC 例も網羅し、現場で迷わない実践的な手順書として使える内容にまとめました。
背景とよくある質問
質問：既存の VPN ゲートウェイ（アクティブ‑スタンバイ構成）を アクティブ‑アクティブ に変更しようとすると、Azure Portal や PowerShell で「3 つ目の IP 構成（＝3 個目のパブリック IP アドレス）が必要」と表示される。一方、最初からアクティブ‑アクティブで作成した場合は 2 個の IP で済む。この違いの理由と、実運用での回避策は？
結論（最短回答）
- 発生理由：P2S（ポイント対サイト）VPN 構成が残った状態でアクティブ‑アクティブ化すると、P2S の IKEv2 終端を冗長化・負荷分散するため、規定で第3のパブリック IP を要求する仕組みになっている。
- エラー：PowerShell 等で強制しようとしても
ActiveActiveP2SGatewayMustHaveExactlyThreeIpConfigurationsにより 400 Bad Request で拒否される。 - 回避策：（推奨）一旦 P2S 構成を削除してからアクティブ‑アクティブ化 → 必要なら後から P2S を再構成（この時点で第3 IP を求められる）／（代替）P2S を残したまま新規で 3 個目のパブリック IP を割り当てる。
- 影響：切り替え中はゲートウェイ再起動に伴い数分の瞬断が発生。オンプレ側では新しいゲートウェイ IP の許可が必要。既存 S2S は自動再接続されるのが一般的。
現象の全体像と設計背景
Azure VPN ゲートウェイをアクティブ‑アクティブで動かす場合、ゲートウェイ VM は 2 つのインスタンスで稼働し、それぞれが外向きにパブリック IP を持ちます。サイト間 VPN（S2S）だけであれば通常この 2 つで完結します。ところが、P2S を同居させていると、P2S クライアントの接続終端（IKEv2）を冗長化・負荷分散するために、別枠の IP 構成（3 個目）が必要になります。
【構成イメージ】
- ipconfig0 ─ パブリックIP#1（GW インスタンスA：S2S用）
- ipconfig1 ─ パブリックIP#2（GW インスタンスB：S2S用）
- ipconfig2 ─ パブリックIP#3（P2S IKEv2 の LB/終端用）★P2S 同居時のみ必須
このため、既存ゲートウェイに P2S が残ったままアクティブ‑アクティブを有効化すると、システム側は「P2S を HA 提供するには ipconfig が 3 つ必要」と判断し、3 個目のパブリック IP を求めるわけです。逆に、最初からアクティブ‑アクティブで構築して P2S をまだ設定していない場合は、S2S 用の 2 個だけで作成が完了します（P2S を後から有効化するタイミングで第3 IP を要求されます）。
“最初からアクティブ‑アクティブ” と “途中で切り替え” の違い
| 項目 | 新規（AA で最初から） | 既存（AS → AA 切替） |
|---|---|---|
| P2S 構成の有無 | 未設定なら 2 IP で作成可 | 残存していると第3 IP が必須 |
| 必要パブリック IP | 2（S2S 用）※P2S 追加時に＋1 | 3（S2S×2 + P2S×1） |
| 典型エラー | なし | ActiveActiveP2SGatewayMustHaveExactlyThreeIpConfigurations |
| 推奨対応 | そのまま 2 IP で構築 | P2S を一旦外す or 3 個目 IP を追加 |
ポータル／PowerShell での実際の挙動
PowerShell の Set-AzVirtualNetworkGateway -EnableActiveActiveFeature 等で強制的に切り替えようとしても、P2S 構成が残っていると 400 エラーが返ります。
Invoke-AzRestMethod : Operation failed with status: 'BadRequest'.
ErrorCode: ActiveActiveP2SGatewayMustHaveExactlyThreeIpConfigurations
Message: Active-Active P2S gateway must have exactly three ip configurations.
ポータル側のエラーメッセージが「Application Gateway に関連する設定が必要」といった文言で表示される場合がありますが、本質は VPN Gateway の仕様に起因します（文言上の表現がやや分かりづらいだけ、という理解で問題ありません）。
対応方針（2 択）
| 選択肢 | 内容 | メリット | デメリット | 向いているケース |
|---|---|---|---|---|
| 回避策①（推奨） | P2S を一旦削除 → AA 有効化（2 IP のまま）→ 必要なら P2S を再構成 | IP 資産を増やさず整理できる／構成がシンプル | 再構成まで P2S が使えない時間が生じる | 夜間メンテ等で P2S 停止許容がある環境 |
| 回避策② | 3 個目のパブリック IP を新規作成し、P2S 側に追加 | P2S を止めずに AA 化を進めやすい | パブリック IP が 1 つ増える／運用複雑度が上がる | P2S を止められない環境／短時間で終わらせたい |
前提条件と事前チェックリスト
- SKU・タイプ：ルートベース（RouteBased）であること。アクティブ‑アクティブはルートベースが前提。
- SKU 世代：既存 SKU（例：VpnGw1 以上）で AA がサポートされることを確認。
- パブリック IP SKU：新規作成するパブリック IP は通常 Standard を推奨（静的割り当て）。
- アドレス設計：VNet の
GatewaySubnetに十分なアドレス余裕があること。 - メンテナンス計画：数分の瞬断を考慮し、業務影響の少ない時間帯に実施。
- オンプレ機器：新しいゲートウェイのパブリック IP を事前に許可リストへ追加。
- バックアップ：P2S のルート証明書／RADIUS 設定／クライアントアドレスプールの控えをエクスポート。
手順：回避策①（推奨）— P2S を一旦外してから AA 化
ポータル操作の流れ
- 対象の VPN ゲートウェイで ポイント対サイト構成 を開き、無効化／削除（アドレスプール・証明書・RADIUS 設定を退避後に削除）。
- ゲートウェイ本体の設定から アクティブ‑アクティブ を有効化（この時点では 2 個のパブリック IP で完了）。
- 完了後、必要に応じて P2S を再構成（再構成の段で第3のパブリック IP を求められる場合あり）。
PowerShell 例
# 事前変数
$rg = "rg-network-prod"
$gw = "vpngw-hub-prod"
# 現状確認
Get-AzVirtualNetworkGateway -ResourceGroupName $rg -Name $gw | ` Select-Object Name,GatewayType,VpnType,ActiveActive,GatewaySku,@{N="IpConfigCount";E={$_.IpConfigurations.Count}},`
@{N="HasP2S";E={($_.VpnClientConfiguration -ne $null)}}
# アクティブ‑アクティブ有効化（P2S を外していることが前提）
Set-AzVirtualNetworkGateway -ResourceGroupName $rg -Name $gw -EnableActiveActiveFeature
# （必要なら）P2S を後から再構成する
# 例：IKEv2 + アドレスプールを設定（値は環境に合わせて）
$addr = New-Object System.Collections.Generic.List[string]
$addr.Add("172.16.10.0/24")
Set-AzVirtualNetworkGateway -ResourceGroupName $rg -Name $gw ` -VpnClientAddressPool $addr`
-VpnClientProtocol "IkeV2" 補足：実環境では RADIUS／証明書（ルート証明書公開キー）など、P2S の細部設定を合わせて再投入してください。ポータルのエクスポート機能や IaC の定義を活用すると確実です。
手順：回避策② — P2S を残したまま第3のパブリック IP を追加
ポータル操作の流れ
- パブリック IP（Standard/静的） を新規作成（名前例：
pip-vpngw-p2s）。 - VPN ゲートウェイの ポイント対サイト構成 を開き、「既存を使用」等の選択肢から上記パブリック IP を割り当てる（P2S 用の第3 IP）。
- 保存後、アクティブ‑アクティブ を有効化。以降は 3 IP 構成で運用。
PowerShell 例（第3 IP 作成）
$rg = "rg-network-prod"
$loc = "japaneast"
New-AzPublicIpAddress -Name "pip-vpngw-p2s" -ResourceGroupName $rg -Location $loc `
-Sku Standard -AllocationMethod Static
# 以降、P2S 構成画面（ポータル）で「既存のパブリック IP を使用」を選び、上記 IP を割り当てて保存
# その後に AA を有効化
I a C（Bicep / Terraform）での表現例
「アクティブ‑アクティブ + P2S 同居」の定義では、gatewayIpConfigurations が 3 つになる点が肝です。
Bicep 例（抜粋）
resource vpngw 'Microsoft.Network/virtualNetworkGateways@2023-04-01' = {
name: 'vpngw-hub-prod'
location: resourceGroup().location
properties: {
activeActive: true
gatewayType: 'Vpn'
vpnType: 'RouteBased'
sku: { name: 'VpnGw2', tier: 'VpnGw2' }
ipConfigurations: [
{ name: 'gw-ipconfig-0', properties: { subnet: { id: gatewaySubnet.id }, publicIPAddress: { id: pip0.id } } }
{ name: 'gw-ipconfig-1', properties: { subnet: { id: gatewaySubnet.id }, publicIPAddress: { id: pip1.id } } }
{ name: 'gw-ipconfig-2', properties: { subnet: { id: gatewaySubnet.id }, publicIPAddress: { id: pip2.id } } } // P2S 用
]
vpnClientConfiguration: {
vpnClientProtocols: [ 'IkeV2' ]
vpnClientAddressPool: [ '172.16.10.0/24' ]
// RADIUS や証明書等は適宜追加
}
}
}
Terraform 例（抜粋）
resource "azurerm_virtual_network_gateway" "hub" {
name = "vpngw-hub-prod"
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
type = "Vpn"
vpn_type = "RouteBased"
active_active = true
sku = "VpnGw2"
ip_configuration {
name = "gw-ipconfig-0"
public_ip_address_id = azurerm_public_ip.pip0.id
private_ip_address_allocation = "Dynamic"
subnet_id = azurerm_subnet.gateway.id
}
ip_configuration {
name = "gw-ipconfig-1"
public_ip_address_id = azurerm_public_ip.pip1.id
private_ip_address_allocation = "Dynamic"
subnet_id = azurerm_subnet.gateway.id
}
ip_configuration {
name = "gw-ipconfig-2" # P2S 用
public_ip_address_id = azurerm_public_ip.pip2.id
private_ip_address_allocation = "Dynamic"
subnet_id = azurerm_subnet.gateway.id
}
vpn_client_configuration {
vpn_client_address_pool = ["172.16.10.0/24"]
vpn_client_protocols = ["IkeV2"]
}
} 切り替え時の影響とダウンタイムの扱い
| 対象 | 影響 | 対応 |
|---|---|---|
| S2S（オンプレ拠点との IPsec） | ゲートウェイ再起動に伴い数分の瞬断。トンネルは自動再接続が一般的。 | メンテ時間を確保。オンプレ機器に新しいゲートウェイ IP を事前許可。 |
| P2S クライアント | 回避策①では再構成まで一時停止。回避策②では継続利用可だが再接続が入る可能性。 | 周知・業務調整。クライアント側の再接続を促す案内を準備。 |
| ルーティング | 基本的にテーブルの再設計は不要。BGP を使っている場合もピアは維持される想定。 | 念のため経路収束時間と許容ダウンを計画に反映。 |
トラブルシューティングの要点
- エラーコードで判断：
ActiveActiveP2SGatewayMustHaveExactlyThreeIpConfigurationsが出たら P2S 同居を疑う。 - 構成カウントを確認：PowerShell で
IpConfigurations.CountとVpnClientConfigurationの有無をチェック。 - ポータル表示の文言に惑わされない：Application Gateway 由来に見える表現でも、実態は VPN Gateway の制約であることが多い。
- GatewaySubnet のサイズ：小さすぎると更新に失敗することがある。/27 以上を目安に余裕を確保。
- パブリック IP の SKU／割当：Standard / Static を基本とし、地域・ゾーン冗長の方針と整合を取る。
よくある質問（FAQ）
Q1：最初からアクティブ‑アクティブで作った場合、本当に 2 IP だけでいいの？
A：P2S をまだ設定していなければ 2 IP で作成完了します。後から P2S を有効にする時点で、P2S 用の第3 IP を求められます。
Q2：P2S を OpenVPN のみで使っていても第3 IP は必要？
A：P2S 構成をゲートウェイに同居させる設計そのものが「P2S 終端の高可用性」を前提に 3 つ目の IP 構成を要求します。IKEv2／OpenVPN の選択に関わらず、P2S が有効なら 3 IP の設計になると考えるのが安全です。
Q3：第3 IP を追加した後、オンプレ側は何を変える？
A：S2S の対向は引き続き 2 つのゲートウェイ IP（インスタンス A/B）です。P2S 用の第3 IP はエンドユーザー接続のためのもので、オンプレのトンネル設定自体は通常変更不要です。ただし、ファイアウォールのアウトバウンド許可や監視対象への登録は環境に応じて見直してください。
Q4：Basic SKU からの切り替えや SKU 変更は？
A：アクティブ‑アクティブはルートベースの現行 SKU（VpnGw1 以上）が前提です。旧構成からの移行は、可能であれば新規作成→切替（スワップ）を検討すると安定します。
Q5：ダウンタイムをさらに短くしたい。
A：回避策②で P2S を残したまま第3 IP を先に準備し、業務時間外に AA の切替操作のみ行うと、体感停止時間を最小化しやすくなります。接続数が多い場合は段階的に拠点ごと・ユーザーグループごとに切替を進めるのも有効です。
運用ベストプラクティス
- 命名一貫性：
gw-ipconfig-0/1/2のように役割が分かる命名にする（0/1= S2S、2= P2S）。 - IaC で差分管理：Bicep/Terraform に 3 本の ipConfig を明示し、変更差分をレビュー可能に。
- 監視と可視化：接続数・再接続回数・トンネル状態をログ分析でトレンド化し、切替直後の安定性を確認。
- フェイルオーバー訓練：定期的に意図的な再起動／フェイルオーバーを行い、S2S/P2S の復旧時間を計測しておく。
- 証明書／RADIUS ライフサイクル：P2S を証明書ベースで運用している場合はルート証明書の更新計画を前倒しで整備。
参考のコマンド／確認ポイント集
現状の構成確認（PowerShell）
$g = Get-AzVirtualNetworkGateway -ResourceGroupName $rg -Name $gw
$g.ActiveActive
$g.IpConfigurations.Count
$g.VpnClientConfiguration # null なら P2S 未設定
現状の構成確認（Azure CLI）
az network vnet-gateway show -g <rg> -n <gw> --query "{activeActive:activeActive, ipConfigCount:length(ipConfigurations), hasP2S: (vpnClientConfiguration!=null)}"
パブリック IP の作成（Azure CLI）
az network public-ip create -g <rg> -n pip-vpngw-p2s --sku Standard --allocation-method Static
運用の落とし穴と回避策まとめ
| 落とし穴 | 起きる理由 | 回避策 |
|---|---|---|
| AA 化で突然「第3 IP 必須」エラー | P2S が残存しており、P2S 終端の HA に 3 つ目の ipConfig が必要 | P2S を一旦外す or 第3 IP を事前に追加 |
| ポータルの文言が Application Gateway 風 | UI 表現が紛らわしいケースがある | 根本は VPN Gateway 側の制約。動作原理に立ち返って判断 |
| 切替中の想定外の通信断 | ゲートウェイ再起動・セッション再確立 | 夜間メンテ／SLA 告知／自動再接続の事前テスト |
| GatewaySubnet の枯渇 | アドレス設計がタイト | /27 以上で余裕を確保、将来の増設を見込む |
要点の最終整理
- P2S 構成があるゲートウェイをアクティブ‑アクティブ化する場合は第3 IP が必須（エラーコードで明示）。
- 選択肢は 「P2S を一度外す」 か 「3 つ目のパブリック IP を追加」 の二択。運用要件で選ぶ。
- 切替時は数分の瞬断を前提に、業務影響が小さい時間帯に実施。オンプレ機器の許可リスト更新を忘れずに。
- IaC 化・監視・フェイルオーバー訓練で、変更の再現性と可用性を高める。
付録：現場で役立つチェックシート
| チェック項目 | OK/NG | メモ |
|---|---|---|
| Gateway は RouteBased / VpnGw SKU か | ||
| P2S 設定のバックアップ済みか（証明書/RADIUS/アドレスプール） | ||
| 第3 パブリック IP（Standard/Static）を用意済みか（回避策②時） | ||
| GatewaySubnet のアドレスに余裕があるか（/27 以上推奨） | ||
| オンプレ FW に新しいゲートウェイ IP を事前許可したか | ||
| メンテ告知・ロールバック案（切替失敗時の手順）を用意したか |
まとめ
“第3 のパブリック IP”問題は、設計の欠陥ではなく、P2S を高可用に提供するための意図的な仕様です。アクティブ‑アクティブ化の前に「P2S を一旦外す」か「先に第3 IP を用意する」かを選び、手順通りに進めれば、短時間の瞬断に抑えながら安全に移行できます。構成の見通しを良くするには、ipConfig の役割を明確化し、IaC で 3 本の構成を宣言的に管理することが近道です。現場で迷いやすいポイント—エラーコードの読み解き、ポータル文言の解釈、オンプレ側の許可更新—を事前に押さえておけば、移行は落ち着いて遂行できます。
Q&A スナップショット（超要約）
| 項目 | 内容 |
|---|---|
| 理由 | P2S（IKEv2 等）を冗長化するため、AA では第3 の IP 構成を要求 |
| PowerShell の挙動 | ActiveActiveP2SGatewayMustHaveExactlyThreeIpConfigurations の 400 で拒否 |
| 回避策①（推奨） | P2S を一旦削除 → AA 有効化（2 IP のまま）→ 必要に応じ P2S 再構成 |
| 回避策② | 第3 のパブリック IP を作成し、P2S に割り当ててから AA 化 |
| 影響・ダウンタイム | ゲートウェイ再起動に伴う数分の瞬断。S2S は再接続、オンプレ側の許可更新を推奨 |
| ポータルのエラーメッセージ | Application Gateway 風に見える表現でも、実際は VPN Gateway 仕様の結果 |
コメント