Azure VPN GatewayでIPv6が通らないときの直し方｜S2S・P2S設定を切り分ける

Azure VPN Gatewayで「Site-to-Site VPNではIPv6通信できるのに、Point-to-Site VPNクライアントからは接続できない」、あるいはその逆になる場合、最初に疑うべきなのは障害ではなくS2SとP2Sの設定対象の違いです。

S2Sでは、IPv6パケットをIPsec/IKEトンネルの内側に通すため、IKEv2、Local network gatewayのIPv6プレフィックス、オンプレミス側の経路設定が必要です。一方、P2Sでは、クライアントへIPv6アドレスを割り当てるアドレスプールと、接続先IPv6プレフィックスへのルート、更新済みのVPNクライアントプロファイルを確認しなければなりません。(Microsoft Learn)

つまり、次の順番で確認するのが最短です。

利用しているVPNプロトコル
IPv6アドレスまたはプレフィックスの割り当て
クライアントと拠点側のIPv6ルート
戻り経路
NSG、ファイアウォール、NVAのIPv6許可設定

S2SとP2Sで異なるIPv6設定ポイント：IPsec/IKE内部通信とクライアントアドレスプール

S2SとP2Sは、同じAzure VPN Gatewayを利用していても、IPv6通信を成立させるための設定が異なります。

確認項目	Site-to-Site VPN	Point-to-Site VPN
主な用途	オンプレミス拠点とAzure VNetの接続	PCなど個別クライアントとAzure VNetの接続
IPv6の送信元	オンプレミスネットワークのIPv6プレフィックス	P2Sクライアントアドレスプールから割り当てられたIPv6
対応プロトコル	IKEv2	IKEv2またはOpenVPN
非対応となる構成	IKEv1によるIPv6通信	SSTPによるIPv6通信
Azure側の重要設定	Local network gatewayのIPv6プレフィックス	P2SのIPv6クライアントアドレスプール
接続元側の重要設定	VPN装置のIPv6経路、暗号化対象、戻り経路	VPNアダプターのIPv6アドレス、クライアントルート
よくある原因	IPv4プレフィックスしか登録されていない	IPv6アドレスプールまたは経路が配布されていない
トンネル外側のIPv6	非対応	非対応

Azure VPN GatewayのIPv6対応は、VPNトンネルの外側をIPv6化する機能ではありません。S2SではIPv6をIPsec/IKEトンネルの内部トラフィックとして運びます。P2SはルートベースのVPN Gatewayを使用し、IKEv2またはOpenVPNで接続します。(Microsoft Learn)

Azure VPN GatewayのIPv6はトンネルの「内側」を通る

Azure VPN Gatewayのdual-stack modeでは、IPv4とIPv6の両方をVNet内で利用できます。ただし、IPv6が使われるのはVPNトンネル内を流れるデータ部分です。

次のような構成になります。

オンプレミスIPv6端末
        ↓ IPv6パケット
オンプレミスVPN装置
        ↓
IPv4のVPNトンネル外側
        ↓
IPsec/IKEトンネル内部にIPv6を格納
        ↓
Azure VPN Gateway
        ↓ IPv6パケット
Azure VNet内のIPv6対応リソース

そのため、オンプレミスVPN装置やAzure VPN Gatewayの接続先パブリックIPをIPv6に変更しようとしても解決しません。確認すべきなのは、トンネル内部へIPv6プレフィックスが正しくルーティングされているかどうかです。

dual-stack modeの共通前提

現在のMicrosoft Learnに記載されている主な前提は次のとおりです。(Microsoft Learn)

項目	確認内容
Gateway SKU	VpnGw1AZからVpnGw5AZ
VPN方式	ルートベース
VNetアドレス空間	IPv4とIPv6の両方を登録
GatewaySubnet	IPv4とIPv6の両方を設定
S2SのIPv6	IKEv2を使用
P2SのIPv6	IKEv2またはOpenVPNを使用
P2SのSSTP	IPv6は非対応
Basic SKU	IPv6は非対応
トンネル外側のIPv6	非対応

