FortiGate IPsec VPNが繋がらない時の対処法｜Phase1/Phase2エラー原因・diagコマンド・NAT Traversal設定【トラブルシューティング】

2025年7月12日2026年5月5日

トラブルシューティング

FortiGate
IPsec VPN
Phase1 / Phase2
トラブルシューティング

FortiGateでIPsec VPNを設定しても、なぜかPhase1やPhase2が確立しない。一見正しく設定しているつもりでも、細かいパラメータの不一致や見落としでつまずくことはかなり多いです。

本記事では、FortiGateでVPNがつながらないときに実際に確認しているポイントを5つ紹介します。現場でよくあるトラブルを例に、Phase1/Phase2の切り分け方・diagコマンドの使い方・エラーメッセージの読み方・ポリシーとルートの確認まで体系的に解説します。

👷 現場での体験談

拠点間VPNの設定で「Phase1は上がるのにPhase2が確立しない」という状況に遭遇したとき、最初はルーティングやポリシーを疑って30分以上調査していました。

結局原因はPhase2のProposal設定で、自分がSHA256を設定していたのに対向機器がSHA1のみ対応という組み合わせ不一致でした。diagコマンドで「peer SA proposal not match local」が出ていたのに最初は読み飛ばしていたのが敗因です。ログのキーワードを知っているかどうかで解決時間が5倍変わることを痛感した案件です。

IPsec VPN拠点間接続の構成図。FortiGate-AとFortiGate-Bがインターネット経由でIPsecトンネルを構築し、本社LANと支社LANを接続 — IPsec VPN 拠点間接続の構成図（本社・支社間のトンネル構成）

Phase1とPhase2の違いと役割

IPsec VPNのトラブルシュートを効率よく進めるには、まずPhase1とPhase2が何をしているかを正確に理解することが重要です。

Phase1（IKE SA）

対向装置との信頼関係を確立
鍵交換・認証（Pre-shared Key または証明書）
ここが落ちているとトンネル自体が存在しない
UDP 500（IKE）/ UDP 4500（NAT-T）を使用

確認：diagnose vpn ike gateway list

Phase2（IPsec SA）

実際の通信路（トンネル）を確立
トラフィックの暗号化・復号
通信が発生しないと確立されない（デフォルト）
Phase1が成功していることが前提

確認：diagnose vpn tunnel list

⚠ よくある誤解：「トンネルが上がらない」≠「Phase1が落ちている」
VPN設定後に「トンネルが上がらない」と思っていても、実は通信していないだけでPhase2が未確立というケースは多いです。FortiGateのPhase2はデフォルトでオンデマンド（トラフィック発生時に確立）のため、pingなどで通信を発生させてから状態を確認しましょう。

段階	落ちているときの現象	主な原因
Phase1が落ちている	トンネル自体が一切上がらない diagnose vpn tunnel listで何も出ないログに「negotiation timeout」「no proposal chosen」	Pre-shared key不一致ポート500/4500がブロック IPアドレス・IKEバージョン不一致
Phase2が落ちている	Phase1は上がるが通信できない diagnose vpn tunnel listで status: down pingしても反応なし	暗号設定不一致（AES/SHAなど） Quick Mode Selectorのミスルートやポリシーの不備

図1：FortiGate IPsec VPNがつながらない原因の内訳（現場経験ベース）

Phase1が確立しない時に見るべき設定

Phase1が上がらない場合、まず以下の項目を順番に確認します。

事前共有鍵（Pre-shared Key）の不一致

最も多い原因です。大文字・小文字・記号の打ち間違いは目視では気づきにくく、両端のFortiGateでPSKをコピー&ペーストして入力するのが確実です。「これ絶対合ってる」と思っていても、もう一度確認してください。

IKEバージョンの不一致（v1とv2）

IKEv1とIKEv2は互換性がありません。片方がv2でもう片方がv1の場合、Phase1のネゴシエーションが始まりません。FortiGateはデフォルトでIKEv1になっていることが多いため、対向機器のバージョンを必ず確認してください。

ポート500/4500がブロックされている

IKEはUDP 500、NAT-TはUDP 4500を使用します。途中のFWやACLでこれらのポートがブロックされていると、Phase1のパケットが対向装置に届きません。特にクラウド接続やインターネットVPNでは要確認です。

