FortiGate IPsec VPN 複数回線冗長化の切替失敗を切り分け｜確認手順

現場でよくあるのが「平常時は拠点間IPsecが安定しているのに、回線切替（フェイルオーバー/フェイルバック）した瞬間だけ通信が死ぬ」「片方向だけ通る」「数分戻らない」です。
この記事は一般的なVPN不通ではなく、FortiGate IPsec VPN 複数回線 冗長化で切替時だけ起きるトラブルに絞って、私が実際に使う順序で切り分けます。

移行前チェックの優先度

対象構成の前提と、よくある3パターン

以降は「拠点AのFortiGate ↔ 拠点BのFortiGate/他社装置」を想定します。冗長化は大きく3パターンあります。

アーキテクチャ（テキストフロー）と、切替時に起きること

LAN(A) → Policy →（SD-WAN選択）→ IPsec_Tunnel_A(Primary) → Internet → 対向GW → LAN(B)
                └→ IPsec_Tunnel_B(Backup)  → Internet → 対向GW → LAN(B)
戻り: LAN(B) → 対向GWの経路/ポリシー → (同じトンネルで返す必要がある)

切替失敗の多くは、切替後に「片道はBackupトンネル、戻りはPrimaryのまま」などの非対称になり、FortiGateのステートフル処理（セッション/ポリシー）や対向側の実装で落ちます。

切替失敗の確認手順（routing→sniffer→session→IKE/IPsec）

ここからは手順書として使える粒度で書きます。私は「切替の瞬間」だけでなく、切替後30〜60秒も含めて観測します（SLAの判定/ホールドで挙動が変わるため）。

get router info routing-table details <対向LANセグメント>
get router info routing-table all

# SD-WAN利用時
diagnose sys sdwan health-check
diagnose sys sdwan service

• NG例：routing-tableで次ホップ/デバイスがPrimaryのまま。→ SD-WANルール、静的ルート距離、PBR条件を先に直す。
• NG例：SD-WAN health-checkがDownになっているのに、serviceがまだPrimaryを掴む。→ SLAのfailtime/recoverytime、hold-down相当の設定、優先度を見直す。

# トンネルIFでLAN側→対向LANの通信を見る
diagnose sniffer packet any 'host 10.10.10.10 and host 10.20.20.20' 4 0 a

# 片方向疑いなら、LAN側IFでも同じ条件で見る
diagnose sniffer packet <lan_if> 'host 10.10.10.10 and host 10.20.20.20' 4 0 a

• 症状→判断：送信は見えるが戻りが見えない → 対向側の戻り経路（SD-WAN/静的/PBR/ポリシー）か、対向側が別トンネルへ返している可能性。
• 症状→判断：戻りは来ているのにLANへ出ていかない → FortiGate側のポリシー順序/UTM/NAT、またはセッション不整合の可能性。

diagnose sys session filter clear
diagnose sys session filter src 10.10.10.10
diagnose sys session filter dst 10.20.20.20
diagnose sys session list

セッションの読み方は別記事に寄せます：FortiGate session tableの確認と詰まりどころ

# IKE SAの状態
diagnose vpn ike gateway list
diagnose vpn ike gateway list name <tunnel_name>

# IPsec SA（Phase2）の状態
diagnose vpn tunnel list
diagnose vpn ipsec sa

# 必要に応じてデバッグ（実施後は必ずoff）
diagnose debug reset
diagnose debug console timestamp enable
diagnose debug application ike -1
diagnose debug enable
# ...切替/再接続を実施...
diagnose debug disable

• 典型症状：切替後にIKE SAが別ゲートウェイで張られない／張り直しが遅い → 対向から見た送信元IP（回線のPublic IP）が変わっており、対向側のピア条件に合っていない可能性。
• 典型症状：IKEはupだがPhase2が不足/Down → セレクタ（proxy-id）不整合、またはトンネルごとのPhase2重複が疑い。
• 典型症状：ログにproposal/selector関連が出る → 既存記事のエラー別整理に逃がす：peer SA proposal対処（提案不一致）

論点別：典型症状→確認→判断→対処（最低1セットずつ）

1) 戻り非対称（片方向）

2) SD-WAN SLA設計ミス（Down判定がズレる/揺れる）

私がよく見る失敗は「プローブが実際の出口を通っていない」「sourceが固定されていない」「閾値が厳しすぎて揺れる」です。

• probe宛先：回線A/Bそれぞれで到達してほしい先を2つ用意（同一ASに偏らない）
• source：WANインターフェースのIP（回線ごとの出口を固定）
• 閾値：packet loss/latency/jitterは「業務アプリが耐えられる範囲」から逆算。いきなり厳しくしない
• 揺れ対策：failtime/recoverytime、復旧後もしばらくPrimaryに戻さない運用（時間帯で戻す等）も検討

3) Phase2セレクタ/プロキシID（重複・不足）

冗長化でトンネルを2本作ると、同じローカル/リモートサブネットを両方に入れがちです。FortiGate同士なら成立することもありますが、対向が他社装置やクラウドゲートウェイの場合、受け側の実装で不安定になることがあります。

diagnose vpn tunnel list
# 出力で、どのtunnelにどのproxyid/selectorが紐づいているかを確認

対処は「セレクタを役割分担（例：通常系/バックアップ系で経路を明確化）」か、「対向仕様に寄せて1本に集約＋回線冗長はUnderlay側で行う」など。どちらが取れるかは対向依存です。

4) NAT/ポリシー順序（切替後にだけ踏む）

切替でトンネルIFが変わると、ポリシーのfrom/toが一致せず、暗黙denyに落ちることがあります。UTMを掛けているとログの見え方も変わります。

# forward traffic のdeny/accept、policyid、srcintf/dstintf を見る
# GUI: Log & Report → Forward Traffic
# CLI例（環境によりフィルタは調整）
diagnose log filter category 0
diagnose log filter field logid 0000000013
# showでも十分だが、運用ポリシーに合わせて確認

判断基準：切替後にsrcintf/dstintfが変わっているのに、ポリシーが追従していない。対処はポリシー追加/統合、またはzone化でトンネルをまとめる等（ただし既存設計への影響は要評価）。

5) セッション固定（古い経路のまま）

切替直後だけ詰まる・数分で戻る場合、セッションタイムアウト待ちのことがあります。影響を最小にするなら「該当通信だけ」落とします。

diagnose sys session filter clear
diagnose sys session filter src 10.10.10.10
diagnose sys session filter dst 10.20.20.20
diagnose sys session clear

切替テスト手順（回線断/復旧、収束時間、切り戻し条件、ログ）

一般的な「VPNがつながらない」観点も併用すると漏れが減ります：FortiGate VPN不通で最初に見るポイント

関連読み（深掘りは既存記事に分離）

まとめ（現場で迷わない最短ルート）

FAQ

まとめ