MENU

Azure P2S VPN「Policy Match error 13868」と「管理者権限が必要」の完全対処ガイド｜Virtual WAN・Windowsでの原因と解決策

Azure

Azure Virtual WAN の Hub‑P2S（証明書認証）で Windows クライアントから接続した際、「この接続には昇格された特権が必要です」と表示された直後に Policy Match error 13868（ERROR_IPSEC_IKE_POLICY_MATCH）で失敗する、もしくは接続は成功するが社内リソースへ到達できない――という相談は非常に多い課題です。本記事はその三点（昇格の方法／13868 の原因と対処／接続後に到達しない理由）を、現場で役立つ手順と検証コマンド込みで体系的に解説します。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

対象とする前提環境

  • Azure Virtual WAN（仮想ハブ）で構成した Point‑to‑Site VPN（P2S, IKEv2＋証明書）
  • Azure からダウンロードした VpnClientSetupAmd64.exe を使用し、Windows 10/11 にプロファイルをインストール
  • Windows 標準の IKEv2 クライアント（RAS/rasphone/rasdial）で接続

※OpenVPN（SSL）＋「Azure VPN Client」アプリを使う方式は別系統です。本記事は IKEv2 証明書方式に絞ります。

症状の見分け方

  • Windows の「設定 > ネットワークとインターネット > VPN」から接続すると昇格が必要のトースト通知。
  • イベントビューアー（アプリケーションとサービス ログ > Microsoft > Windows > RasClient/RemoteAccess）に エラー 13868 が記録。
  • あるいは接続は「接続済み」だが、社内 FQDN が引けない／プライベート IP へ疎通できない。

すぐ解決したい人向け：三つの質問への短答

「管理者として実行」はどこで行うのか

  1. スタート > すべてのアプリに作成される （接続名） のショートカット（例：Azure Virtual WAN VPN）を右クリック。
  2. [その他 > 管理者として実行] を選択して接続します。

GUI が見当たらない、あるいは自動化したい場合は、管理者権限の PowerShell/コマンドプロンプトで次を実行します。

rasdial "<接続名>"

注意：「設定 > ネットワークとインターネット > VPN」の画面は昇格できません。必ずショートカットの右クリック、または昇格済みシェルから rasdial/rasphone を使います。

Policy Match error 13868 の原因と対処（要点）

主な原因対処の要点
IKE/IPsec ポリシー不一致
（暗号・ハッシュ・DH/グループ・PFS・SA 有効期限 などがゲートウェイと一致していない）		最優先：Azure が生成した VPN プロファイルをそのまま使用し、クライアント側のポリシーを手動変更しない。
カスタムを使うなら、両者のパラメータを完全一致させる（後述の確認コマンド参照）。
証明書配置ミス／失効・未信頼
（AzureClient.pfx が Current User > Personal で秘密鍵つき、
AzureRoot.cer が Local Computer > Trusted Root に無い、など）		いったん削除し、最新のユーザー VPN プロファイルを再生成。VpnClientSetupAmd64.exe を管理者として実行。クライアント証明書を再インポート（秘密鍵必須、EKU=Client Authentication）。
OS/ポリシーによる暗号スイート拒否Windows Update と端末のセキュリティ基準（CSP/Intune/GPO）を確認。不要な制限で Azure 既定案が弾かれていないかを見直す。

接続後に社内リソースへ到達できない理由（総点検ポイント）

  • アドレスプールとルート：P2S クライアントアドレスレンジが VNet/オンプレと重複していないか。仮想ハブのルートテーブル／伝播設定で P2S プールから目的サブネットへ経路があるか。
  • NSG / Firewall：NSG と Azure Firewall が P2S プールからの受信を許可しているか。必要ポート（RDP/SSH/HTTP など）の許可があるか。
  • DNS 解決：azurevpnconfig.xml に配布された DNS がクライアントに反映されているか（ipconfig /all で確認）。社内 FQDN が正しいプライベート IP を返すか。
  • BGP/広告経路：BGP でオンプレ経路を受け取る場合、仮想ハブから P2S プールを適切に広告しているか。

なぜ「管理者として実行」が必要なのか（背景）

Windows の IKEv2 VPN は、カーネルレベルの IPsec ポリシーおよびトンネルインターフェイスの作成・ルート注入を伴います。設定アプリは UWP で昇格不可のため、必要な特権を持つ rasphone.exe／rasdial.exe を 管理者トークンで起動する必要があります。常に右クリックで昇格するか、管理者権限の端末スクリプトに接続手順を組み込むと安定します。

13868 の仕組みと深掘り（IKE/IPsec ポリシー不一致）

13868 は「提示された IKE/IPsec の提案（プロポーザル）が相手と一致しない」際に出ます。IKEv2 は フェーズ 1（IKE SA）と フェーズ 2（Child SA） の二段階でネゴシエーションを行い、それぞれで候補の組み合わせを提示します。以下のいずれかが食い違うと失敗します。

  • 暗号化方式（AES256 など）
  • 完全性（ハッシュ）（SHA256 等）
  • DH グループ／PFS（例：Group14, PFS2048）
  • SA の有効期限／再キーイング方針

