FortiGate SSL-VPN廃止に伴うIPsec VPN移行手順|設定例・脆弱性の背景・FortiClient対応【実務ガイド】

FortiGate SSL-VPNからIPsec VPNへの移行手順

あわせて読みたい関連記事

FortiGateのVPN設定や関連するトラブルシューティング記事もご覧ください。

FortiGate SSL-VPN廃止とIPsec移行が必要な理由

style=”color:#334155;margin:0 0 1.5rem;font-size:18px;line-height:1.8;”>FortiGateでリモートアクセスVPNを運用していると、避けて通れなくなってきたのがSSL-VPNからIPsec VPNへの移行です。これまでSSL-VPNで安定運用していた環境でも、FortiOSのアップグレード計画にあわせて「このまま上げて大丈夫か」「FortiClient側は何を直せばいいのか」「利用者影響を最小化するにはどう進めるべきか」と悩むケースは多いはずです。

現場では、VPNの方式そのものを変える話になると単純な設定変更では終わりません。認証方式・アドレス払い出し・ポリシー・DNS・分割トンネル・ユーザーへの案内・切り戻しまで含めて考えないと、移行当日に「接続はできるのに社内へ行けない」「一部ユーザーだけ名前解決できない」「認証情報は通るのにトンネルが上がらない」といった事故が起きやすくなります。

この記事では、移行の理由・事前確認・実際の手順・CLI設定例・よくある失敗・切り戻しの考え方まで、実務目線でまとめます。

🚨 最重要:「とりあえずOSを上げてから考える」は厳禁 FortiOSのアップグレード後にSSL-VPNが動作しなくなった状態では、在宅ワーク中のユーザー全員が社内にアクセスできなくなります。移行計画はアップグレード前に完成させてから上げるのが鉄則です。
👷 現場での体験談

以前担当した移行案件で、社内検証では完璧に動いたのに本番切り替え後に特定ユーザーだけ名前解決できないという問題が発生しました。調べると、SSL-VPN時代はDHCPでDNSが払い出されていたのに対して、IPsec VPN側にDNS設定を移し忘れていたことが原因でした。

別の案件では、自宅回線では安定するのにテザリング環境だけ接続が不安定になりました。途中経路でUDPが制限されていたことが原因で、最終的にTCP 443利用に設計変更しました。社内からの検証だけでは見えない落とし穴があることを痛感した経験です。

SSL-VPN→IPsec VPN移行の構成と手順
SSL-VPN → IPsec VPN 移行構成図

なぜSSL-VPNからIPsec VPNへの移行が必要なのか

FortiOS SSL-VPN廃止の背景と脆弱性問題 style=”color:#334155;margin:0 0 1.5rem;font-size:18px;line-height:1.8;”>今回の話は「新しい方式もありますよ」という任意の検討ではなく、FortiOSのバージョンによっては事実上の必須対応になるという点を最初に押さえてください。

これまでFortiGateではSSL-VPNが広く使われてきました。TCP 443を使えるため社外ネットワークでも通しやすく、設定もしやすいという理由から選ばれ続けてきた方式です。しかし今後はSSL-VPNトンネルモードを前提に運用を続ける設計が難しくなります。

SSL-VPNからIPsec VPNへの移行手順 style=”color:#334155;margin:0 0 1.5rem;font-size:18px;line-height:1.8;”>実務で重要なのは、単に「名称が変わる」わけではないことです。VPN方式が変わるため、認証・暗号化・クライアント定義・ポリシー確認のやり直しが必要になります。アップグレード計画だけ先に進んでVPN移行を後回しにした結果、夜間メンテナンス後に在宅ユーザーが翌朝つながらない、という形で発覚するケースが現場では最も多いパターンです。

図1:SSL-VPN→IPsec移行の主な変更点と影響範囲

SSL-VPNとIPsec VPNの違い

移行時に必要な観点を中心に整理します。

項目SSL-VPNIPsec VPN
使用プロトコルTLS(TCP 443)IKE(UDP 500/4500)またはTCP 443
動作レイヤーアプリケーション層ネットワーク層
設定の複雑さ比較的シンプルPhase1/Phase2・経路設計が必要
トラブル時の確認SSL/TLS・Webポータル系のログIKEネゴシエーションログで追いやすい
NAT越えTCP 443で通りやすいNAT-T(UDP 4500)またはTCPカプセル化で対応
今後の方向性廃止予定今後の標準

