MENU

FortiGate IPsec VPN の構築手順｜IKEv2 と NAT 越えの設定例

Security
  • URLをコピーしました！
目次

はじめに

FortiGate を用いた拠点間 VPN（IPsec VPN）は、両拠点が固定 IP を持つシンプルな環境であれば設定は容易ですが、実務では「片方の拠点が動的 IP（PPPoE）である」「拠点間で LAN の IP アドレスが重複している」といった条件付きの構成 に遭遇するケースが少なくありません。

本記事では、FortiOS 7.6 系 を前提に、これら 2 つのシナリオを IKEv2 ベース で構築する手順を CLI 設定例とともに解説します。IKEv1 は RFC 9395（2023 年 4 月）で正式に Deprecated 化されており、新規構築では IKEv2 を選定することが推奨されます。

なお、SSL-VPN から IPsec への移行を急ぐ背景や FortiOS 7.4 のサポート期間延長（EOES 延長）の動向については、関連記事『FortiOS 7.4 サポート延長の背景と SSL-VPN 廃止に伴う移行の現実』で詳しく解説しています。

IPsec の仕組みや IKE のフェーズ・アルゴリズムなど基礎部分については、関連記事『IPsec の仕組みと IKEv1 廃止｜ESP・SA・NAT-T の落とし穴』をあわせてご参照ください。

この記事でわかること
  • FortiOS 7.6 における IPsec VPN 設計の前提（IKEv2／Route-based／推奨アルゴリズム）
  • 動的 IP の支店を Hub-and-Spoke で収容する IKEv2 設定（Network ID 利用）
  • 拠点間で IP アドレスが重複する場合の NAT 利用型 VPN 設定
  • diagnose vpn ike gateway list 等を使ったトラブルシューティング手順
  • 実装上のハマりポイント（Aggressive Mode の脆弱性、ASIC オフロード、HA 構成）

IPsec VPN の構築パターンと選び方

設定コマンドを入力する前に、構築する VPN が以下のどちらのパターンに該当するかを確認します。本記事では実務で頻出する以下 2 つのシナリオを取り上げます。

Hub-and-Spoke 構成（動的 IP 対応）

本社（Hub）と支店（Spoke）を接続する一般的な構成です。支店側のインターネット回線が動的 IP（PPPoE など）であっても、固定 IP を持つ本社側で待ち受ける形で VPN を確立します。

以下のような環境向けです。

  • 一般的な拠点間 VPN を構築したい
  • 支店側のグローバル IP アドレスが固定ではない（動的 IP）
  • 拠点間で LAN 側の IP アドレス（サブネット）は重複していない

NAT 利用型 VPN 構成（IP 重複対応）

VPN トンネルを通る通信の送信元・宛先 IP アドレスを、NAT（アドレス変換）によって書き換える構成です。通常、IPsec VPN は拠点間でサブネットが重複していると通信できませんが、NAT を挟むことでこれを回避します。

以下のような環境向けです。

  • 企業合併などで、接続先と自社の IP アドレス体系（例: 192.168.1.0/24 同士）が重複している
  • セキュリティ上の理由で、内部 IP アドレスを相手に見せたくない

構成パターンの選び方

状況選択する構成
IP アドレスが重複していないHub-and-Spoke 構成
IP アドレスが重複しているNAT 利用型 VPN 構成

FortiGate IPsec VPN の設計前提

具体的な設定例に入る前に、FortiOS 7.6 における IPsec VPN の設計上の前提を整理します。

IKE バージョンは IKEv2 を選定

新規構築では IKEv2（set ike-version 2） の選定が推奨されます。FortiOS のデフォルトは IKEv1 のため、明示的にバージョンを指定する必要があります。

参考: FortiOS 7.6 – Customizing IPsec tunnel settings
“However, peer ID functionality is limited with IKE version 2 because the peer ID is not included in the initial IKE message. … Thus, for IKEv2, it is recommended to instead use Network ID field within Phase 1 tunnel.”
（IKEv2 では初回 IKE メッセージに Peer ID が含まれないため Peer ID 機能に制限があります。そのため IKEv2 では Phase 1 トンネル内で Network ID フィールドを使うことが推奨されます）
https://docs.fortinet.com/document/fortigate/7.6.0/ssl-vpn-to-ipsec-vpn-migration/690046/customizing-ipsec-tunnel-settings