VNetのアドレス空間だけをdual-stackにしても不十分です。GatewaySubnet、VPN Gateway、接続先プレフィックス、実際に通信するサブネットやリソースまで、一貫してIPv6を設定する必要があります。

また、dual-stackに構成したVPN GatewayはIPv4専用構成へ戻せないという制約があります。Microsoft Learnの更新情報ではVPN GatewayのIPv6 dual-stack機能はPreviewとして掲載されているため、本番環境ではサポート条件、変更手順、切り戻し方法を事前に確認してください。(Microsoft Learn)

S2SだけIPv6が通らないときの直し方

P2SからはIPv6通信できるのにS2Sだけ失敗する場合、Azure VNetや接続先リソースのIPv6設定はおおむね機能していると考えられます。

この場合は、S2S固有の次の設定へ絞って確認します。

IKEv2で接続しているか確認する

S2SでIPv6内部通信を利用するにはIKEv2が必要です。IPv4通信が正常でも、接続がIKEv1であればIPv6は通りません。

確認対象は次のとおりです。

Azure VPN Gatewayの接続設定
オンプレミスVPN装置のIKEバージョン
接続ポリシーやVPNテンプレート
IPv4用とIPv6用で異なるポリシーが適用されていないか

VPN接続のステータスが「接続済み」であることだけでは、IPv6が正しく通っている証明にはなりません。IKEトンネルが確立していても、IPv6プレフィックスが経路や暗号化対象に含まれていなければ、IPv4だけが通信できます。

Local network gatewayにオンプレミスIPv6プレフィックスを登録する

Azure側は、Local network gatewayに登録されたアドレスプレフィックスを基に、どの通信をオンプレミスへ送るか判断します。

たとえば、次の構成を考えます。

用途	プレフィックス例
Azure VNet	`fd20:10::/48`
Azureの接続先サブネット	`fd20:10:1::/64`
オンプレミスネットワーク	`fd20:20::/48`

この場合、Local network gatewayにはオンプレミス側のfd20:20::/48を登録します。オンプレミス側では、Azure側のfd20:10::/48をVPNトンネルへ向けます。

どちらか一方だけでは、片方向通信や応答が返らない状態になります。

PowerShellでLocal network gatewayのアドレスプレフィックスを更新する例は次のとおりです。

$lng = Get-AzLocalNetworkGateway `
  -Name "lng-onprem" `
  -ResourceGroupName "rg-network"

Set-AzLocalNetworkGateway `
  -LocalNetworkGateway $lng `
  -AddressPrefix @(
    "10.20.0.0/16",
    "fd20:20::/48"
  )

Set-AzLocalNetworkGatewayでアドレスプレフィックスを更新する場合、既存の一覧が新しい指定内容で置き換わります。IPv6プレフィックスだけを指定すると、既存のIPv4プレフィックスを消してしまう可能性があります。更新時は、残すIPv4とIPv6の全プレフィックスを含めてください。(Microsoft Learn)

オンプレミスVPN装置のIPv6経路を確認する

オンプレミス側では、少なくとも次の3点を確認します。

Azure VNetのIPv6プレフィックスがVPNインターフェースへ向いている
オンプレミスのIPv6プレフィックスがトンネル対象に含まれている
Azureから戻ってきたIPv6通信を内部LANへ転送できる

ルートベースVPNでも、機器によっては暗号化ドメイン、Proxy ID、トラフィックセレクターなどの名称で対象プレフィックスを明示します。その場合、IPv4プレフィックスだけでなく、Azure側とオンプレミス側のIPv6プレフィックスも登録します。

また、VPN装置自身に経路があっても、その上位ルーターやL3スイッチに戻り経路がなければ通信は成立しません。オンプレミス端末から見たデフォルトゲートウェイが、Azure向けIPv6通信を正しくVPN装置へ渡しているか確認してください。

NSGとファイアウォールをIPv6で確認する

