IPsec の仕組みと IKEv1 廃止｜ESP・SA・NAT-T の落とし穴

はじめに

IPsec（Security Architecture for Internet Protocol）は、IP レイヤで認証・暗号化・改ざん検知を提供するセキュリティプロトコル群です。インターネットなどの公衆網を経由するパケットを暗号化し、拠点間 VPN（Site-to-Site VPN）の事実上の標準として広く採用されています。

ただし、IPsec は単一のプロトコルではなく AH／ESP・転送モード・IKE という複数の要素を組み合わせたフレームワーク であり、用語が混在しやすい領域です。さらに 2023 年 4 月に公開された RFC 9395 で IKEv1 が正式に Deprecated（非推奨）化 されるなど、運用面の前提も変化しています。

本記事では、IPsec の構成要素を整理したうえで、IKEv2 への移行や NAT-T・MTU といった実務でハマりやすい論点までまとめます。

参考: RFC 9395 – Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms
“Internet Key Exchange Version 1 (IKEv1) has been deprecated, and RFCs 2407, 2408, and 2409 have been moved to Historic status.”
（IKEv1 は非推奨となり、RFC 2407、2408、2409 は Historic ステータスに移行しました）
https://datatracker.ietf.org/doc/rfc9395/

IPsec の 3 つの要素

IPsec は単一のプロトコルではなく、複数のプロトコルや技術を組み合わせたフレームワーク の総称です。要素を分けずに学ぶと混乱しやすいため、以下の 3 つの軸に分解して整理します。

IPsec の 3 本柱

プロトコル（何を守るか）

データの守り方を決める役割です。

• AH: 改ざん検知（認証）のみ。暗号化は行わない
• ESP: 暗号化＋改ざん検知。現在はこちらが標準

転送モード（どこまで包むか）

パケットの保護範囲を決める役割です。

• トンネルモード: オリジナルの IP パケットごと暗号化（拠点間 VPN 向け）
• トランスポートモード: ペイロードのみ暗号化（ホスト間通信や L2TP/IPsec 向け）

鍵交換（どう合意するか）

暗号化に必要な鍵を安全に共有する仕組みです。

• IKE（Internet Key Exchange）: 鍵交換の自動化プロトコル。現在の推奨は IKEv2

プロトコルの種類: AH と ESP

データを保護するプロトコルには AH と ESP の 2 種類がありますが、現在の VPN 環境では ESP が標準の選択肢 です。

AH（Authentication Header）

AH は IP プロトコル番号 51 で動作し、改ざん検知（認証）のみを提供します。データの暗号化は行わず、IP ヘッダを含むパケット全体を認証対象にする点が特徴です。ただし、IP ヘッダを認証対象に含むため、NAT 機器でアドレスが書き換わると認証エラーとなり通信が失敗します。NAT 環境が一般化した現在、AH 単体での利用はほとんど見られません。

ESP（Encapsulating Security Payload）

ESP は IP プロトコル番号 50 で動作し、暗号化と改ざん検知の両方を提供 します。一般的に「IPsec」といえば、この ESP を指すケースがほとんどです。

AH と ESP の比較

RFC 8221 における推奨アルゴリズム

ESP で利用する暗号アルゴリズムは、RFC 8221（2017 年 10 月）で要件が定義されています。AEAD（認証付き暗号）である AES-GCM が MUST（必須） に格上げされ、暗号化と認証を 1 つの処理にまとめられるため、性能と安全性の両面で推奨されます。

参考: RFC 8221 – ESP and AH Algorithm Requirements
“ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order to favor the use of authenticated encryption and AEAD algorithms.”
（AEAD 暗号の利用を推進するため、AES-GCM-16 のステータスが SHOULD+ から MUST に引き上げられました）
https://datatracker.ietf.org/doc/html/rfc8221

一方、3DES は SHOULD NOT（非推奨）、AES-CBC は MAY（任意） となっており、新規構築では AES-GCM を選定することが推奨されます。

転送モード: トンネルとトランスポート

ESP や AH をパケットにどう適用するかを決めるのが「転送モード」です。新しい IP ヘッダを付加するかどうか が両者の最大の違いです。