IKEv1 は RFC 9395 で Deprecated 化されており、新規構築では IKEv2 が推奨されます。ただし、対向機器が IKEv2 非対応のレガシー機器である場合は IKEv1 を選択せざるを得ないケースがあります。その場合の構成例も後述します。

Route-based VPN（Tunnel Interface）を選定

FortiOS には Route-based VPN と Policy-based VPN の 2 種類がありますが、現行の FortiOS では Route-based VPN（config vpn ipsec phase1-interface）が推奨されます。Policy-based VPN は新しい機能の多くが Route-based 専用となっており、新規構築での採用は避けることが推奨されます。

項目Route-based VPNPolicy-based VPN
トンネルインターフェイス仮想インターフェイスとして作成作成されない
ルーティングスタティックルートまたは動的ルーティングファイアウォールポリシーで制御
動的ルーティング対応非対応
FortiOS の推奨推奨レガシー扱い

本記事では Route-based VPN（phase1-interface / phase2-interface）を使用します。

推奨アルゴリズムと PSK の強度

FortiOS では明示的に Phase 1／Phase 2 のプロポーザル（暗号方式）を指定できます。新規構築では以下の組み合わせを選定することが推奨されます。

項目推奨設定
Phase 1 暗号化AES-GCM-256 または AES-256-CBC + SHA2-384
Phase 1 DH グループGroup 14（2048 bit MODP）以上、可能であれば Group 19/20（ECP）以上
Phase 2 暗号化AES-GCM-256（AEAD で性能・安全性ともに優位）
Pre-Shared Key16 文字以上のランダム英数字

参考: Fortinet – IPSec Phase 1 parameters
“For optimum protection against currently known attacks, the key must consist of a minimum of 16 randomly chosen alphanumeric characters.”
（現時点で既知の攻撃から十分に保護するため、PSK は 16 文字以上のランダムな英数字で構成することが推奨されます）
https://www.fortinetguru.com/2017/10/ipsec-phase-1-parameters/

基本設定: Hub-and-Spoke 構成（動的 IP 対応）

最も利用頻度の高い基本構成です。本社側（Hub）は固定 IP、支店側（Spoke）は PPPoE などの動的 IP を使用している環境を想定します。

IKEv2 + Network ID 構成（推奨）

Phase 1（Interface Mode）の設定

複数の Spoke を 1 つの Hub で収容する場合、IKEv2 では Network ID で各 Spoke を識別する のが FortiOS 7.6 の公式推奨です。

Hub 側（FG01）: 受け入れ設定

Spoke の IP アドレスが固定でないため、set type dynamic で待ち受け、set network-overlay enable + set network-id で Spoke を識別します。

config vpn ipsec phase1-interface
    edit "VPN-to-Spoke"
        set interface "wan1"
        set ike-version 2                       # IKEv2 を指定
        set type dynamic                        # 相手の IP を指定せず待ち受ける
        set network-overlay enable              # Network ID 機能を有効化
        set network-id 100                      # この Spoke を識別する ID
        set proposal aes256gcm-prfsha384        # Phase 1 暗号化提案
        set dhgrp 20 19 14                      # DH グループ（強度の高い順）
        set psksecret <16文字以上のランダム文字列>
    next
end

Spoke 側（FG02）: 接続設定

Spoke は固定 IP の Hub に対して接続するため remote-gw を明記し、Hub 側と同じ Network ID を指定します。

config vpn ipsec phase1-interface
    edit "VPN-to-Hub"
        set interface "wan1"
        set ike-version 2
        set remote-gw 1.1.1.1                   # Hub 側の固定 IP
        set network-overlay enable
        set network-id 100                      # Hub 側と同じ ID
        set proposal aes256gcm-prfsha384
        set dhgrp 20 19 14
        set psksecret <16文字以上のランダム文字列>
    next
end

参考: FortiOS 7.6 – Customizing IPsec tunnel settings
https://docs.fortinet.com/document/fortigate/7.6.0/ssl-vpn-to-ipsec-vpn-migration/690046/customizing-ipsec-tunnel-settings