IPv4の許可ルールがあっても、同じルールがIPv6通信に適用されるとは限りません。

次の箇所を確認します。

AzureサブネットのNSG
Azure VMのNICに関連付けたNSG
Azure FirewallやサードパーティーNVA
オンプレミスVPN装置のフィルタールール
サーバーOSのホストファイアウォール
アプリケーションの待ち受けアドレス

たとえば、WebサーバーがIPv4の0.0.0.0:443だけで待ち受け、IPv6の[::]:443では待ち受けていない場合、ネットワーク経路が正しくてもIPv6接続は失敗します。

P2SだけIPv6が通らないときの直し方

S2SではIPv6通信できるのにP2Sクライアントだけ接続できない場合、Azure VNet、GatewaySubnet、接続先リソースのIPv6設定は機能している可能性が高くなります。

この場合は、P2S固有の次の4要素を順番に確認します。

要素	役割	未設定時の典型的な症状
VPNプロトコル	IPv6対応方式で接続する	VPN接続はできてもIPv6を利用できない
IPv6クライアントアドレスプール	クライアントへIPv6送信元アドレスを割り当てる	VPNアダプターにIPv6アドレスが付かない
IPv6宛先ルート	対象プレフィックスをVPNへ送る	IPv6アドレスはあるが通信がVPNへ流れない
戻り経路と許可ルール	応答をクライアントへ返す	パケットを送信しても応答がない

IKEv2またはOpenVPNを使用する

P2SのIPv6対応プロトコルは、IKEv2とOpenVPNです。SSTPではIPv6を利用できません。(Microsoft Learn)

現在の接続がSSTPの場合は、Azure VPN GatewayのPoint-to-site configurationでトンネル種類を見直し、対応するVPNクライアントプロファイルを再配布します。

Microsoft Entra ID認証を利用する構成では、OpenVPNを使用します。証明書認証やRADIUS認証では複数の選択肢がありますが、OS、認証方式、IPv6対応の3条件を合わせて選ぶ必要があります。(Microsoft Learn)

P2SのIPv6クライアントアドレスプールを設定する

P2SクライアントがIPv6通信を開始するには、VPNアダプターへIPv6アドレスを割り当てる必要があります。

Azureポータルでは、Virtual network gatewayのPoint-to-site configurationにあるAddress poolへ、既存のIPv4プールとIPv6プールを設定します。

イメージは次のとおりです。

172.20.10.0/24, <P2Sクライアント用IPv6プレフィックス>

Microsoftの構成例でも、P2SのAddress poolへIPv4とIPv6の両方を登録する画面が示されています。(GitHub)

IPv6プールを選ぶ際は、次の範囲と重複させないようにします。

Azure VNetのIPv6アドレス空間
オンプレミスのIPv6プレフィックス
他のP2Sクライアントプール
接続元ネットワークで利用しているプレフィックス
将来接続する予定のVNetや拠点のプレフィックス

ここで重要なのは、クライアントアドレスプールは宛先ルートではないという点です。

クライアントアドレスプールは「P2Sクライアント自身が使用する送信元アドレス」を決めます。Azure VNetやオンプレミスネットワークへ到達するための経路は、別にクライアントルートとして必要です。

VPNクライアントプロファイルを再生成する

Azure側のP2S設定を変更しても、端末に保存されている古いVPNプロファイルへ自動反映されるとは限りません。

IPv6アドレスプールや接続対象のネットワークを変更した後は、次の手順を実施します。

P2S設定を保存する
VPNクライアントプロファイルを再生成する
最新のプロファイルをダウンロードする
既存プロファイルを更新または再インポートする
VPNを切断して再接続する
VPNアダプターのIPv6アドレスとルートを確認する

特にWindowsクライアントでは、VNetピアリングや接続トポロジーを変更した後、更新された経路を受け取るためにVPNクライアントパッケージの再ダウンロードが必要になる構成があります。(Microsoft Learn)

クライアントにIPv6ルートが配布されているか確認する