トンネルモード（Tunnel Mode）

オリジナルの IP パケットを丸ごと暗号化し、新しい IP ヘッダを付加してカプセル化します。

[新 IP ヘッダ][ESP ヘッダ][元 IP ヘッダ + ペイロード（暗号化）][ESP トレーラ]

VPN ゲートウェイ同士が新しい IP ヘッダで通信するため、LAN 内のプライベート IP アドレス同士の通信をインターネット越しに運べる のが利点です。拠点間 VPN（Site-to-Site VPN）はこのモードを使用します。

トランスポートモード（Transport Mode）

オリジナルの IP ヘッダはそのまま使い、ペイロード部分のみを暗号化します。

[元 IP ヘッダ][ESP ヘッダ][ペイロード（暗号化）][ESP トレーラ]

新しい IP ヘッダを追加しないためオーバーヘッドは小さくなりますが、通信する両端が直接ルーティング可能である必要 があります。L2TP/IPsec や GRE over IPsec、ホスト間の直接通信で利用されます。

モードの選び方

• 拠点間 VPN（プライベート IP 同士の通信） → トンネルモード
• L2TP/IPsec によるリモートアクセス VPN → トランスポートモード（L2TP がカプセル化を担当）
• GRE over IPsec → トランスポートモード（GRE 側でカプセル化）
• ホスト同士の直接通信 → トランスポートモード

鍵交換の仕組み: IKE と SA

IPsec で暗号化通信を行うには、送信側と受信側で共通の鍵を共有する必要があります。鍵そのものをインターネット越しに送れば盗聴のリスクがあるため、Diffie-Hellman（DH）鍵交換アルゴリズム を用いて、お互いの手元で同じ共通鍵を生成する仕組みが取られます。これを担うのが IKE です。

IKE（Internet Key Exchange）

IKE は UDP ポート 500 で動作する鍵交換プロトコルです。NAT 環境を検出した場合は、UDP ポート 4500 に切り替え て NAT-T（NAT Traversal）を使用します。

SA（Security Association）

SA は通信の合意内容（暗号化方式、鍵、有効期限など）をまとめた「契約書」に相当します。IPsec では役割の異なる 2 種類の SA が作られます。

IPsec SA が片方向で 2 つ作られるのは、上り／下りで別々の SPI（Security Parameters Index）を持つためです。show 系コマンドで SA を確認すると、上り（inbound）と下り（outbound）の 2 行が表示されます。

Diffie-Hellman グループの選定

IKE の鍵交換では DH グループを指定します。グループ番号によって強度が異なるため、Group 14（2048 bit MODP）以上、可能であれば Group 19/20（256/384 bit ECP）以上 を選定することが推奨されます。

参考: Palo Alto Networks – Define IPSec Crypto Profiles
“For the highest security, choose the group with the highest number.”
（最高のセキュリティのために、最も大きい番号のグループを選択することが推奨されます）
https://docs.paloaltonetworks.com/network-security/ipsec-vpn/administration/set-up-site-to-site-vpn/define-cryptographic-profiles/define-ipsec-crypto-profiles

通信開始までの流れ: IKEv1 と IKEv2

IKE は 2 段階のフェーズを経て VPN トンネルを完成させます。ここでは IKEv1 を例に流れを示しつつ、現在標準となっている IKEv2 との差分を整理します。

IKEv1: フェーズ 1 とフェーズ 2

IKEv2: フェーズの統合と高速化

IKEv2 は IKEv1 の手順をシンプル化し、最小 4 メッセージ（IKE_SA_INIT × 2、IKE_AUTH × 2）でトンネル確立 が完了します。

参考: RFC 7296 – Internet Key Exchange Protocol Version 2 (IKEv2)
“Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH exchanges (known in IKEv1 as Phase 1). These initial exchanges normally consist of four messages.”
（IKE による通信は常に IKE_SA_INIT と IKE_AUTH 交換で始まります。これらの初期交換は通常 4 つのメッセージで構成されます）
https://datatracker.ietf.org/doc/html/rfc7296

IKEv1 と IKEv2 の比較

