FortiGateとRTXをまたぐLAN-to-LAN VPNでは、IKE SAが確立してもLAN間通信まで通るとは限りません。FortiGate 60FとRTX830を閉域で物理直結し、FortiGate側をGUIで設定して、Windows端末からRTX830のLAN1へPINGするところまでを実機で確認しました。
結論: FortiGate側のLocal IDを手入力せず空欄にした構成で、IKEv2/IPsecのESP SAが送受各1本確立しました。WindowsからRTX830 LAN1（192.168.100.254）への初回PINGは10回中8回応答し、接続を維持した後の再試験は全成功と実施者から報告を受けました。SA、経路・許可、宛先へのPINGを分けて確認したことが切り分けに役立ちました。
FortiGate internal側のWindows 11（192.168.1.110/24）から、RTX830 LAN1（192.168.100.254/24）を疎通先にしました。RTX830 LAN2（172.16.255.1/30）とFortiGate wan1（172.16.255.2/30）は物理直結です。今回確認した範囲は、この閉域直結でのIPsec確立とPING応答です。
機器ごとの設定対応
| 項目 | RTX830（Rev.15.02.31） | FortiGate 60F（FortiOS 7.4.9） |
|---|---|---|
| IKE | IKEv2、PSK | IKEv2、PSK |
| IKE提案 | AES256-CBC / SHA-256 / DH14 | AES256 / SHA-256 / DH14 |
| ESP提案 | AES256-CBC / SHA-256 | AES256 / SHA-256 |
| PFS | 有効、DH14 | 有効、DH14 |
| IKE ID | 172.16.255.1 と 172.16.255.2 をIPv4アドレス型で指定 | Phase1のLocal IDは空欄 |
| TS | Phase2提案を受理 | local 192.168.1.0/24、remote 192.168.100.0/24 |
| 経路 | 192.168.1.0/24をtunnel 1へ | 192.168.100.0/24をVPNインターフェースへ |
FortiGate側はVPN、192.168.100.0/24への静的経路、internalからVPNへ向けるPINGのみの許可ポリシー（source 192.168.1.0/24、destination 192.168.100.0/24、NAT無効）をGUIで一時設定しました。応答通信はセッションに従って通すため、逆向きの新規通信を開始するポリシーは追加していません。RTX830側の一時設定はCLIで行ったため、両機器をGUIだけで設定した検証ではありません。
# RTX830: 接続時に追加した要点（共有鍵の値は掲載しない）
ip lan2 address 172.16.255.1/30
ip route 192.168.1.0/24 gateway tunnel 1
tunnel select 1
ipsec tunnel 1
ipsec sa policy 1 1 esp aes256-cbc sha256-hmac
ipsec ike version 1 2
ipsec ike auth method 1 pre-shared-key
ipsec ike group 1 modp2048
ipsec ike pfs 1 on
ipsec ike encryption 1 aes256-cbc
ipsec ike hash 1 sha256
ipsec ike proposal-limitation 1 on
ipsec ike local address 1 172.16.255.1
ipsec ike remote address 1 172.16.255.2
ipsec ike local name 1 172.16.255.1 ipv4-addr
ipsec ike remote name 1 172.16.255.2 ipv4-addr
tunnel enable 1
tunnel select none両機器には別途同じ事前共有鍵を設定しましたが、値は掲載しません。最初はFortiGateのLocal IDに172.16.255.2を入力していましたが、ESP SAは確立しませんでした。Local IDだけを空欄にしてGUI保存した後、ESPの送受が各1本になりました。ID型そのものをパケットで確認したわけではなく、この観測は今回の組み合わせの結果です。FortinetのLocal ID解説も確認し、自環境でのID型の照合を推奨します。
接続確認の記録
# WindowsからRTX830 LAN1へ
ping -n 10 192.168.100.254
# RTX830で確認
show ipsec sa
show status tunnel 1
show ip route# RTX830 statusの確認結果（接続中に取得した抜粋）
Total: isakmp:1 send:1 recv:1
TUNNEL[1]:
トンネルインタフェースは接続されています
| 確認項目 | 結果 | 判断 |
|---|---|---|
| ESP SA | RTX830で送受各1本 | IPsecの保護SA確立を確認 |
| FortiGateイベント | Phase2成功、SA作成、phase2-up、tunnel-upを記録 | ログ時刻は17:15:42 JST。17:35:35 JSTのdownイベントも記録 |
| Windows → RTX830 LAN1 | 初回PINGは10回中8回応答 | RTX830側のトンネル送受カウンター8/8と一致 |
| 接続維持後の再試験 | 全成功と実施者から報告 | 後続カウンター23/23は累計であり、再試験の回数には換算しない |
FortiGateのイベントは、IKEの成功表示だけでなくPhase2とSA作成、tunnel-upまで確認しました。初回PINGの2回の損失原因は未特定です。トンネル統計のbyte数と送受カウンターは累計値なので、PINGの成功回数を推定する用途には使いません。
確認を進める順序
- IKE ID、IKE/ESP提案、DH/PFSを照合してESP SAまで確認する。
- Phase2 selector、両LANへの経路、開始方向の許可ポリシーを確認する。
- LAN側の実際の宛先へPINGし、SAの確立と宛先応答を別の結果として記録する。
検証後、RTX830は設定を保存せず変更前後のCONFIG hash一致とSA・VPN経路の消去を確認しました。FortiGateも検証用VPN、経路、許可ポリシー、address objectを削除し、wan1を元の値へ復元しました。検証用のMac経路も削除済みです。
まとめ
FortiGate 60FとRTX830の閉域IKEv2/IPsecでは、まずESP SA、次にselector・経路・開始方向の許可、最後に実際の宛先PINGを順に確認すると、どの段階で止まっているかを分けられます。今回のFortiGate GUI設定では、Local IDを空欄にした後にSAが成立しました。環境固有の検証結果として扱い、設定を本番へ適用する前には自環境のID、経路、ポリシーを確認してください。
関連: FortiGateのスタティックルート設定、FortiGateのファイアウォールポリシー設定。仕様確認はYamaha IKEv2資料、Yamaha IKE local name資料、FortiGate 7.4.9 Phase2 referenceを参照してください。
コメント