感覚的には、SSL-VPNは「クライアントアクセスの仕組み」として見ていたものを、IPsec VPNでは「トンネルと経路設計を伴う仕組み」として捉えると理解しやすいです。その分、どこで失敗しているかをIKEネゴシエーションのログで追いやすい面もあります。

移行前に確認しておくべきポイント

SSL-VPNからIPsec VPNへの移行で失敗しやすいのは、機器設定よりも設計情報の棚卸し不足です。先に設定画面を触り始めるより、現在のSSL-VPN環境で何を実現しているかを先に洗い出したほうが結果的に早く終わります。

① 現在のSSL-VPNで使っている要素を整理する

最低限、次の情報は整理しておいてください。この整理が甘いと、移行後に「VPN自体は張れたのに社内の名前解決だけできない」「特定部署のユーザーだけ入れない」という切り分けしづらいトラブルになります。

👥
認証まわり
ユーザーグループ・認証方式(LDAP/RADIUS/ローカル)・二要素認証の有無
🌐
接続先・アドレス
接続先FQDN・割り当てIPレンジ・許可する社内セグメント
🔍
DNSと名前解決
配布しているDNSサーバー・社内ドメイン・split tunnelの有無
💻
クライアント環境
利用端末のOS・FortiClientのバージョン・配布方法(EMS有無)

② FortiClientバージョンを確認する

サーバー側だけ整えても、クライアント側が要件を満たしていなければ移行は成功しません。社内PCは配布ポリシーでそろえられていても、持ち出し端末や例外PCだけ古いバージョンが残っているケースは珍しくありません。これまでSSL-VPNで問題なく使えていた利用者ほど「昨日まで使えたのに今日はつながらない」と感じやすいため、事前にバージョンを確認し配布手順を先に案内しておくことが重要です。

③ TCP 443を使い続ける必要があるか判断する

SSL-VPNを使っていた環境では、TCP 443で通せることをメリットとしていたケースが多いはずです。IPsec VPNへ移行する際も、同じように通過性を重視するのか、標準的なUDPベースで問題ないのかを先に決めておきましょう。

この判断を曖昧にしたまま移行すると、テスト環境では成功したのに出張先ホテルやテザリング経由では接続できないという事態が起きます。リモートアクセスVPNは「本社回線から見て正しい」だけでは足りず、利用者が実際に使う回線条件で考える必要があります。

④ 切り戻し条件を先に定義する

移行作業の前に、どの状態なら成功とみなすか、どの状態なら切り戻すかを定義しておくと当日の判断がぶれません。「接続成功」だけでなく、「社内DNS名前解決」「主要3セグメント疎通」「RDPやWeb業務システム利用」のように、利用者目線の確認項目で判定基準を作ることをおすすめします。

おすすめの移行手順(8ステップ)

実務では、SSL-VPNを残したままIPsec VPNを先に並行検証し、少人数で試してから全体展開する流れが安全です。

1
現在のSSL-VPN設定をバックアップする

最初に必ず設定バックアップを取得します。GUIからのバックアップだけでなく、対象設定のCLI出力も別途保管しておくと差分確認や切り戻しが楽になります。

show vpn ssl settings
show user group
show firewall policy
show firewall address
show firewall addrgrp
show system interface
2
移行対象ユーザーと接続要件を整理する

全ユーザーを同一設定にするのか、部署ごとにアクセス先を分けるのかを決めます。たとえば、一般利用者は社内ポータルと業務システムのみ、運用担当は管理セグメントも許可、開発担当は検証環境のみ、というように整理するとIPsec用ポリシーの見通しがよくなります。VPN移行のタイミングは権限見直しの好機でもあります。

3
FortiGate側にIPsecリモートアクセスVPNを作成する

既存オブジェクト名を流用しすぎると切り戻し時に混乱しやすいため、最初は別名(例:ipsec_ra_01)で作るほうが安全です。以下はCLIサンプルです。実際の環境に応じて読み替えてください。

config vpn ipsec phase1-interface
    edit "ipsec_ra_01"
        set type dynamic
        set interface "wan1"
        set ike-version 2
        set peertype any
        set net-device disable
        set mode-cfg enable
        set proposal aes256-sha256
        set dpd on-idle
        set nattraversal enable
        set ipv4-start-ip 10.255.10.10
        set ipv4-end-ip 10.255.10.200
        set ipv4-dns-server1 192.0.2.10
        set ipv4-dns-server2 192.0.2.11
        set psksecret ENC SAMPLE-KEY
        set authusrgrp "vpn_users"
    next