対向機器のIPアドレス設定ミス

接続先IPが誤っている、またはNAT越え環境でのIP設定が合っていないケースです。Dynamic IPの対向装置（モバイルクライアント等）では、Peer typeの設定も確認してください。

証明書認証の場合はCNや証明書チェーンを確認

PSKではなく証明書で認証している場合、証明書のCN・SAN・有効期限・中間CA証明書のインストール状況を確認します。

Phase2が確立しない時に確認する項目

Phase1はOKでもPhase2でコケることは多いです。以下の4項目を確認してください。

確認項目	よくある不一致パターン	確認方法
暗号・認証アルゴリズム	片方がSHA1、対向がSHA256のみ対応など	ログの「no proposal chosen」「peer SA proposal not match」
PFS（Perfect Forward Secrecy）	片方が有効、対向が無効（またはDHグループが違う）	Phase2のPFS設定と対向の設定を比較
Quick Mode Selector（セレクター）	送信元/宛先サブネットの範囲が合っていない	ログの「INVALID_ID_INFORMATION」
通信の発生	VPN設定後にpingなどを打っていない（オンデマンド確立のため）	ping後に diagnose vpn tunnel list で確認

diagコマンドでログを取る方法

トラブル時は必ずログで原因を絞ります。FortiGateのdiagコマンドは強力で、エラーメッセージからほとんどの原因を特定できます。

IKEデバッグ（Phase1の調査）

! フィルタのクリア（必ず最初に実施）
diagnose vpn ike log-filter clear

! 対向IPでフィルタ（ログを絞り込む）
diagnose vpn ike log-filter dst-addr4 <対向のIP>

! IKEデバッグを開始
diagnose debug application ike -1
diagnose debug enable

! 確認が終わったら必ず無効化する
diagnose debug disable

🚨 diagnose debug enableは業務時間帯に流しっぱなしにしない
IKEデバッグはログ出力量が多く、FortiGateのCPUに影響する場合があります。対象時間帯を絞って実施し、確認後は必ず diagnose debug disable を実行してください。

Phase2・トンネル状態の確認

diagnose vpn tunnel list

（出力例）
name=VPN_to_Branch ver=1 serial=1 10.0.0.1:500->203.0.113.1:500 tun_id=0
bound_if=4 lgwy=10.0.0.1 tun_if=0
mgr_id=1 in_name=VPN_to_Branch
dev=8 prio=0 shaping=0 flags[0]=0 flags[1]=0 flags[2]=0 flags[3]=0
gwy=203.0.113.1

name=VPN_to_Branch     ← トンネル名
version=1              ← IKEバージョン
status: up             ← ✅ トンネルが上がっている
status: down           ← ❌ トンネルが落ちている

rx bytes=1843221       ← 受信データ量（0のままなら通信できていない）
tx bytes=924109        ← 送信データ量
created=2025-03-20     ← セッション作成日時（最近作られているか確認）

Phase1（IKEゲートウェイ）の状態確認

diagnose vpn ike gateway list

! 出力例
vd: root/0
name: VPN_to_Branch
version: 1
interface: wan1 10.0.0.1
addr: 10.0.0.1:500 -> 203.0.113.1:500
created: 50s ago    ← Phase1が確立されてからの時間
IKE SA: created 1/1  established 1/1  ← 確立済み
IPsec SA: created 1/1  established 1/1

よくあるエラーメッセージと対処法

IKEデバッグのログに出るメッセージと、それぞれの意味・対処法を整理します。このキーワードを知っているだけで、原因特定時間が大幅に短縮されます。

エラーメッセージ	意味・原因	対処
no proposal chosen	暗号化方式（Phase1またはPhase2）が一致していない	両者のProposal設定（AES/SHA/DHグループ等）を確認・統一する
received notify: INVALID_ID_INFORMATION	Quick Mode Selectorのサブネット設定ミス	送信元・宛先サブネットの範囲が対向と一致しているか確認
negotiation timeout	対向装置に接続できない（パケットが届いていない）	NAT越え・ルーティング・ポート500/4500の疎通を確認
peer SA proposal not match local	Phase2のProposalが対向と不一致	Phase2のEncryption/Authentication/PFS設定を対向に合わせる
unable to find phase1 handle	対向装置との接続情報が不正（VPNの設定がずれている）	IP設定・ポリシーをVPNの設定と照合する

