Comcastモデム交換後にL2TP/IPsec VPNが一部端末だけ繋がらない原因と対策｜NAT-TレジストリAssumeUDPEncapsulationContextOnSendRule

Comcastのモデムへ交換した直後から、Windows 10 Proの外部L2TP/IPsec VPNが「1台だけ成功」し、他は「VPNサーバーが応答しない」で失敗する――しかもLAN内では全端末が接続できる。これはVPNサーバー設定やPSKの誤りよりも、NAT越え（NATトラバーサル／NAT-T）と二重NATの条件差で起きやすい症状です。現場で再現しやすい切り分けと、最短で復旧する手順をまとめます。

まず確認したい「症状の型」：サーバーは正常、外からの到達経路だけが怪しい

今回のポイントは次の3つが同時に成立していることです。

以前（Arrisモデム時代）は、同じWindows 10 Pro端末群で外部から複数台が接続できていた
Comcastモデムへ交換後、外部接続は1台だけ成功し、他の端末は「VPNサーバーが応答しないため接続できない」で失敗する
VPN接続先をサーバーのLAN内IP（192.168.x.x）にすると、LAN内では全端末が接続できる

この組み合わせは、資格情報（ユーザー名／パスワード、事前共有キー）の間違いというより、社外→社内の経路（NAT／モデム／ルータ）と、L2TP/IPsecがNATを越えるためのNAT-T（UDPカプセル化）が噛み合っていないケースでよく見ます。

観測できる事実	示唆される原因	優先して見るべき場所
LAN内IPに向けると全端末が成功	VPNサーバー（Windows Server 2012 R2／RRAS）自体は動作している可能性が高い	サーバー側設定は「大枠OK」。外部到達とNAT要因を疑う
外部からは1台だけ成功	端末側の環境差（レジストリ／ポリシー／VPN設定）またはネットワーク差（NAT種別）がある	成功端末と失敗端末の差分比較、NAT-T設定確認
「VPNサーバーが応答しない」系の失敗	IKE（UDP 500）/ NAT-T（UDP 4500）/ L2TP（UDP 1701）到達不良、ALG干渉、二重NAT	モデム／ルータのブリッジ、ポート開放、IPsecパススルー

L2TP/IPsecは「NAT越え」が肝：UDP 500/4500/1701 の役割

L2TP/IPsec（事前共有キー：PSK）で外部VPN接続が成立するまでの流れを、ざっくり整理すると次の順番です。

IPsecの鍵交換（IKE）を開始（一般にUDP 500）
NATが検出されると、NATトラバーサル（NAT-T）としてUDP 4500へ切り替えてIPsecをカプセル化
IPsecトンネルの内側でL2TP制御（一般にUDP 1701）が流れる

モデム交換やルータ構成変更でNATの挙動が変わると、「NATあり／なし」「二重NAT」などの条件が変化し、Windows側がNAT-Tを使うべき場面で使えず、結果としてサーバー応答なしに見えることがあります。

プロトコル／ポート	何をしているか	止まると起きやすい症状
UDP 500（IKE）	IPsecの初期交渉（鍵交換の開始）	接続開始直後に失敗、エラー809/800系になりやすい
UDP 4500（NAT-T）	NAT越しにIPsecを通すためのカプセル化	モデム交換後に突然繋がらない、端末によって成否が分かれる
UDP 1701（L2TP）	IPsecの内側でL2TPトンネル制御	認証手前で止まる／接続が確立しない

結論：WindowsのNAT-T関連レジストリが未設定だと「一部端末だけ失敗」になり得る

今回の解決の核は、WindowsがL2TP/IPsecをNAT越しで張る際に必要になることがある、次のレジストリ設定です。

パス：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
名前：AssumeUDPEncapsulationContextOnSendRule（DWORD）

この値を設定すると、NAT環境下でのUDPカプセル化（NAT-T）をWindowsが前提として扱えるようになり、Comcastモデム交換後に発生した「外からだけ繋がらない」の復旧につながることがあります。特に、Comcastゲートウェイ＋既存ルータという構成に変わって二重NATになっている場合は、値2が効く典型パターンです。

値	意味（目安）	今回のケースでの使いどころ
未設定（または0）	既定動作（NAT-T前提にしない）	モデム交換前はこれでも通っていた可能性がある
1	VPNサーバーがNAT配下（社内側にNATがある）	サーバーがルータ配下でポート転送している場合に候補
2	クライアントもサーバーもNAT配下（二重NAT等）	Comcastゲートウェイ＋既存ルータで二重NATになった場合の本命

最短で直す：AssumeUDPEncapsulationContextOnSendRule の設定手順（Windows 10 Pro）

失敗しているWindows 10 Pro端末で、管理者権限で作業します。レジストリ編集に不安がある場合は、事前に復元ポイント作成やバックアップ（エクスポート）を行ってください。

レジストリエディタ（regedit）で設定する