Azure 側でカスタム IPsec/IKE ポリシーを適用した場合は、とくに一致性の確認が不可欠です。クライアント側を手でチューニングするより、Azure が生成したプロファイルを再導入する方が早くて確実です。

クライアント側ポリシーの確認と整合性チェック（PowerShell）

以下は 管理者権限の PowerShell で実行します。

# 接続一覧
Get-VpnConnection | Format-Table Name, ServerAddress, SplitTunneling, AuthenticationMethod

# IPsec/IKE 設定を確認

Get-VpnConnectionIPsecConfiguration -Name "<接続名>" | Format-List *

Azure 側の設定に合わせたいときは（※値は環境のポリシーに読み替えてください）、次のように明示的に合わせます。

Set-VpnConnectionIPsecConfiguration `  -Name "<接続名>"`
-AuthenticationTransformConstants SHA256 `  -CipherTransformConstants AES256`
-DHGroup Group14 `  -IntegrityCheckMethod SHA256`
-PfsGroup PFS2048 `  -SaLifeTimeSeconds 3600`
-PassThru -Force

ただし推奨はプロファイルの再生成・再導入です。クライアント側で個別調整を重ねると将来の保守負荷が跳ね上がります。

証明書トラブルの見落としポイント

  • 配置先ストア：
    • クライアント証明書（.pfx）… Current User > Personal（個人）
    • ルート証明書（.cer）… Local Computer > Trusted Root Certification Authorities
  • 秘密鍵の有無：個人ストアの証明書アイコンに鍵マークが付いているか（秘密鍵付きであること）。
  • EKU：Client Authentication（1.3.6.1.5.5.7.3.2） を含むか。
  • サムプリント一致：Azure にアップロードしたルート証明書の拇印（Thumbprint）と一致しているか。
  • アルゴリズム：実運用では RSA 2048/SHA‑256 を用意すると相性問題が少ない（ECDSA 証明書は周辺機器や古い OS との互換でつまずくことがある）。
  • 有効期限・失効：期限切れ、CRL/OCSP の失敗で未信頼扱いになっていないか（オフライン CRL の場合は特に注意）。

GUI 操作に不慣れな場合は certmgr.msc（ユーザー）と certlm.msc（ローカル コンピューター）で確認できます。自動化が必要なら Get-ChildItem Cert: や certutil を併用しましょう。

接続後に到達できないときの系統立った確認

1) ルーティング（クライアント）

# VPN インターフェイス名の確認


Get-NetIPInterface | Where-Object {$_.InterfaceAlias -like "*VPN*"}

# 目的プレフィックスへの経路が VPN インターフェイスへ向いているか

Get-NetRoute -DestinationPrefix 10.10.0.0/16 | Format-Table DestinationPrefix, InterfaceAlias, NextHop, RouteMetric, PolicyStore

# すべての経路を俯瞰

Get-NetRoute | Sort-Object RouteMetric | Format-Table -AutoSize

Split‑tunneling を採用していると、クライアント側に 特定プレフィックスのみ配布されます。行き先に対する明示経路が無いとローカル NIC から出てしまい到達不能になります。

2) DNS 解決

ipconfig /all


Resolve-DnsName fileserver.corp.example
nslookup fileserver.corp.example

# 名前は引けるが通信できないときは、得られた IP へ直接ポート検査

Test-NetConnection fileserver.corp.example -Port 445

DNS サーバー配布が不適切だと、社内 FQDN がインターネット向けに解決され、VPN 越しに到達しません。azurevpnconfig.xml に定義した DNS サーバーがクライアントに反映されているかを確認し、必要なら仮想ハブの DNS 設定を見直します。

3) NSG / Azure Firewall

  • NSG は 宛先サブネットに適用されます。着信元として P2S アドレス プール（例：172.16.10.0/24）を許可しているか。
  • Azure Firewall/UDR 経由の場合、対向サブネットへの戻り経路と アプリ ルール/NAT ルールの整合も確認します。

4) Virtual WAN のルーティング

仮想ハブのルートテーブルで、P2S 接続（ユーザー接続）から受けたプレフィックスが、目的の VNet 接続や ExpressRoute/サイト間接続へプロパゲートされているかを確認します。意図しない Isolate 設定や Default ルートの強制が原因でブラックホールが発生していないかにも注意しましょう。

5) BGP を使用している場合

オンプレミスへ社内プレフィックスを広告する際、P2S クライアントのプールは戻り経路として必要です。オンプレ側が P2S プールへの戻り経路を持たないと、片方向疎通になります。

再構築が早い：「リセット手順」完全版

  1. 既存の VPN 接続を削除：rasphone から該当プロファイルを削除、または Remove-VpnConnection -Name "<接続名>" -Force
  2. 証明書を削除：ユーザー個人ストア（Personal）からクライアント証明書を、ローカル コンピューターの信頼されたルートから旧ルート証明書を削除。
  3. Azure 側でルート証明書を最新化：必要に応じて新しいルート／クライアント証明書ペアを作成し、P2S 構成に登録。
  4. ユーザー VPN プロファイルを再生成・ダウンロード。
  5. VpnClientSetupAmd64.exe を管理者として実行し、ドライバやルート配布を正しく登録。
  6. スタートメニューのショートカットを 右クリック > 管理者として実行で接続テスト。