IKEv1 は非推奨であることに注意

IKEv1 は RFC 9395（2023 年 4 月）で正式に Deprecated 化 されました。RFC 2407／2408／2409 は Historic ステータスとなり、新規開発は終了しています。

参考: RFC 9395 – Deprecation of IKEv1
“IKEv1 development ceased over a decade ago, and no new work will happen. This poses the risk of unmaintained code in an otherwise supported product.”
（IKEv1 の開発は 10 年以上前に停止しており、今後の更新もありません。これはサポート対象製品に保守されないコードが残り続けるリスクを意味します）
https://datatracker.ietf.org/doc/rfc9395/

既存環境で IKEv1 を使用している場合は、IKEv2 への移行を検討することが推奨されます。

IPsec を導入する際のハマりポイント

IPsec はプロトコルの組み合わせが多く、設計時には正しいのに繋がらない、繋がっても通信が安定しない というトラブルが起きやすい技術です。ここでは、運用現場で踏みやすい代表的な落とし穴を整理します。

NAT-T が必須となるケース

IPsec は ESP（IP プロトコル番号 50）を使う関係で、NAT 機器を素通しすると問題が発生します。AH は IP ヘッダを認証対象に含むため NAT で書き換わると認証エラーになり、ESP も NAPT（Port Address Translation）環境ではポート番号が存在しないため変換ができません。

そのため、NAT 機器を経由する IPsec 通信では NAT-T（NAT Traversal、RFC 3948）が必須 となります。NAT-T では ESP パケットを UDP 4500 番でカプセル化し、NAT 機器が UDP として処理できるようにします。

参考: strongSwan – NAT Traversal
“The solution proposed by RFC 3948 is to encapsulate ESP packets in UDP datagrams, which then allows to apply Port Address Translation.”
（RFC 3948 で提案された解決策は、ESP パケットを UDP データグラム内にカプセル化することで PAT の適用を可能にするというものです）
https://docs.strongswan.org/docs/latest/features/natTraversal.html

必要なポート開放

ファイアウォール経由で IPsec を通す場合、最低限以下のポート／プロトコルが必要です。

ESP は TCP/UDP ではなく IP プロトコル番号 50 で動作する ため、ファイアウォールで「TCP/UDP のみを許可するルール」では通過できません。

MTU・MSS の調整

IPsec は ESP ヘッダや新しい IP ヘッダを追加するため、カプセル化により実効 MTU が縮小 します。トンネルモード＋ESP＋NAT-T を組み合わせた場合の追加オーバーヘッドの目安は以下の通りです。

合計で 50〜80 バイト程度 がオーバーヘッドとなり、Ethernet の MTU 1500 バイトを前提とすると、IPsec トンネル内の実効 MTU は概ね 1400 バイト前後 になります。

この縮小を考慮せずに大きなパケットを送ると、フラグメントが発生して性能劣化や、DF ビットが立ったパケットが破棄される事象につながります。対策としては以下が一般的です。

• トンネルインターフェイスの MTU を明示的に縮小（例: 1400 バイト）
• TCP MSS clamping: TCP SYN/SYN-ACK の MSS をトンネル MTU に合わせてルータ・ファイアウォール側で書き換える
• PMTUD（Path MTU Discovery）の動作確認: 経路上で ICMP Type 3 Code 4 がブロックされていないか確認

DPD（Dead Peer Detection）の設定

IPsec ピアのどちらかが応答不能になった場合、相手側はそのまま「トンネルが生きている」と認識してしまうケースがあります。これを検出する仕組みが DPD（Dead Peer Detection） です。IKEv1 では RFC 3706、IKEv2 では RFC 7296 に標準化されています。

DPD は定期的に R-U-THERE メッセージを送り、応答がなければ SA を破棄して再ネゴシエーションします。未設定のままだと「片側だけ SA が残り、通信不可」という状態が長時間継続 することがあるため、本番環境では設定が推奨されます。

Aggressive Mode の脆弱性

IKEv1 の Aggressive Mode は手順を簡略化する代わりに、PSK 認証時に IKE ハッシュが平文で交換 されます。この通信を攻撃者がキャプチャできれば、PSK のオフライン辞書攻撃が可能となるため、現在は推奨されません。

