ネットワークエンジニアがFortiGateでサイト間VPNを構築する際に遭遇しやすい問題のひとつが、「トンネルが張れない」という現象です。特にIPsec VPNでは、設定が一見正しくても通信が確立しないケースがあります。その原因の多くがFirewallポリシー未設定に起因しています。 本記事では、なぜFortiGateではFirewallポリシーが必須なのか、その設計思想から実際のトラブルシュート方法までを解説します。
FortiGateの設計思想：VPNはFirewallポリシーと連動する
Ciscoルータや他ベンダーの装置と比較すると、FortiGateの大きな特徴は「VPNをFirewallポリシーに紐づけて通信を制御する」点です。 FortiGateはUTM/NGFWとしての性質が強いため、VPNそのものを「セキュリティポリシーに基づいて通す通信経路」として扱います。したがって、ポリシーが存在しない場合、そのVPNトンネルは機能しません。
Phase1とPhase2の違いとポリシー依存性
- Phase1 (IKE SA)： 鍵交換プロセス。これはポリシーがなくても成立します。
- Phase2 (CHILD SA)： 実際の通信を通すためのセッション。この段階でFirewallポリシーが必須となります。未定義だとSAが作成されません。
つまり、「VPNが張れない」と感じるケースの多くは、Phase1は成功しているがPhase2が失敗しているという状態です。ログには no policy configured や negotiation failure といったエラーが出力されるのが典型です。
実務でのチェックポイント
FortiGate間でIPsec VPNを構築する場合、以下の点を必ず確認しましょう。
- VPN ↔ LAN 双方向のポリシーを作成 一方向のみのポリシーでは通信が片道しか通らず、実質的にVPNが機能しません。
- NATを無効化（サイト間VPNの場合） 企業拠点間のVPNでは基本的にNATは不要です。NATが有効になっていると、想定外のアドレス変換でPhase2が失敗することがあります。
- Phase2セレクタ（local/remote）を一致させる 双方のFortiGateで設定するローカルサブネットとリモートサブネットが食い違うと、SAは確立できません。
よくある誤解と比較（Ciscoルータとの違い）
Ciscoルータの場合、VPNトンネルが確立すればデフォルトで通信が可能になるケースも多くあります。 一方、FortiGateでは「明示的に許可した通信のみ通す」というセキュリティ思想のため、ポリシーなしでは通信できません。 そのためCiscoルータからFortiGateに移行したエンジニアは「設定したのにVPNが張れない」と戸惑いやすいのです。
トラブルシューティングの実例
以下は実際の現場で多いケースです。
- VPN設定は正しいが、Firewallポリシーを作成していなかった → Phase1は成功、Phase2失敗
- NATオプションを誤って有効化していた → トラフィックが変換されてセレクタ不一致
- 片方向のみのポリシー → 片側からは通信可能だが戻りトラフィックが遮断
これらはすべて「FirewallポリシーがVPNに紐づいている」というFortiGate特有の挙動を理解すれば回避可能です。
まとめ
FortiGateで「IPsec VPNが張れない」とき、まず確認すべきはFirewallポリシーの有無です。 Phase1が成功していても、ポリシーがなければPhase2は成立せず、VPNは実際には使えません。 実務では以下を必ず意識しましょう：
- VPN ↔ LAN 双方向ポリシーを作成する
- サイト間VPNではNATを無効化する
- Phase2セレクタを正しく設定する
この仕組みを理解すれば、FortiGate特有のVPN構築におけるトラブルを大幅に減らすことができます。 「Cisco ルータ 設定」との違いを意識しつつ、FortiGateの「Firewallポリシー必須」の特性を理解しておくことが、安定したVPN運用の第一歩です。
