L2TP/IPsec の VPN がつながらないときの切り分け｜エラー 789 / 809 / 691、NAT 越えのレジストリ、事前共有鍵の不一致、ログの見方

L2TP/IPsec がつながらないときは、「サーバーに届いていない（809）」→「IPsec の交渉で落ちている（789）」→「L2TP / PPP の認証で落ちている（691）」の順に、どの層で止まっているかを決めてから直します。Windows のエラー番号がほぼこの層に対応していて、サーバー側は journalctl で strongSwan と xl2tpd のログを見れば、どこまで進んだかが分かります。

結論を先にまとめます。

• エラー 809: サーバーから応答がありません。UDP 500 / 4500 がどこかで塞がれている、ホスト名が解決できない、サーバーで strongSwan が動いていない、のいずれかです。
• エラー 789: IPsec の交渉（IKE）が失敗しています。事前共有鍵の不一致、暗号方式の不一致、そしてサーバーが NAT の内側にあるのに Windows 側のレジストリを変えていないことが典型です。
• エラー 691: IPsec は張れたが、ユーザー名・パスワードか認証方式（MS-CHAPv2）が合っていません。
• サーバー側では、ipsec statusall に ESTABLISHED が出るか、xl2tpd のログに Connection established が出るか、pppd のログに認証失敗が出るか、で同じ 3 層を確かめられます。

3 つの層とエラー番号

まず自分がどの層にいるかを決め、その層だけを直します。構築の全体像と設定ファイルは L2TP/IPsec の VPN サーバーを構築する方法 にあります。

手順 1: 到達性（エラー 809）を確かめる

1. クライアントから、サーバーのホスト名が正しい IP に解決されるか見ます。

nslookup vpn.example.com

1. サーバー側で strongSwan が UDP 500 / 4500 を待ち受けているか見ます。

sudo ss -lunp | grep -E ':500|:4500'
sudo systemctl status strongswan-starter xl2tpd

1. 経路上のファイアウォールを確かめます。サーバーの OS（ufw / firewalld / nftables）、クラウドのセキュリティグループや NSG、そしてクライアント側のネットワーク（会社のゲストネットワークやホテルの Wi-Fi は UDP 500 / 4500 を止めていることがあります）の 3 か所です。Microsoft の公式トラブルシューティングも、809 の原因として「サーバーかファイアウォールで UDP 500 または 4500 が塞がれている」ことを挙げています。

1. 接続を試しながらサーバーでパケットが届いているか見ます。何も出なければ、サーバーより手前で止まっています。

sudo tcpdump -ni any udp port 500 or udp port 4500

ここで届いているのに応答がない場合は、sudo journalctl -u strongswan-starter -f を見ながら接続を試し、次の層に進みます。

手順 2: IPsec の交渉（エラー 789）を直す

サーバーが NAT の内側にある場合（最多）

クラウドの仮想マシンは、パブリック IP が NAT で付けられていてサーバー自身はプライベート IP を持つ構成が普通です。この構成では、Windows の標準クライアントは既定で IPsec の接続を拒否します。Microsoft の公式ドキュメントに、クライアント側のレジストリで許可する手順があります。

1. 管理者としてレジストリエディターを開き、次のキーに移動します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent

1. DWORD（32 ビット）値 AssumeUDPEncapsulationContextOnSendRule を作り、値を設定します。

1. 再起動します。再起動しないと反映されません。

管理者権限の PowerShell なら 1 行で設定できます。

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

家庭やモバイル回線のクライアントも NAT の内側なので、実運用では 2 を選びます。社内の PC に一括で配るならグループポリシーのレジストリ設定を使います。

事前共有鍵と暗号方式

サーバーの journalctl -u strongswan-starter に次のような行が出るときの読み方です。

クライアント側のサービス

Windows で「IKE and AuthIP IPsec Keying Modules」と「IPsec Policy Agent」のサービスが停止していると 789 になります。services.msc で両方が「実行中」「自動」になっているか確かめます。

手順 3: 認証（エラー 691）を直す

IPsec が張れると、sudo ipsec statusall に ESTABLISHED と INSTALLED, TRANSPORT が出ます。この状態で 691 なら、L2TP / PPP の層です。

1. sudo journalctl -u xl2tpd -f を見ながら接続します。Connection established to <IP> が出て、その後 pppd の行で CHAP peer authentication failed のように出れば、認証の失敗です。
2. /etc/ppp/chap-secrets を確かめます。形式は「ユーザー名 サーバー名 パスワード IP」で、サーバー名は xl2tpd.conf の name = と一致させる必要があります（一致させない場合は *）。パスワードに記号が入るなら引用符で囲みます。
3. 認証方式を確かめます。options.xl2tpd で require-mschap-v2 にしているなら、クライアント側も MS-CHAPv2 を許可している必要があります。Windows の VPN 接続のプロパティ → セキュリティで「Microsoft CHAP Version 2」にチェックが要ります。
4. 一時的に xl2tpd.conf の ppp debug = yes と options.xl2tpd に debug を足すと、pppd の交渉が詳細に出ます。原因が分かったら戻します。