P2SクライアントにIPv6アドレスが割り当てられていても、接続先IPv6プレフィックスへのルートがなければ、パケットはVPNへ流れません。

Windowsでは次のコマンドで確認できます。

Get-NetIPAddress -AddressFamily IPv6 |
  Sort-Object InterfaceAlias, IPAddress

Get-NetRoute -AddressFamily IPv6 |
  Sort-Object DestinationPrefix

route print -6

確認するのは、VPNアダプターにIPv6アドレスがあるか、目的のIPv6プレフィックスがVPNインターフェースへ向いているかの2点です。

たとえば、接続先がfd20:10:1::/64である場合、そのプレフィックスを包含するルートが必要です。ルートがなく、デフォルトのIPv6ルートだけが物理LANやWi-Fiへ向いている場合、VPN Gatewayには届きません。

直接接続されたVNet以外へ通信する場合は、追加確認が必要です。

ピアリング先VNet
S2Sの先にあるオンプレミスネットワーク
ハブ・スポーク構成のスポークVNet
Azure FirewallやNVAの背後にあるネットワーク
BGPで学習させているプレフィックス

必要なプレフィックスがクライアントへ配布されない場合は、P2S設定のカスタムルートやAdditional routes、BGP、ピアリング設定を確認します。Azure VPN GatewayではP2Sクライアントへカスタムルートを通知できますが、接続トポロジーとクライアントOSによって経路の受け取り方が異なります。(Microsoft Learn)

P2Sクライアントプールへの戻り経路を確認する

クライアントからパケットを送信できても、接続先からP2SクライアントのIPv6プールへ応答を返せなければ通信は成立しません。

特に次の構成では戻り経路を明示的に確認します。

Azure FirewallやNVAを経由する
ユーザー定義ルートを適用している
P2SからS2S経由でオンプレミスへ接続する
複数のハブVNetを経由する
オンプレミス側で静的ルートを使用している

P2SからS2S経由でオンプレミスへIPv6接続する場合は、オンプレミス側がP2SのIPv6クライアントプールへの戻り経路を持っているか確認します。

たとえば、次の構成です。

P2SクライアントIPv6プール
        ↓
Azure VPN Gateway
        ↓
S2Sトンネル
        ↓
オンプレミスIPv6サーバー

往路だけ設定され、オンプレミス側がP2Sプールを知らない場合、サーバーからの応答が別のゲートウェイへ流れてしまいます。

症状から原因を最短で絞り込む

症状	優先して確認する項目
S2SのIPv4は通るがIPv6だけ通らない	IKEv2、Local network gatewayのIPv6プレフィックス、オンプレミス側ルート
P2S接続後もVPNアダプターにIPv6がない	IPv6クライアントアドレスプール、利用プロトコル、クライアントプロファイル
P2SにIPv6アドレスはあるが通信できない	IPv6宛先ルート、追加ルート、戻り経路
P2Sは通るがS2Sだけ通らない	オンプレミスVPN装置のIPv6設定、暗号化対象、Local network gateway
S2Sは通るがP2Sだけ通らない	P2Sプロトコル、IPv6プール、プロファイル、クライアントルート
S2SとP2Sの両方で通らない	VNet、GatewaySubnet、Gateway SKU、接続先NIC、NSG
Azureからの応答だけ返らない	戻り経路、NSG、NVA、ホストファイアウォール
ピアリング先だけ接続できない	ピアリング、ゲートウェイトランジット、追加ルート、プロファイル更新
ホスト名では失敗し、IPv6直指定では成功する	DNS、AAAAレコード、カスタムDNSサーバー
pingは失敗するがアプリは動く	ICMPv6だけが遮断されている可能性

この表を使うと、S2SとP2Sの共通部分を調べるべきか、それぞれ固有の設定を調べるべきかを早く判断できます。

たとえばP2SでIPv6通信できている場合、Azure側の接続先サブネット、対象リソース、NSGは少なくともP2Sの経路上では正常である可能性が高くなります。そこでS2S側のIKEv2、Local network gateway、オンプレミスルートへ調査範囲を絞れます。