Phase 2 の設定

トンネル内で「どのネットワーク帯の通信を通すか」を定義します。

Hub 側（FG01）

config vpn ipsec phase2-interface
    edit "VPN-to-Spoke"
        set phase1name "VPN-to-Spoke"
        set proposal aes256gcm                  # Phase 2 暗号化提案
        set src-subnet 192.168.100.0 255.255.255.0   # 自分の LAN
        set dst-subnet 192.168.200.0 255.255.255.0   # 相手の LAN
    next
end

Spoke 側（FG02）

Hub 側と逆の設定（送信元と宛先を入れ替え）を行います。

config vpn ipsec phase2-interface
    edit "VPN-to-Hub"
        set phase1name "VPN-to-Hub"
        set proposal aes256gcm
        set src-subnet 192.168.200.0 255.255.255.0
        set dst-subnet 192.168.100.0 255.255.255.0
    next
end

ファイアウォールポリシーとルーティング

ファイアウォールポリシー（双方向許可）

VPN インターフェイスと LAN インターフェイス間の通信を許可します（以下は Hub 側の例。Spoke 側も同様の設定が必要です）。

config firewall policy
    edit 1
        set name "VPN-Inbound"
        set srcintf "VPN-to-Spoke"              # VPN から入ってくる
        set dstintf "lan"                       # LAN へ抜ける
        set srcaddr "all"                       # Phase 2 で制限済みのため all で問題なし
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
    next
    edit 2
        set name "VPN-Outbound"
        set srcintf "lan"
        set dstintf "VPN-to-Spoke"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
    next
end

スタティックルート

相手の LAN 宛てのパケットを VPN トンネルへ向けるルートを追加します。

config router static
    edit 1
        set dst 192.168.200.0 255.255.255.0     # 相手の LAN
        set device "VPN-to-Spoke"               # 出口は VPN インターフェイス
        set distance 10                         # 既存のデフォルトルートより優先する場合に調整
    next
end

IKEv1 構成（互換性目的の代替）

対向機器が IKEv2 非対応のレガシー機器である場合に限り、IKEv1 を選択する構成例を以下に示します。

Hub 側（FG01）

config vpn ipsec phase1-interface
    edit "VPN-to-Spoke-Legacy"
        set interface "wan1"
        set ike-version 1
        set mode aggressive                     # 動的 IP の場合は Aggressive Mode
        set type dynamic
        set peertype one
        set peerid spoke01                      # Spoke を識別する Peer ID
        set proposal aes256-sha256
        set dhgrp 14
        set psksecret <16文字以上のランダム文字列>
    next
end

ただし、IKEv1 の Aggressive Mode は PSK 認証時に IKE ハッシュが平文で交換されるため、オフライン辞書攻撃のリスクがあります。Aggressive Mode の脆弱性の詳細は、関連記事『IPsec の仕組みと IKEv1 廃止｜ESP・SA・NAT-T の落とし穴』を参照してください。新規構築では IKEv2 を選定することが推奨されます。

応用設定: NAT 利用型 VPN（IP 重複対応）

企業合併などで「お互いの社内 LAN の IP アドレス（サブネット）が重複してしまっている」場合の対応策です。通常、IP アドレスが重複しているとルーティングが成立しませんが、FortiGate の NAT 機能を使うことで、トンネルを通る際にアドレスを変換し、相互に重複しない仮の IP で通信させる ことが可能です。

NAT 用オブジェクトの作成（VIP / IP Pool）

この構成のポイントは、送信元と宛先の両方を変換する（Double NAT） ことです。それぞれの変換ルールを定義するオブジェクトを作成します。

NAT 変換ルールの整理

通信の方向使う機能役割
相手へ送る時IP Pool（送信元 NAT）自分の実 IP（172.16.1.100）を仮 IP（10.1.1.1）に変換して送信する
相手から来る時VIP（宛先 NAT）相手が宛先として指定してきた仮 IP（10.1.1.1）を、自分の実 IP（172.16.1.100）に変換して受け取る

IP Pool（送信元 NAT 用）の作成

