2026年6月4日

L2TP/IPsec の接続が不安定なときの対処｜切れるタイミングとログから原因を絞る

IPアドレス・ルーティング

L2TP/IPsec の接続が不安定なときは、「いつ切れるか」を先に把握すると原因がかなり絞れます。一定時間ごとに切れるなら鍵の再交換（リキー）や NAT のセッション切れ、大きなデータを送ったときだけ固まるなら MTU、複数人が同時につなぐと誰かが落ちるなら NAT 越えの設定、が典型です。この記事では、症状とログの読み方を示したうえで、起きやすい順に原因と確認方法、直し方を説明します。サーバー側は Linux（strongSwan または Libreswan と xl2tpd）、クライアント側は Windows を主な例にします。

設定を変える前に、サーバーとルーターの設定ファイルを控えておいてください。リモートから VPN サーバーを触る場合は、VPN 以外の経路（SSH やコンソール）を確保してから作業します。

まず「切れ方」を記録する

次の点をメモしてから調べ始めると、無駄な試行が減ります。

接続してから切れるまでの時間（毎回ほぼ同じか、ばらばらか）
切れる直前に何をしていたか（大きなファイルの転送、Web 会議、何もしていない）
特定の回線（自宅、モバイル回線、ホテルの Wi-Fi）でだけ起きるか
同じ拠点から複数人が接続しているか

ログの見方

L2TP/IPsec は3つの層が重なっています。外側が IPsec（IKE で鍵を交換し、ESP で暗号化）、その中で L2TP のトンネル、さらにその中で PPP のセッションが動きます。どの層で切れているかをログで見分けます。

# IPsec 側（strongSwan の例。サービス名は構成や版で異なる）
sudo journalctl -u strongswan --since "1 hour ago"

# Libreswan の例
sudo journalctl -u ipsec --since "1 hour ago"

# L2TP と PPP 側
sudo journalctl -u xl2tpd --since "1 hour ago"
sudo journalctl -t pppd --since "1 hour ago"

IKE の再交換（rekey）や DPD（相手の生存確認）のタイムアウトが切断の直前に出ている → IPsec 層の問題
IPsec は維持されているのに LCP terminated や echo 要求への無応答が出ている → PPP 層、または中を通るパケットが届いていない
サーバー側に何も記録されずにクライアントだけが切れる → 途中の NAT やファイアウォールでパケットが消えている可能性

Windows では、イベントビューアーの「アプリケーション」ログに RasClient の記録が残り、切断時のエラーコードが確認できます。

原因1：NAT のセッションが途中で切れる（一定時間で切れる・無通信で切れる）

家庭用ルーターや携帯回線の NAT は、一定時間通信がない UDP のセッションを消します。L2TP/IPsec は NAT を越えるとき UDP 4500 番に包まれて流れるため、無通信の時間が続くと NAT の対応表から消え、次のパケットが届かなくなります。

確認

何もしていないときにだけ切れるか、切れるまでの時間がほぼ一定かを見ます。サーバー側で通信を観察すると、クライアントからのパケットが途絶えたタイミングが分かります。

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

直し方

IPsec の DPD や NAT キープアライブの間隔を、NAT の保持時間より短くします。strongSwan・Libreswan とも、DPD の間隔やキープアライブの設定項目があります（設定ファイルの形式は版や構成によって異なるため、使っている版のドキュメントで項目名を確認してください）
PPP 側でも生存確認を送ります。pppd のオプションファイル（xl2tpd から参照されるもの）に次のように書くと、一定間隔で LCP の echo を送り、応答が続けて無ければ切断と判断します

# /etc/ppp/options.xl2tpd の例
lcp-echo-interval 30
lcp-echo-failure 4

lcp-echo-failure を小さくしすぎると、回線の一時的な揺れで切断されるようになります。間隔と回数は回線の質に合わせて調整します。

原因2：鍵の再交換（リキー）がうまくいかない（一定時間ごとに切れる）

毎回1時間や8時間など、決まった時間で切れる場合は、IKE や IPsec SA の有効期限が切れたときの再交換に失敗している可能性が高いです。サーバーとクライアントで有効期限や暗号方式の提案が噛み合っていないと、最初の接続は通っても再交換で失敗します。