Windowsクライアントで確認するコマンド

IPv6アドレスを確認する

Get-NetIPAddress -AddressFamily IPv6 |
  Format-Table InterfaceAlias, IPAddress, PrefixLength, AddressState

VPNアダプターにP2S用IPv6プールのアドレスが割り当てられているか確認します。

リンクローカルアドレスであるfe80::から始まるアドレスしかない場合、P2S用IPv6アドレスが正常に割り当てられていない可能性があります。

IPv6ルートを確認する

Get-NetRoute -AddressFamily IPv6 |
  Format-Table DestinationPrefix, NextHop, InterfaceAlias, RouteMetric

接続先プレフィックスがVPNアダプターへ向いているか確認します。

複数の一致するルートがある場合は、より長いプレフィックスが優先されます。同じプレフィックス長で競合する場合は、メトリックも確認してください。

実際のサービスポートで確認する

Test-NetConnection `
  -ComputerName "<接続先IPv6アドレス>" `
  -Port 443 `
  -InformationLevel Detailed

経路確認には次のコマンドも利用できます。

tracert -6 <接続先IPv6アドレス>

IPv6アドレスをURLへ直接指定する場合は、角括弧で囲みます。

https://[IPv6アドレス]/

pingだけで判断するのは避けてください。ICMPv6がファイアウォールで拒否されていても、HTTPSやSSHなどの実際のサービスは通信できる場合があります。

Azure側で確認する場所

Azureポータルでは、次の順番で確認すると効率的です。

Virtual network

IPv4とIPv6のアドレス空間が登録されている
接続先サブネットにIPv6プレフィックスがある
他のVNetやオンプレミスと重複していない

GatewaySubnet

IPv4プレフィックスだけでなくIPv6プレフィックスもある
GatewaySubnetへ不適切なルートや制御を追加していない

Virtual network gateway

dual-stack対応SKUを使用している
ルートベースで作成されている
S2SはIKEv2で接続している
P2SはIKEv2またはOpenVPNを使用している
P2S Address poolにIPv6プレフィックスがある

Local network gateway

オンプレミスのIPv4プレフィックスがある
オンプレミスのIPv6プレフィックスがある
BGPを利用する場合は学習対象が想定どおりである

接続先リソース

NICやサブネットにIPv6構成がある
NSGがIPv6送信元を許可している
アプリケーションがIPv6で待ち受けている
NVAやホストファイアウォールがIPv6を拒否していない

よくある設定ミス

S2SとP2Sを一つのIPv6スイッチとして考える

dual-stack modeを有効にすればS2SとP2Sの両方が自動的に使えるわけではありません。

S2SではオンプレミスIPv6プレフィックスと経路、P2SではクライアントIPv6プールとクライアントルートを別々に設定します。

P2SのAddress poolだけ設定して完了する

Address poolはクライアントの送信元アドレスを割り当てる設定です。接続先へのルートや戻り経路を保証する設定ではありません。

VPNアダプターへIPv6アドレスが付いた後も、必ずGet-NetRouteやroute print -6で宛先ルートを確認します。

設定変更後も古いクライアントプロファイルを使う

Azure側へIPv6プレフィックスを追加しても、古いクライアントプロファイルには新しい経路や接続設定が含まれていない可能性があります。

設定変更後は、プロファイルの再生成、再ダウンロード、再インポートまでを一連の作業として扱います。

Local network gateway更新時にIPv4プレフィックスを消す

IPv6プレフィックスだけを指定して更新すると、既存のIPv4プレフィックスが一覧から消える場合があります。

変更前の値を控え、IPv4とIPv6を含む完全なプレフィックス一覧で更新してください。

IPv4用ファイアウォールルールだけを確認する

IPv4で通信できることは、IPv6でも許可されている証明にはなりません。

送信元として、オンプレミスIPv6プレフィックスまたはP2S IPv6クライアントプールが許可されているか確認します。

NAT64で解決しようとする

Azure VPN GatewayのNATは、IPsecを使用したクロスプレミス接続を対象とする機能で、P2Sには対応していません。また、VPN GatewayはNAT64をサポートしていません。

そのため、IPv4しか持たないP2SクライアントをVPN GatewayのNAT64でIPv6リソースへ接続させる方法は利用できません。P2S側へIPv6クライアントアドレスプールとルートを正しく設定する必要があります。(Microsoft Learn)

DNSの問題をネットワーク障害と誤認する

ホスト名で接続できない場合は、最初にIPv6アドレスを直接指定してテストします。

直接指定で成功する場合は、次を確認します。

AAAAレコードが登録されているか
P2Sクライアントが利用するDNSサーバー
カスタムDNSサーバーへの経路
DNSサーバーがIPv6の問い合わせへ応答できるか
古いDNSキャッシュが残っていないか

安全に設定変更する手順

本番環境では、S2SとP2Sを同時に変更するより、通信経路ごとに確認した方が原因を追いやすくなります。

変更前に4種類のプレフィックスを整理する

最初に次の値を一覧化します。

区分	記録する内容
Azure	VNetと各サブネットのIPv6プレフィックス
オンプレミス	Azureと通信するIPv6プレフィックス
P2S	クライアントへ割り当てるIPv6プレフィックス
接続先	実際に到達させるサーバーやネットワークのIPv6プレフィックス

重複、登録漏れ、不要に大きなプレフィックスがないかを確認します。

S2Sを先に検証する場合

VNetとGatewaySubnetのdual-stack構成を確認する
S2SがIKEv2であることを確認する
Local network gatewayへオンプレミスIPv6プレフィックスを登録する
オンプレミス側へAzure IPv6プレフィックスのルートを設定する
NSGとファイアウォールを確認する
IPv6アドレスを直接指定して通信テストする

P2Sを先に検証する場合

IKEv2またはOpenVPNを選択する
P2S IPv6クライアントアドレスプールを設定する
必要なIPv6宛先ルートを設定する
クライアントプロファイルを再生成する
VPN接続後のIPv6アドレスを確認する
クライアントルートを確認する
実際のサービスポートで接続テストする

最後に通信マトリクスで確認する

テスト	確認結果
オンプレミスからAzureへIPv4	成功・失敗
オンプレミスからAzureへIPv6	成功・失敗
Azureからオンプレミスへの応答	成功・失敗
P2SクライアントからAzureへIPv4	成功・失敗
P2SクライアントからAzureへIPv6	成功・失敗
P2Sクライアントからピアリング先へIPv6	成功・失敗
P2SクライアントからS2S先へIPv6	成功・失敗
ホスト名によるIPv6接続	成功・失敗
IPv6アドレス直接指定	成功・失敗

この結果を残しておくと、経路変更後にどの通信だけが失敗したかを比較できます。

まとめ

Azure VPN GatewayでS2SとP2SのIPv6動作が一致しない場合は、両者を別の通信経路として切り分けます。

S2Sで重要なのは、IKEv2、IPsec/IKEトンネル内部のIPv6通信、Local network gatewayのIPv6プレフィックス、オンプレミス側の経路です。

P2Sで重要なのは、IKEv2またはOpenVPN、IPv6クライアントアドレスプール、クライアントへ配布されるIPv6ルート、更新済みのVPNプロファイルです。

トラブル時は、次の順番で確認してください。

対応プロトコル
  ↓
IPv6アドレスまたはプレフィックス
  ↓
宛先ルート
  ↓
戻り経路
  ↓
NSG・ファイアウォール
  ↓
DNSとアプリケーションの待ち受け

まず、Azure VNet、オンプレミス、P2Sクライアントプール、接続先の4種類のIPv6プレフィックスを書き出します。そのうえで、S2SならLocal network gateway、P2SならAddress poolとクライアントルートを確認するのが、最も効率的な解決手順です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。