あわせて読みたい関連記事
- FortiGate SSL-VPN廃止に伴うIPsec VPN移行手順
- FortiGate IPsec VPN設定手順｜拠点間接続のCLI設定例
- FortiGate IPsec VPNが繋がらない時の対処法
- FortiGateのUTM機能を徹底解説｜IPS・アンチウイルス・Webフィルタ
- FortiGate CLIコマンド一覧
FortiGate SSL-VPN廃止とは？影響範囲を正しく理解する
style=”color:#334155;margin:0 0 1.5rem;font-size:18px;line-height:1.8;”>FortiGateの「SSL-VPN廃止」という情報を見て、何が本当に使えなくなるのか、いま動いているリモートアクセスはどうなるのか、不安に感じている方は多いはずです。特に、FortiClientでSSL-VPN接続を提供していた環境では、FortiOSのアップグレードをきっかけにリモートアクセス基盤そのものを見直す必要が出てきます。現場でよくあるのは、「FortiOSを上げれば設定もそのまま引き継がれるだろう」と考えてしまうケースです。しかし今回の変更は、単なる画面名称の変更ではありません。SSL-VPNのトンネル接続をそのまま使い続ける前提でアップグレードすると、在宅勤務者や出張者が翌日つながらない、といった大きな影響が出る可能性があります。
この記事では、FortiGateのSSL-VPN廃止とは何を指すのか、なぜ影響が大きいのか、IPsec VPNへ移行するときに何を確認すべきか、どこでハマりやすいのかを実務目線でまとめて解説します。
FortiGateのSSL-VPN廃止とは何を意味するのか
まず整理しておきたいのは、「SSL-VPNが全部まとめて消える」という理解は少し正確ではない、という点です。今回大きく影響を受けるのは、FortiClientなどで利用してきたSSL-VPNのトンネルモードです。
FortiOS 7.6.3以降では、このSSL-VPNトンネルモードがIPsec VPNへ置き換えられる前提になっています。一方、旧SSL-VPN web modeに相当する機能はAgentless VPNという扱いに整理されていますが、一部機種では非対応です。
| 項目 | 従来 | 7.6.3以降 | 実務影響 |
|---|---|---|---|
| SSL-VPN Tunnel Mode | FortiClientでの一般的なリモートアクセス | IPsec VPNへ移行 | 既存構成の見直しが必要 |
| SSL-VPN Web Mode | ブラウザ経由の社内リソースアクセス | Agentless VPNに整理 | 一部機種では使えない |
| アップグレード時 の挙動 | 設定継承を期待しがち | 関連設定は自動移行されない | 事前移行なしは危険 |
なぜ今回の変更がこんなに重いのか
SSL-VPN廃止の影響が大きい理由 style=”color:#334155;margin:0 0 1.5rem;font-size:18px;line-height:1.8;”>今回の変更が重い理由は、単にプロトコル名が変わるからではありません。リモートアクセスは、いまや在宅勤務・障害時対応・夜間メンテナンス・ベンダー保守・拠点の臨時作業など、日常運用の中核になっていることが多いからです。
そのため、SSL-VPNを使っていた環境では、装置設定だけでなく、クライアント設定・認証方式・接続案内・運用手順・問い合わせ対応フローまで含めて見直す必要があります。「利用者にどう切り替えてもらうか」のほうが時間を使うことも珍しくありません。
移行前に必ず確認したいこと
① いま使っているのが本当にSSL-VPNトンネルなのか
自分の環境が対象かどうかの確認方法 style=”color:#334155;margin:0 0 1.5rem;font-size:18px;line-height:1.8;”>FortiClientでVPN接続し、社内LANへルーティングしているなら、ほぼ今回の対象であるSSL-VPNトンネルモードです。この場合はIPsec VPNへの移行が必要になります。利用者がブラウザから特定の社内Webシステムだけを開いている場合は旧Webモードに近い使い方ですが、それもAgentless VPN扱いとなり機種によっては使えない可能性があります。
② FortiGateの機種を確認する
小型モデルや一部シリーズでは、Agentless VPNが使えない条件があります。特に拠点用の小型機は「本社の大型機では使えたから大丈夫」と思い込みやすいです。本社だけでなく、拠点FortiGateをVPN終端にしている環境では、同じ移行方針を全拠点へ一括適用できるとは限りません。
③ 認証まわりを洗い出す
VPN移行では、トンネルそのものより認証方式の確認が重要です。ローカルユーザーなのか、RADIUSなのか、LDAPなのか、SAMLや多要素認証と組み合わせているのかで、切り替え時の影響点が変わります。既存の利用者案内が「この接続名を選ぶ」という説明になっている場合、接続名が変わるだけでも問い合わせが増えます。
④ ポリシーとアドレスオブジェクトを整理する
SSL-VPNでは、専用のインターフェースやアドレスグループを前提にポリシーが組まれていることが多いです。IPsecへ移行すると、参照インターフェースやポリシーの考え方を見直す必要があります。このタイミングで不要なアドレスグループや長年使われていないポリシーも棚卸ししておくと、移行後のトラブルを減らせます。
実務でおすすめの移行手順
誰が・どの端末から・どの業務のために・どの時間帯に接続しているかを整理します。ここが曖昧なままだと、移行後に「業務が成立するか」が確認できないまま本番投入してしまいます。
フルリモートで広く入るユーザー・RDPだけ使うユーザー・特定Webシステムだけ必要なユーザー・保守ベンダーなど、利用者を分けて考えます。全員を同じプロファイルにすると運用が長くなるほど無理が出ます。
既存SSL-VPNをすぐ消すのではなく、先にIPsec側の接続先・認証・アドレス割り当て・ポリシー・DNS・ルーティングを作り込みます。一部利用者から先行移行し、問題がないかを確認する流れが安全です。
利用者向けの案内を後回しにしないことが重要です。接続名・画面遷移・認証手順・初回接続時の注意点・切り替え日を明確にした手順書を準備したほうが、結果的に障害対応より楽です。
可能であれば短期間でも並行稼働を設けるほうが安全です。先行ユーザーで潰した問題を反映してから全体移行することで、本番影響を小さくできます。いきなり全員切り替えはよほど単純な環境でない限りおすすめしません。
確認で使いやすいコマンド例
現行のSSL-VPN設定・認証・ポリシーを洗い出す
show vpn ssl settings
show user local
show user group
show firewall policy
show system interface
get system status機種・リソース状態の確認
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現場でハマりやすいポイント
ポリシーはあるのに通信できない
IPsecへ移行したあと、見た目上はトンネルが確立しているのに業務通信だけ通らないパターンです。原因として多いのは、送信元・宛先アドレスオブジェクトの見直し漏れ・DNSが配布されていない・分割トンネルの対象に必要な宛先が入っていないケースです。「VPNはつながる」と「業務が使える」は別物です。疎通確認ではpingだけで終わらせず、名前解決・RDP・ファイル共有・業務アプリなど実際に使うものを一通り触ることが重要です。
利用者によって成功したり失敗したりする
認証やクライアント配布で起きやすいです。端末ごとにFortiClientの設定が微妙に違う・古い接続プロファイルが残っている・MFAの登録状態が異なる、といった差が出ます。ネットワーク側だけ見ていると再現性の低い障害に見えて苦労します。成功している端末と失敗している端末を並べてクライアントバージョン・接続先名・認証手順を比較するほうが近道です。
443を使っていたからそのまま考えてしまう
SSL-VPN時代は「443で通るから大丈夫」と考えやすかったですが、IPsecへ移行すると通信方式や経路上の扱いをあらためて確認する必要があります。FWやプロキシ・回線事業者側の制約・出先ネットワークのポリシーなど、利用環境によって差が出ます。利用者が自宅だけでなくホテル・客先・モバイル回線・テザリングなどを使う場合は、複数パターンで接続検証しておくと安全です。
切り替え後の問い合わせが想像以上に多い
技術的には成功していても、「画面が変わった」「接続方法が分からない」という理由で問い合わせは増えます。これは障害ではなく運用設計の問題です。事前通知・切り替え日・旧手順の無効化・新手順の図解、この4つが揃うだけでかなり減らせます。
移行時に見直しておきたい設計ポイント
| 見直しポイント | 内容 | 注意点 |
|---|---|---|
| フル vs スプリット トンネル | 全員フルトンネルの必要があるか見直す | スプリットは設計が雑だと「一部だけ通らない」問題が起きやすい |
| アクセス権の 最小化 | グループ単位で必要最小限のアクセス先に整理 | 全員が全サーバへ入れる設計はトラブル時の影響範囲が大きい |
| ログと監視の 整備 | 接続数・失敗率・認証エラーを見える化する | 切り替え直後は障害か操作ミスかの判断が早くなる |
やってはいけない進め方
- 現行設定をよく理解しないまま似たような設定をIPsec側へ並べるだけの移行：見た目は移せても認証フローが再現できず、切り戻しも難しくなります
- 利用者テストを1人だけで終わらせること：IT部門の端末だけ成功しても本番利用者全体を代表しているとは限りません。営業用ノートPC・社外回線・MFA利用者など複数条件で検証しましょう
- 切り替え日まで旧手順を残したままにする：利用者は古い接続先を選びがちです。旧手順が見えていると、自己解決しようとした利用者が余計に迷います
- アップグレード後に考える：これが最も避けたいパターンです。事前移行なしでOSを上げると「設定が見当たらない」「利用者が接続できない」状況になります
まとめ
FortiGateのSSL-VPN廃止で本当に重要なのは、SSL-VPNトンネルモードを前提にした運用を、IPsec VPN前提へ移行しなければならないという点です。既存設定が自動で引き継がれるわけではないため、アップグレード前の準備が必須です。
- まず現行利用者と用途を整理し、機種制約と認証方式を確認する
- IPsec側の新構成を先に作り、限定ユーザーで検証してから全体展開する
- FortiClient配布・利用者手順・問い合わせ対応まで含めて設計する
- 「VPNはつながる」と「業務が使える」は別物。実際に使うものを一通り検証する
- 今回の移行は設定変更の作業というより、リモートアクセス全体の再設計と捉える
「先に移行を設計してから上げる」。この順番を守るだけで、かなりのトラブルを防げます。