図2：IPsecトラブル時に遭遇するエラーメッセージの頻度（現場経験ベース）

最終確認：VPNポリシーとルートの設定

Phase1・Phase2が両方確立されているのに通信できない場合、ルートやポリシーが未設定・不正なケースがよくあります。トンネルが上がったからといって安心しないでください。

確認すべき3つのポイント

🛡️

双方向のポリシー

送信元→宛先だけでなく、宛先→送信元の戻りポリシーも作成されているか確認する

🗺️

静的ルートの設定

VPN対向ネットワーク宛のルートがトンネルインターフェース向きに設定されているか確認する

🚫

NATの除外

VPN通信にNATがかかっていると宛先が書き換えられて通信できない。VPN対向宛はNATを除外する

確認コマンド一覧

! ルーティングテーブルの確認
get router info routing-table all

! ファイアウォールポリシーの確認
show firewall policy

! アドレスオブジェクトの確認
show firewall address

! 実際の経路をフロートレースで確認
diagnose debug flow filter addr <宛先IP>
diagnose debug flow show function-name enable
diagnose debug enable
diagnose debug flow trace start 10

! 確認後は無効化
diagnose debug disable

（フロートレースで出る典型的な問題のサイン）
id=20085 trace_id=1 msg="policy lookup failed"    ← ポリシーがない・マッチしていない
id=20085 trace_id=1 msg="no matching route"       ← ルートがない・トンネル向きでない
id=20085 trace_id=1 msg="iprope_in_check() check failed, drop"  ← FWに弾かれている

トラブルシューティングの全体フロー

図3：VPNがつながらない時の切り分けフロー

VPNがつながらない

↓

🔍 diagnose vpn tunnel list / ike gateway list
Phase1はUPか？

Phase1がDOWN↓

PSK・IKEバージョン
ポート500/4500
対向IP設定を確認

Phase1がUP↓

Phase2設定確認
暗号/PFS/セレクター
→通信を発生させてから確認

Phase1・Phase2ともUPでも通信できない↓

ポリシー・ルート・NATを確認
diagnose debug flow で経路を追跡

NAT環境でIPsec VPNが繋がらない場合（NAT Traversal）

FortiGateの手前にルータやファイアウォールがあり、NATされている環境ではIPsec VPNが正常に確立しないケースがよくあります。IPsecのESPパケット（IPプロトコル50番）はNATと相性が悪く、途中のNAT装置でパケットが破棄されることがあります。

対処としてNAT Traversal（NAT-T）を有効にする必要があります。NAT-Tを有効にすると、ESPパケットがUDP 4500番でカプセル化されるため、NAT環境でも通過できるようになります。

config vpn ipsec phase1-interface
  edit "vpn-tunnel"
    set nattraversal enable
    set nattraversal-keepalive 10
  next
end

自分が担当した案件で、拠点のルータを交換した直後にVPNが張れなくなったことがありました。原因は新ルータのNAT設定で、UDP 500/4500のパススルーが設定されていなかった点です。NAT-Tを有効にしたうえで、途中経路のFW/ルータでUDP 500とUDP 4500を許可するのがポイントです。

スプリットトンネルの設定と注意点

リモートアクセスVPNでよく使うスプリットトンネルは、VPN経由で通信する宛先と、ローカルインターネット経由で通信する宛先を分離する設定です。すべての通信をVPNに流すフルトンネルと比較して、VPN側の帯域を節約できます。

FortiGateでスプリットトンネルを有効にする場合、Phase2のローカルサブネットに社内ネットワークのみを指定します。「0.0.0.0/0」を指定するとフルトンネル、特定のサブネット（例：192.168.1.0/24）を指定するとスプリットトンネルになります。

注意点として、スプリットトンネルではリモート端末からインターネットへの通信がVPNを経由しません。セキュリティポリシーでリモート端末のインターネット通信もFortiGateのUTMで検査したい場合はフルトンネルを選択してください。

IPsec VPNの同時接続数と制限