手順 4: つながるが通信できない

VPN の接続は成功したのに、社内のサーバーやインターネットに出られない場合は、認証ではなく経路の問題です。

• サーバーで sysctl net.ipv4.ip_forward が 1 か。
• NAT（iptables -t nat -L POSTROUTING -n に MASQUERADE があるか。ufw なら before.rules の *nat 節と DEFAULT_FORWARD_POLICY=ACCEPT）。
• クライアントの「リモートネットワークでデフォルトゲートウェイを使う」（Windows の IPv4 の詳細設定）。オフにしていると社内の範囲しか通りません。
• MTU。大きなページが開けない、SSH が途中で止まる、のときは options.xl2tpd の mtu / mru を 1280 前後まで下げます。

WordPress の観点: VPN が落ちたときに管理画面に入れなくなる

WordPress の管理画面を「VPN 経由だけ許可」にしている構成では、VPN が壊れるとサイトの更新もできなくなります。切り分けの間に困らないよう、次を用意しておきます。

• Nginx の allow に、VPN の範囲とは別に事務所の固定 IPも入れておく。
• サーバーのコンソール（クラウドのシリアルコンソールや VNC）から入れる手段を確かめておく。
• 緊急時に allow の行を一時的に外す手順を、nginx -t と systemctl reload nginx まで含めて書き残しておく。

管理画面が開けない原因が VPN ではなく WordPress 側のときの手順は 管理画面だけ白い画面になるときの直し方 を参照してください。乗っ取りが疑われる状況で VPN のパスワードも漏れた可能性があるなら、サーバーが乗っ取られたときの初動対応 の手順で事前共有鍵と全ユーザーのパスワードを変えます。

よくある質問

Windows 11 にしてから急に 789 になりました

Windows の更新で L2TP/IPsec の接続に影響が出た例が過去にあります。まず、レジストリの AssumeUDPEncapsulationContextOnSendRule が残っているか、「IKE and AuthIP IPsec Keying Modules」サービスが動いているかを確かめ、別の端末（macOS や iOS）から同じサーバーに入れるかで、サーバー側かクライアント側かを切り分けます。

macOS や iOS からは入れるのに Windows だけ入れません

ほぼ NAT 越えのレジストリです。macOS と iOS は NAT の内側のサーバーに既定で接続できますが、Windows は AssumeUDPEncapsulationContextOnSendRule を設定して再起動する必要があります。

事前共有鍵が正しいのに AUTHENTICATION_FAILED と出ます

ipsec.secrets を変えた後に sudo ipsec rereadsecrets（または strongSwan の再起動）をしていない、鍵の前後に空白や全角文字が入っている、%any %any ではなくサーバーの IP を書いていて実際のアドレス（NAT の内側のプライベート IP）と合っていない、のいずれかが典型です。

ログに uniqueids 関連で前の接続が切れる、と出ます

同じ事前共有鍵で 2 台目が接続すると 1 台目が切れる症状です。ipsec.conf の config setup に uniqueids=no を入れて再起動します。

まとめ

• L2TP/IPsec がつながらないときは、809（届かない）→ 789（IPsec 交渉）→ 691（認証）の順に層を決め、サーバーの journalctl で同じ層を確かめます。
• 最も多い原因は、サーバーが NAT の内側にあるときに Windows のレジストリ AssumeUDPEncapsulationContextOnSendRule を設定していないことです。設定後は再起動が要ります。
• つながるのに通信できないときは IP 転送・NAT・デフォルトゲートウェイ・MTU を見ます。管理画面を VPN 限定にしている場合は、事務所の固定 IP とコンソールの入口を予備として持ちます。

関連記事

• L2TP/IPsec の VPN サーバーを構築する方法｜strongSwan と xl2tpd の設定・ファイアウォールのポート・クライアント接続
• 管理画面だけ白い画面になるときの直し方
• サーバーが乗っ取られたときの初動対応

参考: Microsoft Learn – Configure L2TP/IPsec server behind NAT-T device、Microsoft Learn – Troubleshoot Always On VPN（エラー 809 ほか）、strongSwan Documentation

更新履歴: 2026-11-09 全面改訂（定型文の記事を、エラー 809 / 789 / 691 の 3 層での切り分け、NAT 越えのレジストリ設定、サーバー側ログの読み方に置き換え。構築手順は別記事に分離）。この記事はワードプレス博士（ライトセンド株式会社）が運営しています。