ログで、切断の直前に rekey に関する記録やエラーが出ていないかを確認します。直し方は、サーバー側の有効期限をクライアント（多くは OS 標準の VPN クライアント）の既定値に近づける、受け入れる暗号方式の組み合わせを見直す、のどちらかです。古い暗号方式に合わせるために弱い方式を許可するのは避け、クライアント側の OS 更新を優先してください。

原因3：MTU が大きすぎる（大きな通信だけ固まる）

L2TP/IPsec は、IPsec・UDP・L2TP・PPP のヘッダーが重なるため、トンネル内で運べるパケットの大きさが小さくなります。小さな通信（チャットや ping）は通るのに、ファイルの転送や画面共有を始めると固まる、Web ページが途中で止まる、という症状は MTU の問題であることが多いです。

確認

トンネル越しに、断片化を禁止したうえでサイズを変えた ping を送ります。

# Linux：1372 バイトのデータ（ヘッダー込みで 1400 バイト）が通るか
ping -M do -s 1372 10.8.0.1

# Windows：同様に断片化禁止で送る
ping -f -l 1372 10.8.0.1

通らなければ値を下げていき、通る上限を探します。

直し方

PPP の MTU と MRU を下げます。

# /etc/ppp/options.xl2tpd の例
mtu 1400
mru 1400

あわせて、トンネルを通る TCP の MSS を調整すると効果的です。iptables を使う環境では、PPP インターフェースを通る SYN パケットの MSS を経路の MTU に合わせて書き換える設定がよく使われます。nftables を使う環境では同等のルールを書きます。どちらもファイアウォール全体の設定に関わるため、既存のルールを控えてから追加してください。

原因4：同じ NAT の後ろから複数台がつなぐ・サーバーが NAT の後ろにある

同じ拠点のルーターの後ろから2台目が接続すると1台目が切れる、という症状は、L2TP/IPsec の NAT 越えでよく知られています。サーバー側の実装や設定によっては、同じ送信元アドレスからの複数のクライアントを区別できないためです。サーバーが Libreswan や strongSwan なら、版によって対応状況が異なるため、使っている版のドキュメントで NAT の後ろの複数クライアントへの対応を確認してください。

また、Windows のクライアントは既定では NAT の後ろにある L2TP/IPsec サーバーへの接続を許可しません。サーバーがクラウドや家庭用ルーターの後ろにある場合、クライアント側でレジストリ HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent に DWORD 値 AssumeUDPEncapsulationContextOnSendRule を作成し、値を 2 にして再起動する設定が、Microsoft のサポート情報で案内されています。レジストリの変更は OS の動作に影響するため、手順はMicrosoftの最新の案内を確認したうえで行ってください。

原因5：回線そのものが不安定

モバイル回線や混雑した Wi-Fi では、通信中に送信元のアドレスやポートが変わったり、パケットの損失が続いたりして、VPN が張り直しになります。L2TP/IPsec は、アドレスが変わったときに接続を引き継ぐ仕組みを持たないため、回線の揺れがそのまま切断として現れます。別の回線（有線やテザリング）で同じ症状が出るかを試すと、回線側の問題かどうかが分かります。経路の損失は mtr で継続的に見ると把握しやすくなります。

プロトコルの見直しも検討する

L2TP/IPsec は多くの OS に標準で組み込まれている一方、Microsoft は将来の Windows で PPTP と L2TP を非推奨とする方針を示しています（2026年10月現在）。今後も長く使う VPN であれば、IKEv2、WireGuard、OpenVPN などへの移行も選択肢に入ります。特に WireGuard はアドレスが変わっても通信を続けやすく、モバイル回線での切断の悩みが減ることが多いです。移行する場合は、旧方式と並行して動かし、利用者ごとに切り替えると混乱を抑えられます。

まとめ

切れるタイミングを先に記録します。無通信で切れるなら NAT の保持時間、一定時間ごとならリキー、大きな通信で固まるなら MTU、複数台で落ちるなら NAT 越えの設定が典型です。
ログは IPsec、L2TP、PPP の層ごとに見て、どの層で切れているかを見分けます。
無通信対策は DPD やキープアライブと lcp-echo-interval、MTU 対策は mtu・mru と MSS の調整です。
Windows で NAT の後ろのサーバーにつなぐ場合は、Microsoft が案内しているレジストリ設定が要ります。
長く使うなら、IKEv2 や WireGuard などへの移行も検討します。