FortiGateのIPsec VPN同時接続数はモデルによって異なります。ダイアルアップ（リモートアクセス）VPNの場合、FortiClient経由の接続数が上限に達するとそれ以降の接続が拒否されます。

モデル	IPsec VPNトンネル数（参考値）
FortiGate 40F	最大200
FortiGate 60F	最大500
FortiGate 100F	最大2,000
FortiGate 200F	最大2,000

正確な上限値はFortinetのデータシートで確認してください。get vpn ipsec tunnel summaryコマンドで現在のアクティブトンネル数を確認できます。接続数が上限に近い場合は機器のアップグレードを検討する必要があります。

FortiGate IPsec VPNの脆弱性と対策

FortiGateのVPN機能には過去に深刻な脆弱性が複数報告されています。特にCVE-2023-27997（ヒープオーバーフロー）やCVE-2024-21762（境界外書き込み）は実際に攻撃に悪用された事例があり、速やかなファームウェアアップデートが必要です。

脆弱性対策の基本

FortiOSのバージョンは常に最新のパッチバージョンに更新し、Fortinetのセキュリティアドバイザリ（PSIRT）を定期的に確認してください。VPNのWAN側インターフェースへの管理アクセスは無効化し、不要なサービスは閉じておくのが基本です。

自分が管理している環境では、FortiGateのファームウェア更新をCisco機器と同じ感覚で「年に1回でいい」と思っていた時期がありましたが、VPN関連の脆弱性が続出して以降、四半期ごとにPSIRTを確認する運用に切り替えました。

「peer sa proposal not match local policy」エラーの原因と対処法

FortiGateのIPsec VPNトラブルで、地味に遭遇率が高いのがこのエラー。diagコマンドでログを見ていると「peer sa proposal not match local policy」という1行がポツンと出てきて、そこからトンネルが一向に張られない。正直、初めて見たときは意味が分からなくて30分くらいログを眺めてた。

結論から言うと、これはIKE Phase1のプロポーザル不一致が原因。対向機器（相手側のルーターやファイアウォール）と自分のFortiGateで、暗号化パラメータが噛み合っていないときに出る。

📝 このエラーの意味

Phase1ネゴシエーションで相手が提示してきたSA（Security Association）プロポーザルが、自分のローカルポリシーと一致しなかった、ということ。つまり「お前の暗号化条件、うちと合ってないよ」と言われている状態。IKEv1でもIKEv2でも同じメッセージが出る。

不一致が起きる4つのパラメータ

Phase1で合わせなきゃいけないパラメータは主に4つ。どれか1つでもズレてたらこのエラーが出る。

パラメータ	確認コマンド	よくある不一致パターン
暗号アルゴリズム	config vpn ipsec phase1-interface	片方がAES256、もう片方がAES128
ハッシュアルゴリズム	show vpn ipsec phase1-interface	SHA256 vs SHA1（デフォルト値が機器で違う）
DHグループ	show vpn ipsec phase1-interface	Group 14 vs Group 5（FortiGateのデフォルトが変わった）
IKEライフタイム	show vpn ipsec phase1-interface	86400秒 vs 28800秒

💡 現場での体験談

以前、客先でFortiGate 60FとYAMAHA RTX1220の拠点間VPNを組んだとき、まさにこのエラーが出た。原因はDHグループ。FortiGateのファームウェアを7.2系にアップデートしたら、Phase1のデフォルトDHグループがGroup 14に変わっていたのに、YAMAHA側はGroup 2のまま。設定画面上はどちらも「デフォルト」と表示されていたから、パッと見では気づけなかった。明示的にDHグループを指定する癖をつけておくのが一番の予防策。

diagコマンドで不一致箇所を特定する

エラーが出ているのは分かったけど、具体的にどのパラメータがズレているのかはログだけでは分かりにくい。以下のdiagコマンドでIKEネゴシエーションの詳細を出力させる。

FortiGate # diagnose debug application ike -1
FortiGate # diagnose debug enable

このコマンドを叩いた状態でVPN接続を試みると、Phase1のネゴシエーション詳細がリアルタイムで流れてくる。注目すべきは以下のような出力。

