IKEv2とは？IPsec VPNの仕組み・設定・つながらない原因
IKEv2とは、IPsec VPNで使う暗号の鍵や設定を、PCとVPNゲートウェイが自動で取り決めるための仕組み（Internet Key Exchange version 2）です。
この記事では、UDP 500と4500で進む4つのメッセージの中身、認証と暗号の選び方、エラー809や証明書のエラーでつながらないときの切り分け、固定IPが必要な場面での選び方を図解します。
この記事は以下のような人におすすめ！
- IKEv2の仕組みを基礎から知りたい人
- VPNがエラー809などでつながらない人
- 社外から決まったIPで入りたい人
本記事はプロモーション（アフィリエイト広告）を含みます。
IKEv2とは
1-1. IPsecの鍵と設定を自動で決める仕組み
IPsecは、IPの通信を暗号化して、途中で読まれたり書き換えられたりしないようにする仕組みです。
ただし、暗号化を始めるには、どの暗号を使うか、どの鍵を使うか、どの範囲の通信を守るかを、両側で先にそろえておく必要があります。
その取り決めを自動で行うのがIKE（Internet Key Exchange）で、現在の版がIKEv2です。
米国国立標準技術研究所（NIST）のガイドSP 800-77 Rev. 1も、IPsecはIPネットワークの通信を守るネットワーク層の仕組みで、その設定は通常IKEで行うと説明しています（参考2）。
次の図は、自宅のPCから会社の社内LANへIKEv2でつなぐときの全体像を、例示用のIPアドレスで示したものです。
IKEv2の仕様であるRFC 7296では、IKEで作る「IKE SA」と、その上で作るデータ用の「Child SA」を分けて扱います。
IKE SAは鍵の交換や相手の確認、その後の管理のやり取りに使い、Child SAはESP（暗号化したデータを運ぶ形式）でデータを守るために使います（参考1）。
図の例では、PC（198.51.100.23）がVPNゲートウェイ（203.0.113.10）のUDP 500番ポートへ話しかけ、接続が終わると仮想IP（10.0.99.5）や社内のDNS、VPNに通す範囲が配られます。
SAは、通信を守るための約束事（使う暗号や鍵、有効期限などの組み合わせ）のことだと考えるとわかりやすいでしょう。
利用者から見れば「VPNにつなぐ」の一言ですが、その裏ではこの2種類のSAが順番に作られています。
1-2. IKEv1との違い
IKEv2の前には、IKEv1という旧版がありました。
次の図は、RFC 7296の付録にある「IKEv1からの変更点」をもとに、主な違いを5つの項目で比べたものです。
RFC 7296は、IKEv1では8通りあった最初のやり取りを、4つのメッセージ（2往復）の1通りに置き換えて単純にしたとしています。
さらに、Child SAを追加するやり取りを3メッセージから2メッセージに短くし、すべてのメッセージに応答を返す確実なやり取りにしました。
IKEv1では別の文書や拡張として追加されていたNAT越え、EAPによる利用者の認証、仮想IPの取得も、IKEv2では1つの仕様にまとめられています。
一方で、同じRFCはIKEv2をIKEv1との後方互換がない変更だとしているため、PCとゲートウェイの両方でIKEv2を選ぶ必要があります（参考1）。
Windowsの組み込みのVPNクライアントでも、IKEv2はトンネルの種類の1つとして用意されていて、暗号の組み合わせを設定できます（参考8）。
IKEv1の仕組みや、メインモードとアグレッシブモードの違いは、次の記事で解説しています。
IKEv2の仕組み
2-1. 最初の4メッセージ（IKE_SA_INITとIKE_AUTH）
IKEv2の接続は、通常、IKE_SA_INITとIKE_AUTHという2つのやり取り、合わせて4つのメッセージで始まります。
次の図は、4つのメッセージに入る主な中身（ペイロード）と、それぞれで決まることを並べたものです。
①と②のIKE_SA_INITでは、使える暗号の候補（SA）、鍵を作るためのDiffie-Hellmanの値（KE）、使い捨ての乱数（Nonce）を交換し、ここで共通の鍵の素ができます。
途中にNATがあるかを調べるためのNAT_DETECTIONという値も、このときに一緒に送ります。
③と④のIKE_AUTHは②までに作った鍵で暗号化されていて、身元（ID）、証明書（CERT）、その鍵を持っていることの証明（AUTH）をやり取りします。
リモートアクセスでは、③でPCが設定ペイロード（CP）で仮想IPを求め、④でゲートウェイが割り当てたアドレスを返します。
RFC 7296も、ゲートウェイが守るネットワークの中のアドレスをPCへ動的に配る場合は、IKE_AUTHのやり取りの中で求めると定めています。
TSiとTSrは「どの範囲の通信をこのSAで守るか」を示すTraffic Selectorで、④でゲートウェイが範囲を絞って返すこともあります（参考1）。
4つのメッセージが終わった時点で、IKE SAと最初のChild SAができ、すぐにESPで社内との通信を始められます。
逆に言えば、つながらないときは①②で止まったのか、③④で止まったのかを分けるだけでも、原因の見当がかなり付きます。
2-2. NAT越え：UDP 4500へ移る理由
家庭やホテルのネットワークでは、ルーターのNAT（アドレス変換）で、PCの送信元のアドレスとポートが書き換えられるのが普通です。
次の図は、ゲートウェイがNATを見つけて、UDP 4500番ポートへ移るまでの流れを、例示用のアドレスとポートで示したものです。
RFC 7296では、NATを越える機能を持つ実装は、IKE_SA_INITにNAT_DETECTION_SOURCE_IPとNAT_DETECTION_DESTINATION_IPを入れます。
中身はSPI（SAの識別番号）とIPアドレス、ポート番号をまとめたSHA-1のハッシュ値で、受け取った側は実際に届いたパケットの外側のアドレスから計算した値と比べます。
図の例では、PCは192.168.1.20の500番から送ったつもりでも、届いたパケットの送信元は198.51.100.23の40123番に変わっているため、値が一致せず途中にNATがあると分かります。
ESPのパケットは暗号で守られていてNATがうまく書き換えられないため、IKEv2はIKEとESPをUDPで包んでNATを通りやすくしています。
NATを見つけた場合、その後のIKEとESPはすべてUDP 4500番ポートで送り、IKEのメッセージには先頭に4バイトのゼロを付けて、0にならないSPIで始まるESPと見分けます（参考1）。
ESPをUDPで包む形式そのものはRFC 3948で定められていて、通信が途切れている間もNATの対応表が消えないよう、0xFFの1バイトだけのキープアライブを送ることも決められています。
同じRFCでは、ほかに何も送っていない時間がこの長さを超えたら送るという間隔の既定値を20秒としています（参考3）。
そのため、UDP 500は通ってもUDP 4500が止められている場所では、NATの内側からはつながりません。
反対に、途中にNATがない場合はESPをUDPで包む必要はなく、包まないESPがそのまま流れることがあります。
包まないESPはポート番号を持たず、IPのプロトコル番号50で区別されるため、ファイアウォールではUDP 500に加えてESPも通す必要があります（参考10）。
NATの仕組みそのものは、次の記事で詳しく解説しています。
2-3. 鍵の更新・生存確認・回線の切り替え
接続が終わったあとも、IKEv2は裏で短いやり取りを続けています。
次の図は、接続したあとに起きる主なやり取りを、時刻と例示用のIPアドレスで並べたものです。
RFC 7296では、最初の4メッセージのあとのやり取りを、Child SAを作るCREATE_CHILD_SAと、SAの削除やエラーの通知などを行うINFORMATIONALの2種類に分けています。
しばらく相手から暗号化されたメッセージが届かないときは、中身が空のINFORMATIONALを送って相手が生きているかを確かめ、応答が返らなければ再送したうえで接続をあきらめます。
鍵を新しくするときも、CREATE_CHILD_SAで新しいSAを作って入れ替えます（参考1）。
回線の切り替えに対応するのが、RFC 4555で定められたMOBIKEという拡張です。
基本のIKEv2では、SAは作ったときのIPアドレスに結び付いているため、PCがWi-Fiからモバイル回線へ移ってアドレスが変わると、作り直しが必要になります。
RFC 4555は、作り直しにはワンタイムコードの入力のような利用者の操作が必要になる場合もあると指摘しています。
MOBIKEに対応していれば、PCは新しいアドレスからUPDATE_SA_ADDRESSESを含むINFORMATIONALを送り、ゲートウェイは新しいアドレスへ届くかを確かめてから、ESPの宛先を切り替えます（参考4）。
図の例のように、10時15分にWi-Fiの192.0.2.15からモバイル回線の198.51.100.77へ変わっても、接続し直さずに通信を続けられるのが利点です。
スマホやノートPCを持ち歩いて使う場合は、ゲートウェイとクライアントの両方がMOBIKEに対応しているかを確かめておくとよいでしょう。
IKEv2の認証と暗号の設定
3-1. 証明書・事前共有鍵・EAPの違い
IKEv2の設定でまず迷うのが、相手をどの方法で確かめるかという認証方式です。
次の図は、3つの認証方式の違いと、向いている場面をまとめたものです。
RFC 8247は、IKEv2の認証方式として、RSA署名（方式1）と事前共有鍵（方式2）を実装必須とし、ECDSAなどのデジタル署名（方式14など）を推奨としています。
同じRFCは、RSAの鍵の長さは2048ビットを実装必須とし、2048ビット未満は使うべきでないとしています（参考5）。
証明書は端末ごとに発行でき、なくした端末の証明書だけを失効させられるため、会社の端末や拠点間の接続に向いています。
事前共有鍵（PSK）は両側に同じ文字列を設定するだけで始められますが、多くの人で同じ鍵を使うと、1人から漏れたときに全員分の変更が必要になります。
EAPは、IDとパスワードや利用者の証明書で本人を確かめる方式で、RADIUSサーバーと組み合わせて社員一人ひとりを管理するのに使われます。
RFC 7296は、EAPはふつう利用者がサーバーに対して本人を示すための方式で相互の認証にならない場合があるため、ゲートウェイ側は公開鍵の署名で自分を証明しなければならないとしています（参考1）。
つまり、RFC 7296の基本の仕組みでは、EAPを使う場合でもゲートウェイの証明書が必要です。
EAPの種類や、PEAPとEAP-TLSの違いは、次の記事で解説しています。
3-2. 暗号スイートの選び方
認証方式が決まったら、暗号、整合性、PRF、DHグループの組み合わせ（暗号スイート）を選びます。
次の図は、RFC 8247の推奨度をもとに、選ぶ値の例と、使わない値を整理したものです。
RFC 8247は、暗号ではAES-CBCを実装必須、AES-GCMやChaCha20-Poly1305を推奨とし、DESとNULL（暗号化なし）は使ってはいけないとしています。
改ざんを見つける整合性ではHMAC-SHA2-256-128、鍵を作るPRFではHMAC-SHA2-256を実装必須とし、MD5を使う方式はどちらも使ってはいけないとしています。
ただし、AES-GCMのように暗号化と改ざんの検知を一体で行う方式（AEAD）を選んだ場合、整合性の項目は使わず「なし」にします。
DHグループでは、14番（2048ビットのMODP）を実装必須、19番（256ビットの楕円曲線）を推奨とし、1番と22番は使ってはいけない、2番と5番は使うべきでないとしています。
同じRFCは、DHグループを最も慎重に選ぶべき値だとしています。
理由は、IKEとESPの通信をすべて記録した攻撃者が、何年後であってもDHグループを破れれば、ESPの暗号化に使った鍵を得られてしまうためです。
一方で、大きすぎるDHグループは、大規模なゲートウェイや小さな機器の負担になるとも書かれています（参考5）。
そのため、迷ったら19番か14番を基準にし、使う機器が対応しているかを確かめるとよいでしょう。
なお、MUSTやSHOULDは「実装しなければならない・実装すべき」という実装側の要件で、そのまま強さの順位を表すものではありません。
PCとゲートウェイの候補の中に共通の組み合わせが1つもないと①②の段階で接続が止まるため、両側の設定をそろえることが大切です。
IKEv2でつながらないときの切り分け
4-1. エラー809：UDP 500と4500が途中で止まる
WindowsでIKEv2の接続を試して「809」のエラーが出ると、何が悪いのか分からず不安になりますよね。
でも、809は多くの場合、PCやパスワードではなく、途中の道が塞がれていることを示しています。
次の図は、PCからゲートウェイまでの道のりで、UDP 500や4500が止まりやすい場所と、確かめる順番を示したものです。
Microsoftの資料は、エラー809を、リモートのサーバーが応答せず、PCとVPNサーバーの間で接続を確立できない状態だとしています。
原因としては、VPNサーバーやファイアウォールでUDP 500や4500が塞がれている場合を挙げ、途中のファイアウォール、NAT、ルーターの設定が正しくないと起きると説明しています。
対策として、まず管理者や回線の事業者にどの機器で止まっているかを確かめ、その機器でUDP 500と4500を通すようにし、それでも直らなければ途中のすべての機器を確かめるよう勧めています（参考6）。
利用者側でできる最初の確認は、スマホのテザリングなど別の回線で同じ設定を試すことです。
別の回線でつながるなら今いる場所のルーターやネットワークの制限が原因の可能性が高く、つながらないなら会社側の受け口の設定を疑います。
会社側では、ゲートウェイに要求が届いた記録があるかを見ると、手前で止まっているのか、届いたうえで断っているのかを分けられます。
2-2で見たとおり、NATの内側ではUDP 4500も、NATのない経路ではESPも使うため、500だけを開けても足りない点に気を付けましょう。
UDP 500と4500を開けても特定の回線だけで809になる場合は、4-2で説明する大きなメッセージの分割も疑ってください。
4-2. 証明書のエラー（13801・13806）と大きなメッセージの分割
③④のIKE_AUTHで応答が返り、13801や13806のような番号が表示される場合は、まず証明書を疑います。
次の図は、Windowsで表示される証明書のエラーの意味とよくある原因、そして証明書が大きくて落ちる問題を整理したものです。
Microsoftの資料は、エラー13801を、サーバーかクライアントがIKEの認証情報を受け入れられない状態だとしています。
原因には、サーバー証明書の拡張キー使用法に「サーバー認証」がない、証明書の期限切れ、PCにサーバー証明書を確かめるためのルート証明書がない、PCに設定した接続先の名前と証明書の名前が違う、の4つが挙げられています。
エラー13806は有効なマシン証明書が見つからない状態で、必要な証明書やルート証明書が入っていないと起きるとされています（参考6）。
接続先をIPアドレスで設定していて、証明書がvpn.example.co.jpのような名前で発行されている場合も、名前が一致しないため失敗します。
一方、証明書のエラー番号ではなく応答が返らない症状が、自宅やホテルの回線だけで起きる場合は、メッセージの大きさを疑います。
RFC 7383は、IKE_AUTHは証明書を送るときに数KBになることがあり、経路のMTUを超えるとIPで分割され、一部のNATなどが分割された断片を通さないためにSAを作れなくなると説明しています。
断片が途中で捨てられるとIKE_AUTHの応答が返らないため、PCには証明書のエラーではなく、809と同じ応答のない症状として見えることがあります。
その対策として、IKEv2自身がメッセージを分けて送るIKEフラグメントを定めていて、①②でIKEV2_FRAGMENTATION_SUPPORTEDを伝え合った場合に使います。
分ける大きさの目安は、IPv4では576バイト、IPv6では1280バイトとされています（参考7）。
証明書の仕組みや、ルート証明書で確かめる流れは、次の記事で詳しく解説しています。
4-3. つながるのに通信できないとき
「接続済み」と表示されるのに、社内のサーバーに届かないこともあります。
次の図は、そのときに見る通す範囲（Traffic Selector）、PCのルート表、DNSの値を、例示用のアドレスで示したものです。
2-1で見たとおり、④でゲートウェイが通す範囲を返すときに、PCの提案より狭く絞ることがあります。
RFC 7296は、ゲートウェイの方針で提案された範囲を一部も受け入れられない場合はTS_UNACCEPTABLEを返し、全体を受け入れられる場合はそのまま返すとしています（参考1）。
図の例では、PCがすべての宛先（0.0.0.0/0）を提案しても、ゲートウェイが10.0.20.0/24だけに絞ったため、別の部署の10.0.30.0/24への通信はVPNでは運ばれません。
その通信が自宅回線へ流れるのか、トンネルに入っても捨てられるのかはOSやクライアント、分割トンネルの設定で変わりますが、どちらの場合も届きません。
名前では失敗するのにIPアドレスなら届く場合は、社内のDNS（図では10.0.20.53）が配られていない可能性があります。
IPアドレスでも届かない場合は通す範囲とルート表を、どちらも正しい場合は社内のサーバーやファイアウォールが仮想IPの範囲からの通信を許しているかを確かめます。
方式を問わないVPNの接続トラブルの切り分けは、次の記事で段階ごとに解説しています。
IKEv2 VPNの使い道と固定IPが必要な場面
5-1. リモートアクセスと拠点間接続
IKEv2は、使い方によって「人が会社に入る」場合と「ネットワーク同士をつなぐ」場合の2つに分けられます。
次の図は、2つの使い方を例示用のアドレスで比べたものです。
リモートアクセスでは、社員のPCやスマホが会社のゲートウェイにつなぎ、EAPなどで本人を確かめてから、仮想IPを受け取って社内LANに入ります。
拠点間接続では、本社と支店のルーター同士が証明書などで互いを確かめ、本社の10.0.20.0/24と支店の10.0.40.0/24を常につなぎます。
NISTのSP 800-77 Rev. 1は、組織がさまざまな状況でIPsecとIKEを使って守りを実現する方法を示すとともに、IPsecの代わりになる方法と、それぞれが適する状況も説明するとしています（参考2）。
どちらの使い方でもゲートウェイはインターネットに公開されるため、機器の更新と認証の強化を続けることが前提です。
IPsec VPN全体の仕組みや、トンネルモードとトランスポートモードの違いは、次の記事で解説しています。
5-2. IP制限付きのサービスへ決まったIPで入る
IKEv2を調べている人の中には、「社内LANに入りたい」のではなく、「決まったIPアドレスから外部のサービスに入りたい」だけという人もいます。
たとえば、取引先の管理画面や会計のクラウドサービスが、会社のIPアドレスからしかログインできない設定になっている場合です。
次の図は、IPアドレスで入れる相手を決めているサービスに、自宅から直接入る場合と、固定IPのVPNを通る場合を比べたものです。
自宅の回線（198.51.100.23）から直接入ると、許可リストの203.0.113.50/32と一致しないため、ログインの前に断られます。
固定IPのVPNサーバーを通ると、サービスから見える送信元はVPNの出口のIPになり、それを許可リストに登録しておけば、どこにいても同じIPで入れます。
Microsoft Entra IDの条件付きアクセスでも、本社やVPNのIPアドレスの範囲を「ネームドロケーション」として登録でき、クラウド型のプロキシやVPNを使う場合はそのIPアドレスで判定されると説明されています（参考9）。
このためだけに自社でIKEv2のゲートウェイを立て、固定IPの回線を契約して更新や監視を続けるのは、負担が大きい場合があります。
ただし、図のCのとおり、固定IPのVPNサービスは決まったIPで外へ出るための道で、社内LANのファイルサーバーへ入る仕組みの代わりにはなりません。
選択肢の1つに、専用の固定IPアドレスで接続できる「MillenVPN専用サーバー」があります。
広告主の案内では、テレワークや出張先から決まったIPで接続して外部サービスのIP制限に対応する用途や、フリーWi-Fiでの通信の暗号化が挙げられています。
一方で、すべての制限を回避できることを保証するものではないとも明記されているため、使いたいサービスの許可リストに登録できるかを、導入の前に確かめておきましょう。
こんな場合は固定IPのVPNサービスが向いています
- 会社のIPからしか入れないサービスがある
- 社内LANのファイルサーバーには入らない
- 自社でVPNゲートウェイを運用するのが難しい
社内LANへ入る必要がある場合は、IKEv2などのリモートアクセスVPNを選んでください。
固定IPアドレスの仕組みや、手に入れる方法の比べ方は、次の記事で解説しています。
5-3. 目的別の選び方とSSL VPNとの比較
ここまでの内容を「どこに入りたいか」で整理すると、選ぶ方式が見えてきます。
次の図は、3つの質問で方式を選ぶ流れを示したものです。
本社と支店を常につなぐならIKEv2の拠点間VPN、社員が社外から社内LANに入るならIKEv2のリモートアクセスかSSL VPNが候補です。
出先がホテルや来客用のWi-Fiばかりで、UDPが止められやすい場合は、TCPの443番ポートを使うSSL VPNのほうがつながりやすいことがあります。
社内LANには入らず、決まったIPで外部のサービスに入りたいだけなら、固定IPのVPNサービスで足りることがあります。
次の表は、3つの方式の違いをまとめたものです。
| 項目 | IKEv2（自社のGW） | SSL VPN（自社の装置） | 固定IPのVPNサービス |
|---|---|---|---|
| 入れる先 | 社内LAN・拠点間 | 社内LAN | IP制限付きの外部サービス |
| 主に使うポート | UDP 500・4500（NATがなければESPも） | TCP 443 | サービスによる |
| 社内に置く機器 | ゲートウェイ | VPN装置 | なし |
| 更新作業 | 自社か保守業者 | 自社か保守業者 | 主に事業者 |
Q3に当てはまり、自社でゲートウェイを持たずに済ませたい場合は、固定IPのVPNサービスの仕様と料金を確かめてみてください。
▶ MillenVPN専用サーバーの料金と仕様を公式サイトで確かめる
SSL VPNの仕組みや、IPsecとの違いは、次の記事で解説しています。
よくある質問とまとめ
Q1. IKEv2とIPsecは何が違いますか？
IPsecは通信を暗号化する仕組みの全体で、IKEv2はそのIPsecで使う鍵や設定を自動で取り決める仕組みです。
Q2. IKEv2で使うポートはどれですか？
通常はUDP 500番で始まり、途中にNATがあればUDP 4500番へ移るため両方を通し、NATがない経路ではESP（IPのプロトコル番号50）も通す必要があります。
Q3. エラー809はどうすれば直りますか？
多くは途中でUDP 500や4500が止められているためで、別の回線で試したうえで、会社側や途中の機器の設定を確かめます。
Q4. 事前共有鍵と証明書はどちらがよいですか？
少数の拠点間なら事前共有鍵でも始められますが、社員が多いリモートアクセスでは、端末ごとに失効できる証明書や、利用者ごとに管理できるEAPのほうが管理しやすいです。
Q5. 固定IPのVPNサービスで社内LANに入れますか？
固定IPのVPNサービスは決まったIPで外部のサービスに入るためのもので、社内LANに入る場合は会社のIKEv2ゲートウェイなどが必要です。
決まったIPで外部サービスに入りたいだけの方へ
社内LANには入らず、IP制限のあるサービスを社外から使いたい場合は、自社でゲートウェイを立てる前に固定IPのVPNサービスで足りるかを確かめると、運用の負担を抑えられることがあります。
IKEv2は、IPsec VPNの鍵と設定を4つのメッセージで取り決め、NATがあればUDP 4500へ移ってつながりを保つ仕組みです。
次の図は、この記事の要点をまとめたものです。
つながらないときは、809ならUDP 500と4500、13801や13806なら証明書、つながるのに通信できないなら通す範囲とルートとDNS、と止まった段階で見る所を変えましょう。
目的が「決まったIPで外部のサービスに入る」ことだけなら、ゲートウェイを立てる前に固定IPのVPNサービスも比べてみてください。
まずは今日、使っているVPNの接続設定でIKEv2が選ばれているかと、ゲートウェイの証明書の名前と期限を確かめるところから始めてください。
参考1：RFC 7296 Internet Key Exchange Protocol Version 2 (IKEv2)（IETF、英語）
参考2：SP 800-77 Rev. 1, Guide to IPsec VPNs（NIST、英語）
参考3：RFC 3948 UDP Encapsulation of IPsec ESP Packets（IETF、英語）
参考4：RFC 4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE)（IETF、英語）
参考5：RFC 8247 Algorithm Implementation Requirements and Usage Guidance for IKEv2（IETF、英語）
参考6：Troubleshoot Always On VPN（Microsoft、英語）
参考7：RFC 7383 Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation（IETF、英語）
参考8：VPN connection types（Microsoft、英語）
参考9：条件付きアクセス ポリシー：ネットワーク信号の使用（Microsoft）
参考10：RFC 4303 IP Encapsulating Security Payload (ESP)（IETF、英語）