Cisco IOS には crypto isakmp aggressive-mode disable コマンドで Aggressive Mode を全面的に無効化できます。

参考: Cisco IOS Security Command Reference – crypto isakmp aggressive-mode disable
“To block all Internet Security Association and Key Management Protocol (ISAKMP) aggressive mode requests to and from a device, use the crypto isakmp aggressive-mode disable command in global configuration mode.”
（デバイスへの ISAKMP Aggressive Mode 要求をすべてブロックするには、グローバル設定モードで crypto isakmp aggressive-mode disable コマンドを使用します）
https://www.cisco.com/c/en/us/td/docs/routers/sdwan/command/iosxe/qualified-cli-command-reference-guide/m-crypto-commands.html

新規構築では IKEv2 への移行が望ましく、IKEv1 を継続使用する場合でも Main Mode を選択することが推奨されます。

暗号アルゴリズムのミスマッチ

IKE フェーズ 1／2 で、両端の暗号アルゴリズム・ハッシュ・DH グループ・SA 寿命などが完全に一致していないとネゴシエーションが失敗 します。複数のプロポーザルを設定している場合、両端で提示順が異なると意図しない弱い組み合わせが選ばれることもあるため、設計時に提示順を統一しておくことが推奨されます。

特に以下のアルゴリズムは脆弱性が報告されており、新規構築では避けることが推奨されます。

• DES、3DES: Sweet32 攻撃の対象。RFC 8221 でも 3DES は SHOULD NOT
• MD5、SHA-1: 衝突攻撃のリスク
• DH Group 1（768 bit）、Group 2（1024 bit）: Logjam 攻撃の対象として懸念

2026 年時点の暗号アルゴリズム動向と PQC 対応

IPsec の暗号アルゴリズムは継続的に更新されており、2026 年現在は AES-GCM ベースの構成が標準 です。さらに、量子コンピュータ時代を見据えた耐量子計算機暗号（PQC）への対応も進んでいます。

推奨される標準アルゴリズム構成

耐量子計算機暗号（PQC）への対応

「Harvest Now, Decrypt Later（今盗聴して将来復号する）」攻撃への懸念から、量子コンピュータでも解読困難な PQC（Post-Quantum Cryptography）の標準化が進んでいます。IPsec／IKEv2 でも以下の RFC が成立しています。

RFC 9242（2022 年 5 月）: IKE_INTERMEDIATE Exchange

IKE_SA_INIT と IKE_AUTH の間に中間交換を追加し、PQC のような鍵サイズの大きいデータを IKE フラグメンテーションせずに転送できるようにする拡張

RFC 9370（2023 年 5 月）: Multiple Key Exchanges in IKEv2

従来の DH に加えて最大 7 ラウンドの追加鍵交換を可能にし、従来の鍵交換と PQC アルゴリズムを組み合わせたハイブリッド鍵交換 を実現

参考: Palo Alto Networks – How RFC 9242 and RFC 9370 Resist Quantum Computing Threats
“Together, these two RFC standards give IKEv2 the ability to create hybrid keys using both classic and PQC key exchange mechanisms (KEMs) to mitigate a quantum attack using Shor’s algorithm.”
（これら 2 つの RFC により、IKEv2 は従来の鍵交換と PQC KEM の両方を使ったハイブリッド鍵を生成し、Shor のアルゴリズムによる量子攻撃を緩和できるようになります）
https://docs.paloaltonetworks.com/network-security/quantum-security/administration/quantum-security-concepts/how-rfc-9242-and-rfc-9370-resist-quantum-computing-threats

ハイブリッド鍵交換では「従来の ECDH」と「PQC（ML-KEM など）」を組み合わせ、どちらか一方が破られても、もう一方が安全であれば鍵全体の安全性が保たれる 設計となっています。NIST の FIPS 203 として 2024 年に標準化された ML-KEM（旧 Kyber） が、IKEv2 における主要な PQC アルゴリズム候補です。

ベンダー実装の状況（2026 年時点）

