FortiGateの「SSL-VPN廃止」という情報を見て、何が本当に使えなくなるのか、いま動いているリモートアクセスはどうなるのか、不安に感じている方は多いはずです。特に、これまでFortiClientでSSL-VPN接続を提供していた環境では、FortiOSのアップグレードをきっかけにリモートアクセス基盤そのものを見直す必要が出てきます。
現場でよくあるのは、「FortiOSを上げれば設定もそのまま引き継がれるだろう」と考えてしまうケースです。しかし今回の変更は、単なる画面名称の変更ではありません。SSL-VPNのトンネル接続をそのまま使い続ける前提でアップグレードすると、在宅勤務者や出張者が翌日つながらない、といった大きな影響が出る可能性があります。
この記事では、FortiGateのSSL-VPN廃止とは何を指すのか、なぜ影響が大きいのか、IPsec VPNへ移行するときに何を確認すべきか、どこでハマりやすいのかを、実務目線でまとめて解説します。単に「SSL-VPNがなくなります」で終わらせず、結局どう対応すればよいかが分かるように整理しています。
FortiGateのSSL-VPN廃止とは何を意味するのか
まず整理しておきたいのは、「SSL-VPNが全部まとめて消える」という理解は少し正確ではない、という点です。今回大きく影響を受けるのは、FortiClientなどで利用してきたSSL-VPNのトンネルモードです。これまでリモートPCが仮想的に社内ネットワークへ接続し、RDPやファイル共有、業務システムへアクセスするために広く使われてきた接続方式です。
FortiOS 7.6.3以降では、このSSL-VPNトンネルモードがIPsec VPNへ置き換えられる前提になっています。つまり、従来のSSL-VPNトンネルを使い続けるのではなく、FortiGate側もFortiClient側も、IPsecベースのリモートアクセス設計へ寄せていく必要があります。
一方で、これまでのSSL-VPN web modeに相当する機能は、Agentless VPNという扱いに整理されています。ただし、こちらは一部の機種で非対応です。そのため、「うちはWebモードで逃げればよい」と単純には言えません。機種と用途を分けて考える必要があります。
| 項目 | 従来 | 7.6.3以降の考え方 | 実務影響 |
|---|---|---|---|
| SSL-VPN Tunnel Mode | FortiClientでの一般的なリモートアクセス | IPsec VPNへ移行 | 既存構成の見直しが必要 |
| SSL-VPN Web Mode | ブラウザ経由の社内リソースアクセス | Agentless VPNとして整理 | 一部機種では使えない |
| アップグレード時の挙動 | 設定継承を期待しがち | 関連設定は自動移行されない | 事前移行なしは危険 |
なぜ今回の変更がこんなに重いのか
今回の変更が重い理由は、単にプロトコル名が変わるからではありません。リモートアクセスは、いまや一部社員だけの特別な仕組みではなく、在宅勤務、障害時対応、夜間メンテナンス、ベンダー保守、拠点の臨時作業など、日常運用の中核になっていることが多いからです。
そのため、SSL-VPNを使っていた環境では、装置設定だけでなく、クライアント設定、認証方式、接続案内、運用手順、問い合わせ対応フローまで含めて見直す必要があります。ネットワーク担当者としてはFortiGateの設定変更が主作業に見えますが、実際には「利用者にどう切り替えてもらうか」のほうが時間を使うことも珍しくありません。
現場では、技術面よりも運用面で事故になることが多いです。たとえば装置側は移行済みでも、利用者端末に古い接続プロファイルが残っていてつながらない、接続先名が変わってヘルプデスクに問い合わせが集中する、多要素認証の組み合わせで想定外の失敗が起きる、といった流れです。装置設定だけを見ていると、このあたりを見落とします。
いちばん危ないのは「アップグレード後に考える」こと
今回もっとも避けたいのは、SSL-VPNを本番利用しているにもかかわらず、先にFortiOSを上げてしまうことです。これまでの感覚であれば、機能に多少の差分があっても、既存設定は大筋で残るだろうと考えがちです。しかしSSL-VPNトンネルモードについては、その考え方が通用しません。
もし事前検証なしで上げてしまうと、アップグレード後に「設定が見当たらない」「想定していたポリシーが当たらない」「利用者が接続できない」という状況になります。特に、夜間メンテでOSだけ先に更新し、翌営業日に在宅勤務者が一斉に接続失敗するパターンは避けたいところです。
以前、リモート接続系の変更で大きく荒れた現場では、装置そのものよりも「接続手順書の更新漏れ」で問い合わせが増えました。今回も同じで、設定変更だけ終えて安心するのが一番危険です。切り替えは、ネットワーク機器とユーザー運用の両方で完了して初めて成功です。
移行前に必ず確認したいこと
いま使っているのが本当にSSL-VPNトンネルなのか
まず確認したいのは、現在の利用方式です。FortiClientでVPN接続し、社内LANへルーティングしているなら、ほぼ今回の中心テーマであるSSL-VPNトンネルモードです。この場合はIPsec VPNへの移行が必要になります。
一方で、利用者がブラウザから特定の社内Webシステムだけを開いている場合は、旧Webモードに近い使い方かもしれません。ただし、その場合でも新しい整理ではAgentless VPNで扱われますし、機種によっては使えない可能性があります。用途だけでなく、装置型番まで含めて確認してください。
FortiGateの機種を確認する
小型モデルや一部シリーズでは、Agentless VPNが使えない条件があります。とくに拠点用の小型機は、「本社の大型機では使えたから、同じようにいけるだろう」と思い込みやすいです。実際には機種依存の差があるので、拠点単位で確認したほうが安全です。
本社だけでなく、拠点FortiGateをVPN終端にしている環境では、同じ移行方針を全拠点へ一括適用できるとは限りません。結果として、本社はIPsec、拠点は構成変更、あるいはそもそも接続方式を再設計する必要が出る場合もあります。
認証まわりを洗い出す
VPN移行では、トンネルそのものより認証方式の確認が重要です。ローカルユーザーなのか、RADIUSなのか、LDAPなのか、SAMLや多要素認証と組み合わせているのかで、切り替え時の影響点が変わります。普段は問題なく使えている認証でも、接続方式が変わるとクライアント側の挙動が変わることがあります。
とくに、既存の利用者案内が「SSL-VPNの画面を開いてこの接続名を選ぶ」という説明になっている場合、接続名や選択画面が変わるだけでも問い合わせが増えます。技術的には小さな変更でも、運用では大きな差になります。
ポリシーとアドレスオブジェクトを整理する
SSL-VPNでは、専用のインターフェースやアドレスグループを前提にポリシーが組まれていることが多いです。IPsecへ移行すると、参照インターフェースやポリシーの考え方を見直す必要が出ます。その際、古いオブジェクト名が大量に残っている環境では、どのポリシーが現行利用なのか分かりづらくなりがちです。
このタイミングで、不要なアドレスグループや長年使われていないポリシーも棚卸ししておくと、移行後のトラブルを減らせます。名前だけ残っていて実際には使っていない設定が、切り替え時の判断を邪魔することは珍しくありません。
移行の基本方針は「置き換え」ではなく「再設計」に近い
SSL-VPNからIPsec VPNへの移行を、単純な置き換え作業として見ると失敗しやすいです。もちろん、利用者から見れば「社外から社内へ接続する」という目的は同じです。しかし、実際の設計では、トンネルの張り方、クライアント配布、認証手順、分割トンネルの考え方、ポリシー適用の見え方など、細かい部分で差が出ます。
たとえば、これまでSSL-VPNで広めのアクセス権を与えていた環境では、IPsec移行を機に業務システムごとに通信先を整理し、必要最小限のアクセスに寄せるほうが安全です。逆に、何も整理せずに既存を丸ごと再現しようとすると、余計なポリシーが増え、トラブル時の切り分けが難しくなります。
移行作業は、いまの使い方を見直すチャンスでもあります。長年運用されてきたVPN環境ほど、「本当は不要になっている接続先」が混ざっています。全員がフルトンネルである必要があるのか、特定システムだけのスプリットトンネルに分けたほうがよいのか、このタイミングで整理すると後が楽です。
実務でおすすめの移行手順
1. まず現行SSL-VPN利用者を棚卸しする
誰が、どの端末から、どの業務のために、どの時間帯に接続しているかを整理します。ここが曖昧なままだと、移行後の検証ができません。VPNの利用実態が見えないまま切り替えると、「つながるかどうか」だけは確認できても、「業務が成立するか」が確認できないまま本番投入してしまいます。
2. 接続要件を分ける
フルリモートで社内資源へ広く入るユーザー、RDPだけ使うユーザー、特定Webシステムだけ必要なユーザー、保守ベンダーなど、利用者を分けて考えます。全員を同じプロファイルにすると楽そうに見えますが、運用が長くなるほど無理が出ます。
3. IPsec VPNの新構成を先に作る
既存SSL-VPNをすぐ消すのではなく、先にIPsec側の接続先、認証、アドレス割り当て、ポリシー、DNS、ルーティングを作り込みます。そのうえで、一部利用者から先行移行し、問題が出ないかを確認する流れが安全です。
4. FortiClient配布と接続手順を整える
利用者向けの案内を後回しにしないことが重要です。VPN切り替えは、ヘルプデスク対応件数に直結します。接続名、画面遷移、認証手順、初回接続時の注意点、切り替え日を明確にした簡潔な手順書を準備したほうが、結果的に障害対応より楽です。
5. 並行稼働期間を設けて切り替える
可能であれば、短期間でも並行稼働を設けるほうが安全です。先行ユーザーで切り分けた内容を反映し、問題が潰れてから全体移行したほうが、本番影響を小さくできます。いきなり全員切り替えは、よほど単純な環境でない限りおすすめしません。
確認で使いやすいコマンド例
以下は、移行前後の確認で使いやすいコマンド例です。実際の環境に合わせて読み替えてください。IPアドレスや名称はサンプルです。
現在のVPN関連設定やインターフェースを確認する例
show vpn ssl settings
show user local
show user group
show firewall policy
show system interface
get system statusまずは現行のSSL-VPN設定、認証に使っているユーザーやグループ、関連ポリシー、インターフェース構成を洗い出します。設定量が多い環境では、どのポリシーが本当にVPN利用者向けなのかをコメントやオブジェクト名から整理しておくと後で楽です。
機種やシステム情報を確認する例
get hardware status
diagnose hardware sysinfo conserve
get system performance status機種確認やリソース確認は早めに実施しておくと安心です。小型機では機能差や制約を見落としやすいため、本社機と同じ感覚で判断しないほうが安全です。
IPsec VPNの状態確認でよく使う例
get vpn ipsec tunnel summary
diagnose vpn tunnel list
diagnose debug application ike -1
diagnose debug enable移行後につながらない場合は、まずトンネルが上がっているか、IKEネゴシエーションがどこで失敗しているかを確認します。認証失敗、提案不一致、証明書やポートの問題など、見えるポイントがSSL-VPN時代と少し変わるため、担当者側も確認観点を切り替える必要があります。
デバッグを使うときは、ログが多く出るので、実施時間帯と対象ユーザーを絞って行ったほうが混乱しません。運用中の本番機で広くデバッグをかけると、必要なログが埋もれてしまいます。
現場でハマりやすいポイント
ポリシーはあるのに通信できない
これは非常によくあります。IPsecへ移行したあと、見た目上はトンネルが確立しているのに、業務通信だけ通らないパターンです。原因として多いのは、送信元・宛先アドレスオブジェクトの見直し漏れ、想定していたDNSが配布されていない、あるいは分割トンネルの対象に必要な宛先が入っていないケースです。
「VPNはつながる」と「業務が使える」は別物です。疎通確認では、pingだけで終わらせず、名前解決、RDP、ファイル共有、社内Web、業務アプリなど、実際に使うものを一通り触ることが重要です。
利用者によって成功したり失敗したりする
これは認証やクライアント配布で起きやすいです。同じように見えて、端末ごとにFortiClientの設定が微妙に違う、古い接続プロファイルが残っている、MFAの登録状態が異なる、といった差が出ます。ネットワーク側だけ見ていると、再現性の低い障害に見えて苦労します。
こういうときは、成功している端末と失敗している端末で、クライアントバージョン、接続先名、認証手順、OS差分を並べて比較したほうが早いです。ログだけ追い続けるより、現場ではこのほうが近道なことが多いです。
443を使っていたからそのまま考えてしまう
SSL-VPN時代は「443で通るから大丈夫」と考えやすかったですが、IPsecへ移行すると、通信方式や経路上の扱いをあらためて確認する必要があります。FWやプロキシ、回線事業者側の制約、出先ネットワークのポリシーなど、利用環境によって差が出ることがあります。
利用者が自宅だけでなく、ホテル、客先、モバイル回線、テザリングなどを使う場合は、複数パターンで接続検証しておいたほうが安全です。本社LANでつながったから本番も大丈夫、という考え方は避けたいところです。
切り替え後の問い合わせが想像以上に多い
技術的には成功していても、「画面が変わった」「接続方法が分からない」「前と違う」という理由で問い合わせは増えます。これは障害ではなく、運用設計の問題です。事前通知、切り替え日、旧手順の無効化、新手順の図解、この4つが揃うだけでかなり減らせます。
実際、ネットワーク変更そのものよりも、利用者案内の質で成否が分かれることはよくあります。とくに役員や営業部門など、接続失敗のインパクトが大きい利用者から先に混乱すると、技術的には軽微でも大きな問題に見えてしまいます。
移行時に見直しておきたい設計ポイント
フルトンネルかスプリットトンネルか
この機会に、VPN利用者を全員フルトンネルにする必要があるのかを見直す価値があります。セキュリティ要件や監査要件によってはフルトンネルが必要な場合もありますが、業務アプリが限られているならスプリットトンネルのほうが帯域と体感速度に有利なことがあります。
ただし、スプリットトンネルは設計が雑だと「一部だけ通らない」問題を起こしやすいです。社内アドレス帯、DNS、SaaS接続要件、名前解決方式まで含めて整理しないと、中途半端な作りになります。
アクセス権の最小化
旧SSL-VPN環境では、長年の運用の中で権限が広がりがちです。今回の移行は、グループ単位でアクセス先を整理し、最小限へ寄せるよい機会です。全員が全サーバへ入れる設計は、運用が楽に見えてもトラブル時の影響範囲が大きくなります。
ログと監視の整備
切り替え直後は、利用者の接続失敗や通信不可を早く拾えるようにしておくことが重要です。接続数、失敗率、認証エラー、問い合わせ件数などを最低限でも見える化しておくと、障害か単なる操作ミスかの判断が早くなります。
やってはいけない進め方
まず避けたいのは、現行設定をよく理解しないまま、似たような名前の設定をIPsec側へ並べるだけの移行です。見た目は移せても、実際の運用や認証フローが再現できず、切り戻しも難しくなります。
次に危ないのは、利用者テストを1人だけで終わらせることです。IT部門の端末だけ成功しても、本番利用者全体を代表しているとは限りません。営業用ノートPC、社外回線、MFA利用者、権限の異なるグループなど、複数条件で見たほうが安全です。
さらに、切り替え日まで旧手順を残したままにするのも混乱の原因になります。利用者は古い接続先を選びがちです。旧手順を見えないところに残しておくと、自己解決しようとした利用者が余計に迷います。
FortiGate SSL-VPN廃止対応の進め方まとめ
FortiGateのSSL-VPN廃止で本当に重要なのは、「SSL-VPNが使えなくなるらしい」という表面的な理解ではなく、SSL-VPNトンネルモードを前提にした運用を、IPsec VPN前提へ移行しなければならないという点です。しかも、既存設定がそのまま自動で引き継がれるわけではないため、アップグレード前の準備が必須です。
進め方としては、まず現行利用者と用途を整理し、機種制約と認証方式を確認し、IPsec側の新構成を先に作ったうえで、限定ユーザーで検証してから全体展開する流れが安全です。装置設定だけではなく、FortiClient配布、利用者手順、問い合わせ対応まで含めて設計してください。
今回の変更は、面倒に見えても、VPN環境を整理するよい機会でもあります。長年継ぎ足しで運用してきた設定を見直し、不要な権限を減らし、利用者ごとに適切な接続方式へ分けることで、むしろ運用しやすい環境に整えられます。
「とりあえずOSを上げてから考える」ではなく、「先に移行を設計してから上げる」。この順番を守るだけで、かなりのトラブルを防げます。FortiGateのSSL-VPN廃止対応は、設定変更の作業というより、リモートアクセス全体の再設計だと捉えるのが実務的です。