ike 0:TRX:322: peer SA proposal not match local policy
ike 0:TRX:322: peer proposal: 1:1 (Enc aes-cbc-128 Auth sha1 DH group 2 Lifetime 28800)
ike 0:TRX:322: my proposal:   1:1 (Enc aes-cbc-256 Auth sha256 DH group 14 Lifetime 86400)

ここまで出てくれれば一発。peer proposalとmy proposalを見比べれば、どこが食い違っているか一目瞭然。上の例だと暗号化（AES128 vs AES256）、ハッシュ（SHA1 vs SHA256）、DHグループ（2 vs 14）、ライフタイム（28800 vs 86400）と全部違う。ちなみに、ライフタイムが違うだけならネゴシエーション自体は通ることもあるけど、他のパラメータは完全一致が必要。

⚠ 注意

diagコマンドのデバッグ出力は負荷が高いので、本番環境では必ず確認が終わったら「diagnose debug disable」で止めること。あと、出力量が多いと他のログも流れてくるので「diagnose debug console timestamp enable」でタイムスタンプを付けておくと、後から追いやすい。

修正前→修正後の設定例

対向がAES128 / SHA1 / DHグループ2 / ライフタイム28800秒で来ている場合、FortiGate側を合わせる設定例。

修正前（FortiGate側のデフォルト設定）

config vpn ipsec phase1-interface
  edit "to-remote-site"
    set proposal aes256-sha256
    set dhgrp 14
    set keylife 86400
  next
end

修正後（対向機器に合わせた設定）

config vpn ipsec phase1-interface
  edit "to-remote-site"
    set proposal aes128-sha1
    set dhgrp 2
    set keylife 28800
  next
end

で、設定を変更したら忘れずに接続をリセット。

FortiGate # diagnose vpn ike gateway clear
FortiGate # diagnose vpn tunnel reset

ただ正直、セキュリティ的にはAES128/SHA1/DH2はもう古い。可能であれば対向側もAES256/SHA256/DH14以上に上げるのが望ましい。「とりあえず繋がればいい」で古いパラメータに合わせるのは、あくまで暫定対応として考えておきたい。

IPsec VPNエラーメッセージ早見表

FortiGateのdiagコマンドやイベントログに出てくるIPsec VPN関連のエラーメッセージを一覧にまとめた。現場でエラーが出たら、まずここで当たりをつけてから詳細調査に入ると時短になる。

エラーメッセージ	原因	対処法
peer sa proposal not match local policy	Phase1プロポーザル不一致（暗号/ハッシュ/DH/ライフタイム）	diagでpeer/my proposalを比較し、パラメータを揃える
no matching peer id	Peer IDの検証失敗。相手の識別子がlocal-idと一致しない	set peer-id-validationをdisableにするか、正しいIDを設定
failed to get valid proposal	Phase2のプロポーザル不一致	Phase2の暗号化・PFS設定を対向と揃える
no SA proposal chosen	提案されたプロポーザルがすべて拒否された	両側のPhase1/Phase2設定を全パラメータ確認
invalid id received	IKE IDが期待値と異なる	local-id / peer-idの設定を確認、ワイルドカード許可を検討
pre-shared key does not match	事前共有鍵（PSK）の不一致	両側のPSKを再確認。コピペ時のスペース混入に注意
phase1 negotiation timed out	相手側からの応答がない（FW/ACL/経路の問題）	UDP 500/4500の疎通確認、経路・FWルールの確認
IPsec SA delete	SAが削除された（リキー失敗、手動クリア、相手側切断）	直前のログでリキー失敗がないか確認、ライフタイム設定見直し
encapsulation mode mismatch	トンネルモード/トランスポートモードの不一致	通常はトンネルモード。NAT-T環境の場合は特に注意

ちなみに、上記のエラーメッセージは「diagnose debug application ike -1」の出力やイベントログ（Log & Report > Events > VPN）の両方に出てくる。CLI操作が苦手な人はGUIのイベントログから探すのもあり。

Q. FortiGateのIPsec VPNでPhase1が失敗する主な原因は？