現場感として、細部の調整でハマるよりも、この「リセット手順」を一気に通す方が復旧までの時間が短いケースが大半です。

高度なトラブルシュート（ログとトレース）

  • RasClient/RemoteAccess ログ：イベント ID 20227, 20226 などを確認（IKE 交渉失敗の理由が現れる）。
  • IPsec/IKE トレース： netsh trace start persistent=yes capture=yes tracefile=c:\temp\ike.etl scenario=VpnClient # 再現させた後 netsh trace stop 取得した ETL は Message Analyzer 代替（Visual Studio/ETW ビューアーなど）で解析します。提案のミスマッチ箇所（暗号・ハッシュ・DH）が特定できます。
  • ルーティング/名前解決の同時検証：tracert、pathping、Test-NetConnection を組み合わせ、どの段で詰まっているかを切り分けます。

具体的なコマンド例（コピペ可）

接続・切断

# 接続（管理者権限）
rasdial "<接続名>"

# 切断

rasdial "<接続名>" /disconnect

VPN 接続のプロパティ確認

Get-VpnConnection -Name "<接続名>" | Format-List *

IPsec 設定の確認と反映

Get-VpnConnectionIPsecConfiguration -Name "<接続名>"


# （必要な場合のみ）Azure 側の値に合わせて反映

Set-VpnConnectionIPsecConfiguration -Name "<接続名>" `  -AuthenticationTransformConstants SHA256`
-CipherTransformConstants AES256 `  -IntegrityCheckMethod SHA256`
-DHGroup Group14 `  -PfsGroup PFS2048`
-SaLifeTimeSeconds 3600 -PassThru -Force

証明書の存在確認（ユーザー個人ストア）

Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, EnhancedKeyUsageList, Thumbprint, NotAfter

DNS／疎通確認

ipconfig /all


Resolve-DnsName dc01.corp.example
Test-NetConnection 10.20.0.4 -Port 3389

よくある落とし穴とアンチパターン

  • Windows の設定アプリから接続し続ける：昇格できないため失敗しやすい。ショートカットの右クリックか 管理者シェルの rasdial を習慣化。
  • クライアント側で暗号スイートを微調整：一見直ったように見えて、OS 更新で再発。プロファイル再生成が王道。
  • P2S プールの重複：オンプレや別 VNet とアドレス範囲が被ると「接続済みなのに届かない」典型例に。
  • OpenVPN 設定と IKEv2 の混在：azurevpnconfig.xml（OpenVPN）を IKEv2 環境へ流用しない。逆も同様。
  • DNS の過剰な Split DNS 設計：同名ゾーンの公共記録と社内記録が衝突し、名前解決が不安定に。ゾーン分割や検索サフィックスの整理を。
  • Azure Firewall の戻り経路不足：SNAT/UDR の組み合わせで片道通信になりやすい。対称ルーティングを確保。

運用の実践 Tips

  • 「接続用」ショートカットを配布：rasdial "<接続名>" を呼び出すバッチ/ショートカットを作成し、「常に管理者として実行」をチェックして配布。
  • 正常性チェックの自動化：ログオン時に DNS 解決 + 重要ポートの Test-NetConnection を実行し、失敗時は自動でログ収集（netsh trace）を開始。
  • 証明書の有効期限監視：有効期限 30 日前にアラートを上げ、プロファイル再配布計画を前倒ししておく。
  • OpenVPN 方式の併用検討：利用者端末の権限制約が厳しい環境では、仮想ハブ側で OpenVPN を有効化し、Azure VPN Client（ユーザーモード）で回避する設計も有効。

最短で復旧させるためのチェックリスト（1 分版）

  • 管理者として実行で接続したか（ショートカット右クリック or 管理者シェルの rasdial）。
  • 最新プロファイルを再生成し、VpnClientSetupAmd64.exe を管理者として実行したか。
  • クライアント証明書：Current User > Personal（秘密鍵付き）、ルート証明書：Local Computer > Trusted Root にあるか。
  • 13868 回避：クライアントの IPsec 設定を変更していないか（変えていたら既定に戻す）。
  • 到達不可：ルート・NSG・DNS・BGPを順に点検（Get-NetRoute／Resolve-DnsName／FW 設定／仮想ハブルート）。

まとめ

Policy Match error 13868 の本質は、クライアントとゲートウェイの IKE/IPsec ポリシー不一致です。最短の解決は「証明書とプロファイルを最新にして、変更を加えず再導入」すること。そして接続時は必ず 管理者として実行。接続後に到達できない場合は、アドレスプール／ルート／NSG／DNS／BGPの順で系統立てて診ると早く収束します。日々の運用ではショートカット配布や自動診断の仕込みで、再発時の切り分け時間を大幅に短縮できます。

Azure
PowerShell Windows 証明書 Azure IKEv2 Virtual WAN Point-to-Site VPN

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次