「自分が相手に送信する際に使用する仮の IP」を定義します。

# FG01（拠点 A 側）の設定例
config firewall ippool
    edit "NAT-Source-Pool"
        set startip 10.1.1.1                    # 相手に見せる自分の仮 IP（開始）
        set endip 10.1.1.1                      # 相手に見せる自分の仮 IP（終了）
    next
end

VIP（宛先 NAT 用）の作成

「相手から送られてきた宛先 IP を、自分の内部の実 IP に戻す」設定を定義します。

# FG01（拠点 A 側）の設定例
config firewall vip
    edit "NAT-Dest-VIP"
        set extip 10.1.1.1                      # 相手が宛先として指定してくる IP（外側）
        set extintf "any"                       # VPN インターフェイスを指定しても問題なし
        set mappedip "172.16.1.100"             # 実際にパケットを届けたい内部の実 IP
    next
end

Phase 2 とルーティングの注意点

Phase 1／Phase 2 の設定は基本構成と同じですが、Phase 2 の src-subnet / dst-subnet には NAT 後の仮 IP を指定する 必要があります。スタティックルートの宛先も同様に、相手の実 IP ではなく 相手が NAT で見せている仮 IP を指定します。

config router static
    edit 1
        set dst 10.1.2.0 255.255.255.0          # 相手の実 IP ではなく仮 IP を指定
        set device "VPN-to-Spoke"
    next
end

ファイアウォールポリシー（NAT 有効化）

ファイアウォールポリシーで NAT を有効化します。通常のインターネット行き SNAT（マスカレード）とは異なり、特定の IP Pool を指定する 点がポイントです。

config firewall policy
    edit 1
        set name "VPN-Outbound-NAT"
        set srcintf "port3"                     # LAN 側
        set dstintf "VPN-to-Spoke"              # VPN 側
        set srcaddr "all"
        set dstaddr "all"                       # 実運用では相手の VIP オブジェクトを指定する形が望ましい
        set action accept
        set schedule "always"
        set service "ALL"

        # NAT 設定
        set nat enable                          # NAT を有効化
        set ippool enable                       # デフォルトのインターフェイス IP ではなく Pool を使用
        set poolname "NAT-Source-Pool"          # 上で作成した Pool を指定
    next
end

これにより、VPN トンネルに入る際に IP Pool で指定したアドレスへ送信元が変換される 挙動となります。

接続確認とトラブルシューティング

設定完了後、VPN トンネルが正常に確立し、意図した通りに通信できているかを確認します。

IKE / Phase 1 の状態確認

# IKE Gateway（Phase 1）の状態確認
diagnose vpn ike gateway list

# 特定のトンネル名で絞り込む場合
diagnose vpn ike gateway list name <tunnel-name>

参考: FortiOS 7.6 – Phase 1 configuration
https://docs.fortinet.com/document/fortigate/7.6.4/administration-guide/790613/phase-1-configuration

status: established と表示されれば Phase 1 が確立済みです。proposal: aes256gcm-prfsha384 のように、ネゴシエーションで採用された暗号化方式も確認できます。

IPsec SA / Phase 2 の状態確認

# IPsec SA（Phase 2）の状態確認
diagnose vpn tunnel list

# 特定のトンネル名で絞り込む場合
diagnose vpn tunnel list name <tunnel-name>

bytes や packets のカウンタが増えていれば、トンネル経由の通信が成立しています。送信側のみカウンタが増えていて受信側が 0 の場合は、対向機器側のルーティングまたは Phase 2 セレクタを確認します。

IKE デバッグログの取得

トンネルが確立しない場合は、IKE のネゴシエーションをデバッグログで確認します。

# 対象トンネル名でフィルタ（FortiOS 7.4.1 以降）
diagnose vpn ike log filter name <tunnel-name>

# 7.4.0 以前は以下のコマンド
# diagnose vpn ike log-filter name <tunnel-name>

# IKE デバッグを有効化
diagnose debug app ike -1
diagnose debug console timestamp enable
diagnose debug enable

# 確認後はデバッグを停止
diagnose debug disable
diagnose vpn ike log filter clear