end
注意: IKEv2(set ike-version 2)ではXAUTHは使用しません。ユーザー認証はauthusrgrpで指定したグループに対してFortiGate独自の認証フロー(EAP等)で行われます。IKEv1でXAUTHを使う場合は別途set xauthtype autoが必要です。

SSL-VPN時代のアドレス帯と重複しないVPNクライアント用IPレンジを選ぶことが重要です。社内LAN・拠点VPN・クラウドVPCのアドレスと重なると、接続自体は成功しても戻りルートやポリシー判定で不可解な動きになります。

4
Phase2と許可対象セグメントを定義する

ユーザーが到達すべき社内ネットワークを明確にします。何でも通すより必要な宛先セグメントを定義したほうが事故を防ぎやすく、トラブル時の確認も簡単です。

config vpn ipsec phase2-interface
    edit "ipsec_ra_01_p2"
        set phase1name "ipsec_ra_01"
        set proposal aes256-sha256
        set src-subnet 0.0.0.0 0.0.0.0
        set dst-subnet 192.0.2.0 255.255.255.0
    next
end
5
IPsec VPN用ファイアウォールポリシーを作成する

VPN方式が変わると、ポリシーの参照元インターフェースも変わります。 SSL-VPNのポリシーを見て「似たようなものを作ったつもり」でも、送信元インターフェースやアドレスオブジェクトが違っていて通らないことはよくあります。

config firewall policy
    edit 0
        set name "IPSEC_RA_to_LAN"
        set srcintf "ipsec_ra_01"
        set dstintf "lan"
        set srcaddr "all"
        set dstaddr "srv_app01" "srv_dns01" "lan_users"
        set action accept
        set schedule "always"
        set service "ALL"
        set groups "vpn_users"
        set nat disable
    next
end

本番では必要なサービスに絞ったほうが安全です。管理用ポートまで不用意に許可すると、移行後に別のリスクを増やしてしまいます。

6
FortiClient側にIPsec VPN接続を配布する

接続名・接続先FQDN・認証方式・TCP利用の有無などを整えます。EMSを使っている環境ならプロファイル配布で段階移行しやすくなります。利用者向け案内は「旧接続を消すタイミング」「新接続を追加する前に何を確認するか」「接続後にどの画面が出れば成功か」まで書いておくと問い合わせをかなり減らせます。

7
テストユーザーで事前検証する

本番切り替え前に、情報システム部門や運用担当など少人数で検証します。確認項目は接続成功・社内DNS参照・主要サーバー疎通・ファイル共有やRDP・業務Webアクセスが基本です。

⚠ 社内Wi-Fiだけでの検証で終わらせないこと! 自宅回線・モバイル回線・ホテル回線のように実際の利用条件に近い経路で試しておくと、当日の事故を大幅に減らせます。
8
全体展開と切り替えを行う

検証が完了したら、対象ユーザーへ案内を出し旧SSL-VPNから新IPsec VPNへ切り替えます。一定期間だけ並行稼働を設けて、早めに接続確認をしてもらうことが理想です。切替当日に全員一斉変更だと問い合わせ窓口が詰まりやすくなります。

よくあるトラブルと確認コマンド

接続は成功するのに社内へ通信できない

このパターンは非常に多いです。原因としては、ポリシー不足・到達先アドレス設定漏れ・split tunnelの経路不足・戻りルート不足・DNS配布漏れが代表的です。疎通確認はpingだけでなく、名前解決と業務アプリの接続まで確認することが重要です。

! トンネル状態確認
get vpn ipsec tunnel summary

! IKEゲートウェイ確認
diagnose vpn ike gateway list

! IKEデバッグ(対象時間帯を区切って実施すること)
diagnose vpn ike log-filter clear
diagnose debug reset
diagnose debug application ike -1
diagnose debug enable
ℹ IKEデバッグの注意点 IKEデバッグは業務時間帯に漫然と流すとログ量が増えて必要な情報が埋もれます。対象時間帯を区切り、対象ユーザーを絞って実施してください。終了後は必ずdiagnose debug disableで無効化してください。
症状よくある原因確認先
接続できるのに社内に到達できないポリシー不足・経路不足・DNS配布漏れFW ポリシー・Phase2・ipv4-dns設定
認証は通るがトンネルが安定しない暗号スイート不一致・NAT越えの問題・回線品質Phase1提案・nattraversal設定・TCP利用検討
一部ユーザーだけ接続できないグループ紐付け漏れ・FortiClientバージョン差・旧VPN競合authusrgrp設定・クライアントバージョン確認
モバイル回線だけ不安定途中経路でUDPがブロックされているTCP 443カプセル化に変更
図2:SSL-VPN→IPsec移行時のトラブル原因内訳(現場経験ベースのイメージ)