Phase1が失敗する原因は大きく3つ。まず一番多いのがプロポーザル不一致（暗号アルゴリズム、ハッシュ、DHグループ、ライフタイムのどれかが対向と合っていない）。次に事前共有鍵（PSK）の不一致。これはコピペ時に末尾にスペースが入っていたりするパターンが意外と多い。3つ目はネットワーク到達性の問題で、UDP 500番ポートやUDP 4500番ポート（NAT-T用）が途中のファイアウォールやACLでブロックされているケース。diagコマンドで「phase1 negotiation timed out」と出るなら3つ目を、「peer sa proposal not match」と出るなら1つ目を疑うのが定石。

Q. 「peer sa proposal not match local policy」が出たらまず何をすべき？

まずは「diagnose debug application ike -1」と「diagnose debug enable」を実行して、IKEネゴシエーションの詳細ログを出す。ログの中に「peer proposal」と「my proposal」が並んで表示されるので、暗号アルゴリズム・ハッシュ・DHグループ・ライフタイムの4項目を1つずつ比較する。食い違っているパラメータが見つかったら、どちらかの機器に合わせて修正すればOK。確認が終わったら「diagnose debug disable」でデバッグを止めるのを忘れずに。

Q. FortiGateのIPsec VPNで「phase1 negotiation timed out」と出る原因は？

このエラーは相手側から応答が返ってきていない状態。原因としては、対向機器のIPアドレスやFQDNの設定ミス、途中経路のファイアウォールでUDP 500/4500がブロックされている、対向機器のVPN設定がそもそも入っていない（またはdisableになっている）、ISP側でIPsecパススルーが制限されている、あたりが代表的。まずは対向のグローバルIPに対してUDP 500のポートスキャンやtracerouteで経路を確認して、ネットワーク層の疎通を切り分けるのが先。

よくある質問（FAQ）

Q. FortiGateのIPsec VPNで確認すべきコマンドは？

まず「diagnose vpn ike gateway list」でPhase1の状態、「diagnose vpn tunnel list」でPhase2の状態を確認します。トンネルが確立されていれば「established」と表示されます。パケットカウンタが増えていない場合はルーティングかポリシーの問題を疑ってください。

Q. IPsec VPNが頻繁に切れる原因は？

DPD（Dead Peer Detection）のタイムアウト設定が短すぎるケースが多いです。Phase1の設定でDPDの間隔とリトライ回数を確認してください。またキープアライブの設定値が対向機器と合っていない場合もトンネルが不安定になります。WAN回線の品質が悪い環境ではタイムアウト値を長めに設定すると安定する場合があります。

Q. SSL-VPNからIPsec VPNに移行すべき？

FortinetはFortiOS 7.6以降でSSL-VPNの新規設定を非推奨としています。既存環境からの移行は、IPsec VPNのリモートアクセス設定（ダイアルアップVPN）+ FortiClientの組み合わせで代替可能です。移行時はFortiClientの配布とユーザーへの設定案内を計画的に進めることが重要です。

Q. FortiGate同士の拠点間VPNでおすすめの暗号化方式は？

IKEv2 + AES256 + SHA256 + DH Group 14以上を推奨します。DH Group 5（1536bit）以下は現在では強度不足とされているため、新規構築ではGroup 14（2048bit）またはGroup 20（ECP 384）を選択してください。対向がCiscoやYamahaなどの他ベンダーの場合は、双方でサポートしている暗号スイートを事前に確認しておく必要があります。

まとめ

VPNがつながらないときは「Phase1が上がるか」「Phase2で止まっているか」で切り分けて、ログを見ながら一つずつ原因を潰していくのが基本です。

Phase1落ち：PSK・IKEバージョン・ポート500/4500・対向IPを確認
Phase2落ち：暗号方式・PFS・Quick Mode Selectorを確認。通信を発生させてから確認する
diagnose debug application ike -1でIKEログを取る。終わったら必ずdiagnose debug disableする
エラーキーワード（no proposal chosen・INVALID_ID_INFORMATION・negotiation timeout）を覚えると解決時間が大幅に短縮される
Phase1・Phase2がUPでも通信できないなら、ポリシー・ルート・NATを確認する
diagnose debug flowでフロートレースを取ると、どこでパケットが落ちているかが一目でわかる

FortiGateはトラブル対応にCLIが強い味方になります。現場で詰まりやすいポイントを押さえておけば、いざというときに焦らず対応できます。

YouTubeでも解説してます