参考: Fortinet Community – Troubleshooting Tip: IPsec Tunnel (debugging IKE)
https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-IPsec-Tunnel-debugging-IKE/ta-p/190052

ログ出力で no proposal chosen が見られる場合は、Phase 1／Phase 2 の暗号化アルゴリズムが両端で一致していません。peer SA proposal not match local policy の場合は、暗号化方式や DH グループの差異を確認します。

トンネルの再起動

ネゴシエーションが固まった状態を解消したい場合は、トンネルをクリアして再ネゴシエーションを発生させます。

# 特定のトンネルをクリア
diagnose vpn ike gateway clear name <tunnel-name>

# IKE デーモン全体を再起動（既存トンネル全体に影響するため運用中は注意）
diagnose vpn ike restart

NAT 動作確認（Flow Trace）

「通信は通っているが NAT が正しく効いているか確認したい」という場合は、Flow Trace でパケット処理をリアルタイムに追跡します。

diagnose debug enable
diagnose debug flow filter addr <確認したい宛先IP>
diagnose debug flow trace start 20             # パケット 20 個分だけ表示

# 確認後は停止
diagnose debug flow trace stop
diagnose debug disable

ログ出力例（NAT 利用型 VPN で Ping を実行した際の例）:

id=20085 ... msg="vd-root received a packet(proto=1, 172.16.1.100:22308->10.1.2.100:8) from port3..."
（LAN 側からパケットを受信）

id=20085 ... msg="DNAT 10.1.2.100:8->10.1.1.102:22308"
（宛先 NAT: 宛先が VIP 設定に基づき 10.1.2.100 から 10.1.1.102 へ変換された）

id=20085 ... msg="SNAT 172.16.1.100->10.1.1.1:62464"
（送信元 NAT: 送信元が IP Pool 設定に基づき 172.16.1.100 から 10.1.1.1 へ変換された）

id=20085 ... msg="enter IPsec interface-VPN-to-Spoke"
（変換された状態で IPsec トンネルへ入った）

SNAT と DNAT のメッセージが両方表示されていれば、ポリシーとオブジェクト設定が正しく機能しています。

よくあるハマりポイント

FortiGate での IPsec VPN 構築・運用において、設計時に想定しづらい落とし穴を整理します。

Aggressive Mode の利用は新規構築では避ける

IKEv1 の Aggressive Mode は、動的 IP 環境で簡便に使える反面、PSK 認証時に IKE ハッシュが平文で交換されるため、キャプチャできれば PSK のオフライン辞書攻撃が可能 という構造的な弱点を持ちます。新規構築では IKEv2 + Network ID への切り替えが推奨されます。

Aggressive Mode の脆弱性についての詳細は、関連記事『IPsec の仕組みと IKEv1 廃止｜ESP・SA・NAT-T の落とし穴』も参照してください。

NAT-T と MTU の落とし穴

NAT 機器を経由する IPsec 通信では、NAT-T が必須（UDP 4500 によるカプセル化）となります。FortiOS では set nattraversal enable（デフォルト有効）で動作しますが、ファイアウォールで UDP 500／4500 が許可されていないと Phase 1 から確立できません。

また、ESP ヘッダや NAT-T の UDP ヘッダ追加により トンネル内の実効 MTU は 1400 バイト前後 に縮小します。FortiGate では config system interface 配下の VPN インターフェイスで MTU 調整と MSS clamping を指定できます。

config system interface
    edit "VPN-to-Spoke"
        set mtu-override enable
        set mtu 1400
        set tcp-mss 1360                        # MSS clamping（MTU - 40）
    next
end

NAT-T や MTU の挙動の詳細は、関連記事『IPsec の仕組みと IKEv1 廃止｜ESP・SA・NAT-T の落とし穴』のハマりポイント節も参照してください。

Phase 2 のセレクタ不一致による「片側だけ通信不可」

Phase 1 が確立済みでも、Phase 2 の src-subnet ／ dst-subnet が両端で食い違っている と、特定方向の通信だけが失敗する事象が起きます。diagnose vpn tunnel list で selectors の値を両端で突き合わせることが基本の切り分けです。

