【保存版】FortiGate IPsecVPN ~トラブルシューティング編~

IPsec VPNの構築において、設定を入れた後に「繋がらない」「切れる」といったトラブルはつきものです。
今回は、実際の現場で発生したトラブルとその解決策をまとめました。

コマンドをそのままコピーして使えるよう整理していますので、保守・運用時の備忘録としてご活用ください。

目次

1. IPsecVPNの接続ができない

【事象】
IPsecVPNの接続が確認できない。

診断・対処

  • 設定確認:
    show vpn ipsec phase1-interface <設定名>
    show vpn ipsec phase2-interface <設定名>
    • 設定を確認。
    • 対向側の設定と一致しているか確認します。
  • 状態確認
  • phase1の状態確認
    diagnose vpn ike gateway list
    • status: establishedが出ていればPhase 1は成功している。
  • phase2の状態確認
    diagnose vpn tunnel list
    • sa: mode=0: 0なら有効(Mature)です。
    • stat: rxp=... txp=...: 受信(rx)と送信(tx)のパケット数。片方が0のまま増えない場合は、ルーティングやFirewallポリシー、あるいは対向側の問題が疑いあり。
  • IPsec全体の状態確認
    get vpn ipsec tunnel details
    • 各トンネルのプロトコル、アルゴリズム、有効期限(Expiry)が一覧で出ます。
    • state: mature になっているかを確認します。
  • 主な原因:
    • 設定の不一致
  • 対処: 設定 を対向と完全に一致させる。

2. デバッグログから通信の状態を確認する

【事象】
トンネルは繋がったが、本当に正しく通信できているか確認したい。
トンネルが繋がらず、通信ログを確認したい。

検証コマンド

  • デバッグの開始
    diagnose debug reset  #前回のデバッグ設定をリセット
    diagnose debug application ike -1  #IKE(VPN制御)のログを最大レベル(-1)で指定
    diagnose debug console timestamp enable  #各ログに時間を表示(重要!)
    diagnose debug enable  #デバッグの出力を開始
  • デバッグ中のログ確認方法
    diagnose debug enable を打った瞬間から、画面にログが次々と表示されます。
    ログの読み方のコツ
    大量に流れますが、以下のキーワードを探してください。
    NOTIFY(NO_PROPOSAL_CHOSEN): 暗号化方式(AESやSHAなど)やDHグループが相手と合っていません。
    NOTIFY(INVALID_ID_INFORMATION): フェーズ2のセレクタ(IPアドレスの範囲)が相手と合っていません。
    NOTIFY(AUTHENTICATION_FAILED): プレシェアードキー(PSK)が間違っています。
    REKEY: 鍵の更新処理が始まったことを示します。
    SSH(Teraterm等)で接続している場合、ログが速すぎて画面が流れてしまいます。「ログの保存(ログ取得)」機能を有効にした状態で実行することをお勧めします。
    errorやfailの文字あたりのログから原因を探ります。
  • デバッグの停止
    diagnose debug disable  #デバッグ出力を停止
    diagnose debug reset  #設定をクリア

3. VIP / ポリシー設定(DNAT+SNAT構成)

【事象】
クライアントが仮想IP(VIP)を宛先にして、対向サーバーへ到達させたい。

設定のポイント

  • 作成要素:
    1. Firewall VIP: 仮想IP(External)を対向実IP(Mapped)に紐付け
    2. IP Pool: 送信元変換(SNAT)用のIP
    3. ポリシー: internalvpn_tun1(宛先:VIP, NAT有効:ippool使用)
  • 注意点: 宛先IPの末尾が .255 だとブロードキャスト扱いになるリスクがあるため、可能な限り避けるのが無難です。

4. Phase2が短時間でダウンする(フラップ)

【事象】
ログに delete_phase2_sa などが残り、不安定な状態。

切り分けポイント

  • ログの特定: Event Logで時刻を確認。
  • 主要原因:
    • Rekey (Lifetime) の設定差
    • DPD (Dead Peer Detection) のタイムアウト
    • ネットワーク経路の不安定(ISP側の瞬断など)
  • 対処: DPDやLifetimeの設定を緩和し、対向と設定を突合する。

5. ルーター自身からのPingが通らない

【事象】
FortiGate自身のIPアドレスからは通らないが、SNAT後のIPアドレスなら通る。

診断と原因

  • 原因: Phase2の Selector (Proxy-ID) が、SNAT後のIPのみを許可しており、ルーター自身のIPはトンネルを通す対象から外れている。
  • 対処: execute ping-options source <SNAT後のIPアドレス> のように、許可されているIPをソースに指定してテストを行う。

6. 「unknown SPI」ログが大量に出る

【事象】
ログに Received ESP packet with unknown SPI が継続して記録される。

解析と根本対処

  • 意味: ローカルSAと一致しないESP(プロトコル50)パケットを受信し、エラーを吐いている状態(古いセッションやスキャンの可能性)。
  • 対処(Local-in-Policyでの遮断):許可するピアのみを通し、それ以外を早期にDROPする設定を入れる。Bash# ESP(プロトコル50)のカスタムサービス作成
    config firewall service custom
    edit "ESP_proto50"
    set protocol IP
    set ip-proto-number 50
    next
    end

    # local-in-policyで拒否
    config firewall local-in-policy
    edit <ID>
    set intf "wan1"
    set srcaddr "all"
    set dstaddr "all"
    set action deny
    set service "ESP_proto50"
    set schedule "always"
    next
    end

まとめ:推奨される運用フロー

  1. 設定確認: まずは冷静に設定を確認。対向と設定が合っているか確認する。src-subnet/dst-subnetにも注意する。
  2. 成立後: 状態、カウンタ、ログを確認し、双方向通信を検証。
  3. 不要ログ: local-in-policy を活用し、管理プレーンへの不要なパケットを早期に遮断。

実務でIPsecを運用する際、これらのコマンドをすぐ叩ける状態にしておくだけで、復旧スピードが劇的に変わります。ぜひブックマークして活用してください。

この記事が気に入ったら
フォローしてね!

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

著者

40代の現役インフラエンジニア。
趣味はメダカと観葉植物。
実務で役立つAI活用術を発信中!

コメント

コメントする

目次