移行時の注意点

⚠️
SSL-VPNの設定名をそのまま流用しない
移行完了までは旧SSL-VPNと新IPsec VPNが一目で区別できる命名にする。障害対応中に名前が似ているだけで確認漏れが起きる
⚠️
VPNクライアント用IPレンジの重複に注意
社内LAN・クラウドVPC・拠点間VPN・検証環境とアドレスが増えている組織ほど重複の罠にはまりやすい。不達が起きると認証や暗号設定ばかり疑いがちだが単なるアドレス設計ミスのことも多い
⚠️
DNS設計を軽く見ない
利用者はIPアドレスで業務しない。VPN疎通確認は必ずDNSとアプリ接続もセットで確認する
⚠️
案内文の質が問い合わせ件数を左右する
設定値の羅列ではなく、画面遷移と成功判定まで含めた手順書にする。管理者には簡単に見える変更でも利用者にはハードルになる

切り戻しの考え方

移行計画には、成功手順と同じくらい切り戻し条件が重要です。移行後30〜60分程度で確認すべき項目を事前に決めておき、未達なら戻す判断をする運用をおすすめします。

切り戻しに必要なもの注意点
旧設定のバックアップ手順1で取得したCLI出力とGUIバックアップの両方を用意しておく
旧クライアント配布手順FortiClientをEMSで管理している場合は新旧プロファイルの適用順序まで確認しておく
利用者への周知テンプレート「旧接続先に戻してください」という案内文を事前に準備しておく
旧設定の有効期間の確保完全撤去を急ぎすぎると戻す選択肢が事実上なくなる。本番切り替え後しばらくは旧設定を残しておく

まとめ

FortiGateのSSL-VPNからIPsec VPNへの移行は、単なる機能変更ではなく、今後のFortiOS運用を見据えた実務対応です。移行で失敗しやすいポイントは「ポリシー不足・経路不足・DNS配布漏れ・利用者案内不足」の4つです。逆に言えば、この4つを丁寧に潰していけば、移行はそこまで怖い作業ではありません。

  • アップグレード前に移行計画を立てること。「上げてから考える」は厳禁
  • SSL-VPNの現行要件(認証・アドレス・DNS・split tunnel)を棚卸しすること
  • FortiClient側まで含めて準備し、EMS有無に応じた配布手順を整備すること
  • 社内検証だけでなく自宅・モバイル回線でも事前検証すること
  • 少人数検証を挟んでから段階的に本番展開すること
  • 切り戻し条件と手順を事前に準備しておくこと

移行案件では「認証・経路・名前解決・利用者運用」の4点セットで考えたほうがうまくいきます。この視点があると、トラブル時の切り分けもかなり楽になります。

よくある質問(FAQ)

Q. FortiGate SSL-VPNはいつ廃止される?

FortiOS 7.6系以降でSSL-VPN機能が段階的に廃止されています。具体的なバージョンや時期はFortinet公式のリリースノートで確認してください。既存環境でもセキュリティ上の脆弱性が繰り返し報告されているため、早めのIPsec VPN移行が推奨されます。

Q. SSL-VPN廃止後の代替手段は?

主な代替手段はIPsec VPN(FortiClient利用)です。FortiClientのIPsecモードでリモートアクセスを提供します。また、ZTNA(ゼロトラストネットワークアクセス)への移行も選択肢の一つです。環境に応じてIPsec VPNとZTNAを併用する構成も検討できます。

Q. IPsec VPNはUDPブロック環境で使える?

IPsec VPNはUDP 500/4500を使用するため、公衆Wi-Fiや企業ゲストネットワークなどUDPが制限される環境では接続できない場合があります。この問題への対策として、FortiClientのIPsec over TCP機能や、スプリットトンネル設計による代替経路の確保が有効です。事前にテザリング環境等でのテストを推奨します。