FortiGate IPsec VPNが繋がらない時｜Phase1/2エラー原因と対処

2025年7月12日2026年4月16日

トラブルシューティング

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 で経路を追跡

まとめ

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でも解説してます