FortiGateのIPsec VPNで peer SA proposal not match local policy が出ると、ログの英語は短いのに原因候補が多くて嫌になります。Phase1の暗号化方式なのか、認証方式なのか、NAT Traversalなのか。画面だけ見ていると、けっこう沼。
この記事では、FortiGate IPsec VPNが繋がらない時に、このエラーをどう切り分けるかを現場手順でまとめます。対象はFortiGate同士、FortiClient、他社FWとの拠点間VPN。Fortinet公式のトラブルシュートでも、P1/P2 proposalの一致とIKEデバッグ確認が基本線です。
peer SA proposal not match local policyの意味
ざっくり言うと、対向機器が提示してきたIKE/IPsecの条件を、FortiGate側のローカル設定が受け入れられない状態です。英語のまま読むと「相手のSA proposalがこちらのポリシーと合っていない」。そのまんまですね。
ただし、ここで言うproposalは暗号化アルゴリズムだけではありません。IKEバージョン、認証方式、DHグループ、ローカルID、リモートID、NAT-T、場合によっては接続先IPの勘違いまで絡みます。ログ1行だけで決め打ちしないほうがいいです。
以前、夜間メンテでFortiGate 100Fと他社FWをつないだ時、このエラーで30分ほど止まりました。こちらはIKEv2、AES256/SHA256/DH14。対向は資料上同じ。ところが実機はDH5のまま残っていて、IKEデバッグにincoming proposalが出て初めて気づきました。Excelのパラメータシートを信じすぎると痛いです。
最初に疑う原因と優先順位
Search Consoleではエラー文そのものと、fortigate ipsec vpn 繋がらない が出ています。読者が欲しいのは理屈より先に「どこを見るか」。なので、まずは発生頻度と切り分けやすさで並べます。
図1: 現場で疑う頻度の目安
90%
70%
45%
| 原因候補 | 見る場所 | よくあるズレ |
|---|---|---|
| Phase1 proposal | 暗号化/認証/DH | AES256とAES128、DH14とDH5 |
| IKEバージョン | IKEv1/IKEv2 | 片側だけIKEv2 |
| ID/PSK | localid/peerid/事前共有鍵 | NAT配下でID未指定 |
diagnose debug application ikeで確認する
GUIのログだけで追うより、IKEデバッグを取ったほうが早いです。Fortinet公式ドキュメントでも、IPsec関連の確認では diagnose vpn ike gateway list やIKE debugを使います。FortiOS 7.4.1以降はログフィルタの書き方が変わっている点だけ注意。
diagnose vpn ike log filter rem-addr4 203.0.113.10 diagnose debug console timestamp enable diagnose debug application ike -1 diagnose debug enable
diagnose debug disable diagnose debug reset
本番機で diagnose debug application ike -1 を無フィルタで長時間流すのはおすすめしません。複数VPNがある環境だとログが一気に増えます。必ず対向IPで絞り、取得後は diagnose debug reset まで戻します。
Phase1とPhase2の設定差分を見る
エラー名だけ見るとPhase1っぽいですが、Phase2のselectorやproposal不一致で似た症状になることもあります。まずPhase1でIKE SAが張れるか、その後Phase2でIPsec SAが張れるかを分けて見ます。
show vpn ipsec phase1-interface VPN-TOKYO show vpn ipsec phase2-interface VPN-TOKYO-P2 diagnose vpn ike gateway list name VPN-TOKYO
| 確認項目 | FortiGate例 | 対向と合わせる点 |
|---|---|---|
| IKE version | set ike-version 2 | IKEv1/IKEv2 |
| Phase1 proposal | aes256-sha256 | 暗号/認証/PRF |
| DH group | set dhgrp 14 | グループ番号 |
| Phase2 selector | 10.10.10.0/24 → 10.20.20.0/24 | 左右のlocal/remote |
設定を直す時の安全な順番
いきなり両端を同時に変更すると、何で直ったか分からなくなります。私は、ログでズレを見て、片側ずつ最小変更、再ネゴシエーション、状態確認の順で進めます。地味だけど早い。
config vpn ipsec phase1-interface
edit "VPN-TOKYO"
set ike-version 2
set proposal aes256-sha256
set dhgrp 14
set nattraversal enable
next
end
このコマンドは例です。対向がAES128/SHA256/DH14なら、こちらもそこに合わせます。セキュリティ的には強い値を選びたいですが、まずは両端一致が先。あとから標準化すればOKです。
他社FWやFortiClient相手では、表示名が同じでも中身が違うことがあります。特にIKEv2のPRF、DH group、ローカルIDは見落としやすいです。対向画面のスクショだけでなく、可能なら設定エクスポートで確認します。
復旧後に見るコマンド
設定を合わせたら、トンネルがupしたか、セレクタに合う通信が流れているか、ポリシーとルートが通っているかを確認します。Phase1だけupで満足すると、実通信でまた詰まります。
get vpn ipsec tunnel summary diagnose vpn tunnel list name VPN-TOKYO diagnose sniffer packet any 'host 10.20.20.10 and icmp' 4 execute ping-options source 10.10.10.1 execute ping 10.20.20.10
ここで片方向だけ通らない場合は、proposalではなくポリシー、ルート、NAT、戻り経路を疑います。エラーが消えたあとに通信が通らない、これも現場ではよくあります。
peer SA proposalでハマるパターン
最後に、私が見た中で多かったものを表にします。ここだけ見ても、だいたい初動の当たりは付けられます。
| ログ/症状 | 原因 | 対処 |
|---|---|---|
| no proposal chosen | 暗号/認証/DH不一致 | incoming proposalと設定を比較 |
| Phase1だけ失敗 | IKE version/ID/PSK | localid/peeridを確認 |
| NAT配下で失敗 | NAT-Tや接続先IP | nattraversalとremote-gw確認 |
まとめ
peer SA proposal not match local policy は、まずPhase1 proposal、IKE version、DH group、ID/PSKを疑います。IKEデバッグは対向IPで絞って短時間だけ取得。設定変更は片側ずつ、復旧後はPhase1/Phase2と実通信まで確認します。雑に直すと、次のメンテでまた同じところに戻ってきます。
よくある質問（FAQ）
Q. peer SA proposal not match local policyはPhase1のエラーですか？
多くはPhase1側のproposalやIKE条件の不一致で出ます。ただ、Phase2やIDの問題が絡むこともあります。IKEデバッグでincoming proposalを見てから判断するのが安全です。
Q. FortiGate同士なら何を最初に合わせますか？
IKE version、proposal、DH group、PSK、local/remote subnetの順に見ます。GUIで同じに見えても、CLIで見ると値が違うことがあります。
Q. 設定を合わせてもVPNが繋がらない場合は？
Phase1/Phase2の状態を確認し、その後にポリシー、ルート、NAT、戻り経路を見ます。proposalエラーが消えた後の通信不可は、別問題として切り分けます。