また、複数の Phase 2 セレクタを 1 つの Phase 1 配下にぶら下げる構成は FortiGate では問題なく動作しますが、対向が Cisco など他ベンダーの場合は、対向側の crypto map ACL ごとに Phase 2 を分割しないと proposal mismatch が発生する ことがあります。

IPsec ASIC オフロードと診断時の注意

FortiGate は IPsec の暗号処理を NP（Network Processor）でオフロードして高速化していますが、diagnose debug flow でパケット内容を追跡したい場合、ASIC オフロード経由のパケットは Flow Trace に現れない ことがあります。検証時のみ一時的にオフロードを無効化する方法が取られます。

# 検証時のみ ASIC オフロードを無効化（本番運用では必ず元に戻す）
config system global
    set ipsec-asic-offload disable
end

設定変更後に既存 SA が残っている場合は diagnose vpn ike gateway clear で再ネゴシエーションさせます。検証完了後は必ず enable に戻すことが推奨されます。

HA 構成（FGCP）でのトンネル引き継ぎ

FortiGate を Active-Passive HA（FGCP）で構成している場合、フェイルオーバー時の挙動を理解しておくことが重要です。

  • IKE SA／IPsec SA の状態は同期される ため、フェイルオーバー後も再ネゴシエーションなしで通信が継続できます
  • ただし、対向機器の DPD 設定が短すぎると、フェイルオーバー直後の数秒間に DPD タイムアウトと判定され、対向側からトンネルが切られる ケースがあります
  • 対向の DPD 間隔とリトライ回数を、HA フェイルオーバー時間（典型値 1〜2 秒）より長く設定することが推奨されます

FortiGate 側の DPD 設定例:

config vpn ipsec phase1-interface
    edit "VPN-to-Spoke"
        set dpd on-demand                       # トラフィック発生時のみ DPD を送出
        set dpd-retryinterval 15                # 15 秒間隔
        set dpd-retrycount 3                    # 3 回失敗で切断と判定
    next
end

参考: FortiOS 7.6 – Phase 1 configuration
https://docs.fortinet.com/document/fortigate/7.6.4/administration-guide/790613/phase-1-configuration

バージョン運用と意図しない再起動のリスク

FortiOS 7.4.8 以降では、ライセンス無効や EOES 到達を条件に 同一マイナーバージョン内の最新パッチへ強制アップグレードがスケジュールされる仕様 が追加されています。IPsec VPN を稼働させた後、運用フェーズで意図せず再起動・バージョンアップされるとトンネル断のリスクがあります。

仕様の詳細と回避手順については、関連記事『FortiGate 強制アップグレード（自動アップグレード）の仕様と回避対策』を参照してください。

まとめ

本記事では、FortiGate（FortiOS 7.6）における IPsec VPN の構築手順を、実務で頻出する 2 つのパターンを軸に解説しました。

  • 新規構築では IKEv2 + Network ID + Route-based VPN を選定することが推奨される
  • 動的 IP の Spoke は set type dynamic で待ち受け、Network ID で識別する
  • IP アドレスが重複する拠点は IP Pool（送信元 NAT）と VIP（宛先 NAT）の組み合わせ で通信を成立させる
  • 状態確認は diagnose vpn ike gateway list ／ diagnose vpn tunnel list、デバッグは diagnose debug app ike -1 を使用する
  • Aggressive Mode の脆弱性、ASIC オフロードのデバッグ挙動、HA フェイルオーバー時の DPD 設計に注意する
  • FortiOS 7.4.8 以降の強制アップグレード仕様を理解し、運用フェーズでの意図しないトンネル断を防ぐ

以上、最後までお読みいただきありがとうございました。

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

この記事を書いた人

とものアバター とも

関西を拠点に活動する、現役インフラエンジニア。経験20年超。

大手通信キャリアにて、中〜大規模インフラ（ネットワーク・サーバ・クラウド・セキュリティ）の設計・構築およびプロジェクトマネジメントに従事。現場で直面した技術課題への対処や、最新の脆弱性情報への実務対応を、一次情報として発信しています。

保有資格
CCIE Lifetime Emeritus（取得から20年以上）／ VCAP-DCA ／ Azure Solutions Architect Expert

▶ 運営者プロフィール（詳細）

目次