• Palo Alto Networks: PAN-OS で RFC 9242／9370 をサポートし、ML-KEM などの PQC KEM を IKEv2 に組み込み可能
• strongSwan: NIST P-384 ECDH と ML-KEM-1024 のハイブリッドを CNSA 2.0 推奨構成として案内
• Cisco／Juniper: プロトタイプ実装・対応が進行中

長期間機密性を維持する必要がある通信（政府系・金融系・知財関連など）では、PQC ハイブリッド対応のロードマップを早期に検討することが推奨されます。

動作確認に役立つコマンド

主要なベンダー・実装で IPsec の状態を確認する際の基本コマンドをまとめます。詳細な出力フォーマットは製品・バージョンによって異なるため、実機投入前に対象機器の公式リファレンスを確認することが推奨されます。

Cisco IOS／IOS XE

! IKE（ISAKMP）SA の確認
show crypto isakmp sa
show crypto isakmp sa detail

! IPsec SA の確認
show crypto ipsec sa

! VPN セッションの統合表示（IKE と IPsec をまとめて確認）
show crypto session
show crypto session detail

! SA のクリア（再ネゴシエーション）
clear crypto isakmp
clear crypto ipsec sa

参考: Cisco IOS Security Command Reference
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/security/s1/sec-s1-cr-book/sec-s1-cr-book_CLT_chapter.html

show crypto isakmp sa で QM_IDLE が表示されていれば IKE SA が確立済みです。show crypto ipsec sa では inbound／outbound の SPI が表示され、両方にパケットカウントが加算されていれば双方向で暗号化通信が行われています。

Juniper Junos OS（SRX シリーズ）

# IKE SA の確認
show security ike security-associations
show security ike security-associations detail

# IPsec SA の確認
show security ipsec security-associations
show security ipsec security-associations detail

参考: Juniper Networks – NAT-T を使用したルートベース VPN
https://www.juniper.net/documentation/jp/ja/software/junos/vpn-ipsec/topics/topic-map/security-route-based-and-policy-based-vpns-with-nat-t.html

strongSwan（Linux）

# 設定の読み込み
swanctl --load-all

# 接続定義の確認
swanctl --list-conns

# 確立済み SA の確認
swanctl --list-sas

# 接続の手動確立／切断
swanctl --initiate --child <child-sa-name>
swanctl --terminate --ike <ike-sa-name>

# カーネル側 SA の確認（Linux XFRM）
ip xfrm state
ip xfrm policy

# ログ確認
journalctl -u strongswan -f

参考: strongSwan – swanctl –list-sas
https://docs.strongswan.org/docs/latest/swanctl/swanctlListSas.html

swanctl --list-sas の出力で ESTABLISHED, IKEv2（IKE SA 確立済み）、INSTALLED, TUNNEL, ESP:AES_GCM_16-128（Child SA がトンネルモード ESP-AES-GCM で確立）といった状態が確認できます。

パケットキャプチャでの確認

トンネルが張れない、または不安定な場合は、ピアの外側インターフェイスで UDP 500／4500 をキャプチャし、IKE_SA_INIT や IKE_AUTH の応答が返っているかを確認します。Wireshark の isakmp フィルタで IKE のメッセージ種別と SPI、ネゴシエーション結果が読み取れます。

まとめ

本記事では、IPsec の仕組みと 2026 年時点の動向を整理しました。

• IPsec はフレームワーク: AH／ESP・転送モード・IKE の 3 要素で構成される
• 現在の標準は ESP（AES-GCM）＋トンネルモード＋IKEv2
• IKEv1 は RFC 9395（2023 年）で正式 Deprecated: 既存環境では IKEv2 移行を検討
• NAT 環境では NAT-T（UDP 4500）が必須: AH は NAT 通過不可
• MTU 縮小に注意: トンネルモード＋NAT-T で実効 MTU は 1400 バイト前後になる
• DPD は本番環境で設定推奨: 未設定だと片側だけ SA が残り通信不可になるケースがある
• PQC 対応は RFC 9242／9370 で整備済み: 長期的な機密性が必要な通信では早期検討を推奨

以上、最後までお読みいただきありがとうございました。