スタートメニューで「regedit」を検索し、管理者として実行
次へ移動：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
右ペインで右クリック →「新規」→「DWORD（32ビット）値」
名前を AssumeUDPEncapsulationContextOnSendRule にする
値を10進数で 2（二重NAT想定）に設定（まずは2を推奨。状況により1で改善する場合もあります）
端末を再起動

PowerShellで一括適用する（管理者）

台数が多い場合や、手作業ミスを避けたい場合はPowerShellが便利です。

New-ItemProperty `
  -Path "HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent" `
  -Name "AssumeUDPEncapsulationContextOnSendRule" `
  -PropertyType DWord `
  -Value 2 `
  -Force

適用後は再起動します。再起動が難しい場合でも、現場では再起動が一番確実です（サービス再起動だけでは反映されないことがあります）。

.regファイルで配布する（例）

社内の運用ルールに合わせて、GPOや配布ツールで展開する場合は.regファイル化もできます。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent]
"AssumeUDPEncapsulationContextOnSendRule"=dword:00000002

なぜ「1台だけ成功」するのか：端末差・ネットワーク差の典型

同じVPN設定なのに端末ごとに成否が分かれると、VPNサーバー側を疑いたくなりますが、実際には次のような「差分」が原因になりがちです。

成功した端末だけ、過去に同じ不具合を踏んでレジストリが既に設定されていた
成功端末は外部回線が別（テザリング、別拠点Wi-Fiなど）で、二重NATではなかった
失敗端末はWindows更新やセキュリティソフト差で、IPsec関連サービスの挙動が変わっている

現場での近道は、成功端末のレジストリ値の有無と、接続している外部ネットワークのNAT状態を比べることです。

Comcastモデム交換後に増えがちな落とし穴：二重NATの有無を確認する

「モデムを交換しただけ」のつもりでも、実際にはComcastのゲートウェイ機器がルータ機能（NAT/DHCP）を持ち、既存の社内ルータもNATをしていると、二重NATになりやすいです。二重NATはL2TP/IPsecと相性が悪く、端末によってはNAT-Tがうまく働かず失敗します。

二重NATの簡易チェック

社内ルータの「WAN側IPアドレス」が、次のプライベートレンジ（またはCGNATレンジ）になっていないか確認します。

レンジ	見え方	意味
10.0.0.0/8	10.x.x.x	プライベートIP。ゲートウェイ配下＝二重NATの可能性
172.16.0.0/12	172.16〜172.31.x.x	プライベートIP。二重NATの可能性
192.168.0.0/16	192.168.x.x	プライベートIP。二重NATの可能性
100.64.0.0/10	100.64〜100.127.x.x	CGNAT（事業者側NAT）。外部からの着信自体が難しい場合も

WAN側がプライベートIPなら、Comcast機器がルータとして動作している可能性が高いです。対策としては、Comcast機器をブリッジ（パススルー）にして既存ルータに終端を寄せる、またはComcast機器側で既存ルータをDMZ/パススルーに設定して、二重NATを避けるのが王道です。

モデム／ルータ側のチェックリスト：L2TP/IPsecに必要な通信を通す

レジストリ設定で改善するケースが多い一方、そもそも経路でUDPが遮断されていると、端末側をいくら触っても繋がりません。Comcastゲートウェイや社内ルータで次を確認します。

項目	チェック内容	現場のコツ
ポート／プロトコル	UDP 500 / UDP 4500 / UDP 1701 が外部→VPNサーバーへ到達	「L2TP/IPsec passthrough」「IPsec passthrough」等の設定名の場合も
ポート転送（静的）	VPNサーバー（RRAS）のLAN内IPへ転送されている	DHCPだとIPが変わるので、サーバーは固定IP推奨
二重NAT	Comcastゲートウェイと既存ルータの二重NATになっていない	二重NATならブリッジ／パススルー／DMZで解消を検討
ALG／セキュリティ機能	VPN関連のALGが誤作動していない、過剰なセキュリティでUDPが遮断されていない	「VPNを加速」系の機能が逆に邪魔になることも。疑わしい場合は一時的に無効化して検証

特にUDP 4500はNAT-Tの要です。ここが閉じていると、「サーバーが応答しない」「途中で止まる」になりやすいので、最優先で確認します。

Windows Server 2012 R2（RRAS）側の最低限チェック

LAN内接続ができている時点で大枠はOKなはずですが、外部公開という観点では次も押さえておくと再発防止になります。

RRAS（Routing and Remote Access）がVPN（L2TP/IPsec）を待ち受けている
WindowsファイアウォールでL2TP/IPsec関連の受信が許可されている
ルータのポート転送先IPが、RRASサーバーの正しい固定IPになっている
NPS（Network Policy Server）を使っているなら、ポリシーとログイン条件が想定通り

「外からだけ不安定」「端末によって違う」ときは、サーバー側のイベントログも一度確認しておくと安心です。

イベントビューア →「カスタムビュー」→「サーバーロール」→「Network Policy and Access Services」
RRAS関連の失敗（L2TP、IKE、認証）イベントが出ていないか

クライアント（Windows 10）で原因を確定する：エラーコードとログの見方

UI上は「VPNサーバーが応答しない」と表示されても、内部ではエラー番号が付いています。代表的なものを覚えておくと、切り分けが速くなります。

エラー	画面の印象	疑うポイント	今回の本命度
809	サーバーが応答しない／接続できない	NAT-T（UDP 4500）、二重NAT、ポート遮断、ALG干渉	高い
800	接続できない（一般）	経路遮断、名前解決、ファイアウォール、ポート転送	中
789	セキュリティレイヤーで失敗	PSK不一致、暗号設定、証明書問題、IPsec交渉失敗	低〜中（LAN内OKなら下がる）
766	証明書が見つからない等	証明書ベース構成の不備	構成次第

ログは次を確認します。

イベントビューア →「アプリケーションとサービスログ」→「Microsoft」→「Windows」→「RasClient」→「Operational」
必要に応じて「IKEEXT」や「Security」の関連ログも確認

809が出ていて、Comcastモデム交換というタイミングが一致しているなら、NAT-Tレジストリ＋二重NATから手を付けるのが最短です。

それでも繋がらないときの切り分け手順（現場で迷わない順番）

レジストリを入れても改善しない場合は、「端末」ではなく「回線・経路」の問題が残っている可能性が高いです。次の順で切り分けると無駄が減ります。

同じ失敗端末を、別の外部回線（スマホテザリングなど）で試す
→ ここで成功するなら、社外拠点のルータ設定やUDP制限が疑わしい
社内側でComcastゲートウェイをブリッジにできるか確認し、既存ルータに終端を寄せて二重NATを解消
ブリッジが難しい場合、既存ルータをDMZ／パススルーにし、ポート転送が確実に届く形にする
ポート転送先（RRASサーバー）が正しいか再確認（固定IP、転送ルール、ファイアウォール）

「機器を替えた直後に発生」「LAN内はOK」「外部は一部だけ」という条件では、端末を増やして試すより、NAT構成をシンプルにする方が解決が早いことが多いです。

PPTPへの変更は“切り分け止まり”に：安全性と代替案

トラブル時に「PPTPにしたら？」という提案が出ることがあります。確かにPPTPは通りやすいことがありますが、暗号化方式の脆弱性が指摘されており、恒久運用としては推奨しにくいのが実情です。あくまで切り分け用途に留め、長期的には次の選択肢も検討すると安心です。

方式	通りやすさ	セキュリティ	現場でのコメント
L2TP/IPsec（PSK）	ネットワーク次第（NAT-Tが鍵）	中（PSK運用は管理が重要）	既存資産があるなら、まずはNAT-Tと二重NAT解消で安定化
IKEv2	比較的良い（同じくUDP 500/4500）	高	証明書運用が必要になりやすいが、安定性と安全性が高い
SSTP	高（TCP 443）	高	HTTPSで通るため回線制約に強い。証明書が必要
PPTP	高	低	短期の切り分け以外は非推奨

Windows Server 2012 R2環境でも方式追加は可能ですが、証明書やクライアント配布、運用ポリシーの設計が絡みます。まずは現行のL2TP/IPsecを「確実にNAT越しできる状態」に戻し、その上で移行計画を立てるとスムーズです。

再発防止のチェックリスト（そのまま運用手順に落とせる形）

カテゴリ	チェック項目	推奨アクション
端末	失敗端末にAssumeUDPEncapsulationContextOnSendRuleが設定されている	値2で統一し、GPO/配布ツールで横展開
経路	二重NATになっていない	Comcast機器をブリッジ、またはパススルー/DMZで単一NATへ
ポート	UDP 500/4500/1701がVPNサーバーへ到達	ポート転送を固定IP宛てに設定、ログで到達を確認
監視	障害時に見るログが整理されている	RasClient（クライアント）とNPS/RRAS（サーバー）を手順化
セキュリティ	PSK運用（共有鍵）の管理が適切	定期更新、退職者対応、可能ならIKEv2/SSTPへ段階移行

まとめ：外部だけ一部端末が失敗するL2TP/IPsecは「NAT-T設定＋二重NAT」を最優先で疑う

LAN内では全端末成功＝サーバー設定は大枠OK。外部経路（NAT/モデム/ルータ）を疑う
Comcastモデム交換後に起きたなら、二重NAT化でNAT-Tが必要になった可能性が高い
Windows 10側でAssumeUDPEncapsulationContextOnSendRule（DWORD）を設定し、値2→再起動で改善する例が多い
併せてUDP 500/4500/1701の到達、ブリッジ/パススルー、ポート転送先IPを整えると安定する

「1台だけ繋がる」という紛らわしい症状ほど、成功端末の差分がヒントになります。レジストリ値とNAT構成を揃えるだけで、外部VPNが一気に安定することも少なくありません。

この記事を書いた人

佐藤健司

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