FortiGateでリモートアクセスVPNを運用していると、避けて通れなくなってきたのがSSL-VPNからIPsec VPNへの移行です。これまでSSL-VPNで安定運用していた環境でも、FortiOSのアップグレード計画にあわせて「このまま上げて大丈夫か」「FortiClient側は何を直せばいいのか」「利用者影響を最小化するにはどう進めるべきか」と悩むケースは多いと思います。
特に現場では、VPNの方式そのものを変える話になると、単純な設定変更では終わりません。認証方式、アドレス払い出し、ポリシー、DNS、分割トンネル、ユーザーへの案内、切り戻しまで含めて考えないと、移行当日に「接続はできるのに社内へ行けない」「一部ユーザーだけ名前解決できない」「認証情報は通るのにトンネルが上がらない」といった事故が起きやすくなります。
この記事では、FortiGateのSSL-VPNからIPsec VPNへ移行する理由、事前確認、実際の移行手順、CLI設定例、よくある失敗、切り戻しの考え方まで、WordPressにそのまま貼りやすい形でまとめました。初心者にも流れがわかるように整理しつつ、現場で本当に困るポイントは薄くならないようにしています。
なぜFortiGateでSSL-VPNからIPsec VPNへの移行が必要なのか
まず前提として押さえたいのは、今回の話は「新しい方式もありますよ」という任意の検討ではなく、FortiOSのバージョンによっては事実上の必須対応になるという点です。
これまでFortiGateではリモートアクセスVPNとしてSSL-VPNが広く使われてきました。設定しやすく、TCP 443を使えるため、社外ネットワークでも通しやすいという理由から、長く選ばれてきた方式です。ただし、今後はSSL-VPNトンネルモードを前提に運用を続ける設計が難しくなります。
実務で重要なのは、単に「名称が変わる」わけではないことです。運用者の感覚では、SSL-VPNの接続定義をそのまま持ち上げて、アップグレード後も少し直せば使えるように思いがちです。しかし、実際にはVPN方式が変わるため、認証・暗号化・クライアント定義・ポリシー確認のやり直しが必要になります。
現場でいちばん危ないのは、アップグレード計画ばかり先に進み、VPN移行を後回しにすることです。夜間メンテナンス後に在宅ユーザーが翌朝つながらない、運用担当だけが社内に入れて一般利用者が入れない、といった形で発覚すると収拾がつきにくくなります。実際、VPNは障害が起きると利用者数が一気に表面化するので、LAN内の小規模トラブルよりも影響範囲が大きくなりがちです。
移行前に確認しておくべきポイント
SSL-VPNからIPsec VPNへの移行で失敗しやすいのは、機器設定よりも設計情報の棚卸し不足です。先に設定画面を触り始めるより、まず今のSSL-VPN環境で何を実現しているかを洗い出したほうが結果的に早く終わります。
現在のSSL-VPNで使っている要素を整理する
最低限、次の情報は整理しておきたいところです。ユーザーグループ、認証方式、二要素認証の有無、接続先のFQDN、割り当てIPレンジ、split tunnelの有無、許可する社内セグメント、DNSサーバー、接続後に必要な名前解決、利用クライアントのOS、FortiClientの配布方法です。
この整理が甘いと、移行後に「VPN自体は張れたのに、社内の名前解決だけできない」「開発用セグメントだけ到達できない」「特定部署のユーザーだけ入れない」という、切り分けしづらいトラブルになります。現場でも、設定変更そのものより、移行元の要件が曖昧なことが一番の遅延要因になりがちです。
利用者端末のFortiClientバージョンを確認する
サーバー側だけ整えても、クライアント側が要件を満たしていないと移行は成功しません。社内PCは配布ポリシーでそろえられていても、持ち出し端末や一部の例外PCだけ古いバージョンが残っていることは珍しくありません。
特に、これまでSSL-VPNで問題なく使えていた利用者ほど、「昨日まで使えたのに今日はつながらない」と感じやすいため、運用側の説明不足がそのまま問い合わせ増加につながります。移行前に端末のFortiClientバージョンを確認し、対象ユーザーへ配布手順を先に案内しておくことが重要です。
TCP 443を使い続ける必要があるか確認する
SSL-VPNを使っていた環境では、社外ネットワーク側の制限やモバイル回線の事情から、TCP 443で通せることを大きなメリットとしていたケースが多いはずです。IPsec VPNへ移行する際も、同じように通過性を重視するのか、それとも標準的なUDPベースで問題ないのかを先に決めておきましょう。
この判断を曖昧にしたまま移行すると、テスト環境では成功したのに、出張先ホテルやテザリング経由では接続できないという事態が起きます。リモートアクセスVPNは「本社回線から見て正しい」だけでは足りず、利用者が実際に使う回線条件で考える必要があります。
切り戻し条件を先に決める
移行作業の前に、どの状態なら成功とみなすか、どの状態なら切り戻すかを定義しておくと、当日の判断がぶれません。おすすめは「接続成功」「社内DNS名前解決」「主要3セグメント疎通」「RDPやWeb業務システム利用」のように、利用者目線の確認項目で判定基準を作ることです。
設定差分だけ見ていると、管理者は成功と思い込みやすいのですが、実際の業務アプリが使えなければ移行成功とは言えません。ここは意外と見落とされます。
SSL-VPNとIPsec VPNの違いをざっくり押さえる
厳密なプロトコル解説は長くなるので、移行時に必要な観点だけ整理します。
SSL-VPNはFortiGate上でユーザー認証し、トンネルを張って社内リソースへ到達させる方式として使われてきました。一方、IPsec VPNはネットワーク層で暗号化トンネルを作る方式です。利用者から見ると「VPNで社内へ入る」という体験は似ていますが、設定項目やトラブル時の見方は少し変わります。
運用の違いとして大きいのは、IPsec VPNではPhase1、Phase2、認証方式、提案する暗号スイート、NAT越え、経路配布やDNS配布など、確認ポイントがより明確になることです。その代わり、どこで失敗しているかをログやネゴシエーションで追いやすい面もあります。
感覚的には、SSL-VPNは「クライアントアクセスの仕組み」として見ていたものを、IPsec VPNでは「トンネルと経路の設計を伴う仕組み」として捉えると理解しやすいです。
おすすめの移行手順
実務では、一気に本番切り替えするより、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この段階で、SSL-VPN用ポリシーにどのアドレスオブジェクトやサービスが紐づいているかも確認しておきます。後でIPsec用ポリシーを作るとき、思いのほか再利用できます。
手順2：移行対象ユーザーと接続要件を整理する
全ユーザーを同一設定にするのか、部署ごとにアクセス先を分けるのかを決めます。VPN移行のタイミングは、権限見直しの良い機会でもあります。昔作ったままの広すぎるアクセス権が残っている場合は、この機会に整理したほうが安全です。
たとえば、一般利用者は社内ポータルと業務システムのみ、運用担当は管理セグメントも許可、開発担当は検証環境のみ、というように整理すると、IPsec用ポリシーも見通しがよくなります。
手順3：FortiGate側にIPsecリモートアクセスVPNを作成する
ここでは、わかりやすさ重視で、リモートアクセス用のIPsec VPNを新規作成する前提で考えます。既存オブジェクト名を流用しすぎると、切り戻し時に混乱しやすいため、最初は「ipsec_ra_01」のように別名で作るほうが安全です。
CLI例は環境に応じて読み替えてください。以下はあくまでサンプルです。IPアドレスやホスト名は仮の値を使っています。
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 transport tcp
set tcp-port 443
set xauthtype auto
set authusrgrp "vpn_users"
next
endここで大事なのは、SSL-VPN時代に使っていたアドレス帯と重複しないVPNクライアント用IPレンジを選ぶことです。社内LANや拠点VPNのアドレスと重なると、接続自体は成功しても戻りルートやポリシー判定で不可解な動きになります。
手順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実際の環境では、複数セグメントへのアクセスが必要なことが多いので、要件に応じて設計します。split tunnelを使う場合は、社内向けルートだけを配布する考え方が整理しやすいです。
手順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を使っている環境なら、プロファイル配布で段階移行しやすくなります。EMSがない場合も、利用者向け手順書は必須です。
このとき、利用者向け案内は技術的に正しいだけでは足りません。「旧接続を消すタイミング」「新接続を追加する前に何を確認するか」「接続後にどの画面が出れば成功か」まで書いておくと、問い合わせをかなり減らせます。
手順7：テストユーザーで事前検証する
本番切り替え前に、まずは情報システム部門や運用担当など、切り分けに協力できる少人数ユーザーで検証します。確認項目は、接続成功、社内DNS参照、主要サーバー疎通、ファイル共有やRDP接続、業務Webアクセス、分割トンネルの動作、切断後の再接続あたりが基本です。
ここで大事なのは、社内Wi-Fiからの検証だけで終わらせないことです。自宅回線、モバイル回線、ホテル回線のように、実際の利用条件に近い経路で試しておくと、当日の事故を減らせます。以前、社内検証だけでは完璧に見えたのに、テザリング環境でだけ不安定になり、結果的にTCP利用前提で設計し直したことがありました。こういう差は、机上では見えにくい部分です。
手順8：全体展開と切り替えを行う
検証が完了したら、対象ユーザーへ案内を出し、旧SSL-VPNから新IPsec VPNへ切り替えます。理想は、一定期間だけ併用期間を設けて、早めに接続確認をしてもらうことです。切替当日に全員一斉変更だと、問い合わせ窓口が詰まりやすくなります。
よくあるトラブルと確認方法
接続は成功するのに社内へ通信できない
このパターンは非常に多いです。原因としては、ポリシー不足、到達先アドレス設定漏れ、split tunnelの経路不足、戻りルート不足、DNS配布漏れが代表的です。
まずはFortiGate側でセッションやログを確認し、ポリシーに当たっているかを見ます。あわせて、クライアント側で割り当てIP、受信したDNS、ルート情報も確認します。疎通確認はpingだけでなく、名前解決と業務アプリの接続まで見たほうが確実です。
get vpn ipsec tunnel summary
diagnose vpn ike gateway list
diagnose vpn ike log-filter clear
diagnose debug reset
diagnose debug application ike -1
diagnose debug enableIKEデバッグは便利ですが、業務時間帯に漫然と流すとログ量が増えるので、対象時間を区切って使うのがおすすめです。
認証は通るのにトンネルが安定しない
この場合は、暗号スイート不一致、NAT越えの問題、クライアント側設定差異、回線品質の影響を疑います。特に、自宅回線では安定するのにモバイル回線では不安定、という場合は、通過性を優先した設計に寄せる必要があります。
SSL-VPN時代は通っていたのにIPsecで不安定という相談は、プロトコルの違いだけでなく、途中経路の制限が影響していることが少なくありません。そういうときに、TCP 443での利用を設計に含めておく意味が出てきます。
一部のユーザーだけ接続できない
このケースは、ユーザーグループ紐付け、認証基盤側の属性、FortiClientバージョン差、残存する旧VPN定義の競合などが原因になりやすいです。全員に同じ手順書を配ったつもりでも、実際には旧接続先を選んでいた、端末再起動が未実施だった、資格情報キャッシュが残っていた、といった運用面の要因もあります。
技術的な切り分けだけでなく、「接続先名は何を選んだか」「どのエラー表示が出たか」「自宅か社外か」まで聞き取ると、見える景色がかなり変わります。
移行時の注意点
SSL-VPNの設定名をそのまま流用しない
移行時に既存名を流用すると、どちらの方式を見ているのか混乱しやすくなります。特に障害対応中は、名前が似ているだけで確認漏れが起きます。移行完了までは、旧SSL-VPNと新IPsec VPNが一目で区別できる命名にしておくのが安全です。
VPNクライアント用IPレンジの重複に注意する
社内LAN、クラウドVPC、拠点間VPN、検証環境とアドレスが増えている組織ほど、重複の罠にはまりやすいです。VPN移行で不達が起きると、認証や暗号設定ばかり疑ってしまいますが、実際には単なるアドレス設計ミスだったということもあります。
DNS設計を軽く見ない
利用者はIPアドレスで業務をしません。業務システムのURL、社内ファイルサーバー名、社内ポータルの名前解決ができて初めて「つながる」と感じます。VPNの疎通試験をするときは、必ずDNSもセットで確認してください。
案内文の質が問い合わせ件数を左右する
現場感のある話をすると、VPN移行は設定そのものより利用者案内で差がつきます。管理者向けには簡単に見える変更でも、利用者には「いつもと違う接続を選ぶ」「古い設定を消す」「再サインインする」というだけでハードルになります。手順書は、設定値の羅列ではなく、画面遷移と成功判定まで含めたものにしておくと効果的です。
切り戻しの考え方
移行計画には、成功手順と同じくらい切り戻し条件が重要です。おすすめは、移行後30分から60分程度で確認すべき項目を事前に決めておき、未達なら戻す判断をする運用です。
切り戻しで必要になるのは、旧設定のバックアップ、旧クライアント配布手順、利用者への周知テンプレートです。特にFortiClientをEMSで管理している場合は、新旧プロファイルの適用順序まで確認しておきましょう。設定だけ戻しても、端末側が新プロファイルのままだと、利用者は旧接続に戻れません。
また、切り戻しを考えるなら、本番切り替えの前に「旧設定がまだ有効な時間帯」を確保しておくことも大切です。完全撤去を急ぎすぎると、戻す選択肢が事実上なくなります。
実務でのおすすめ構成
これから移行するなら、いきなり全社一括よりも、まずは情報システム部門と一部部門でIPsec VPNを先行導入し、動作を安定させてから全体展開する流れをおすすめします。構成としては、接続先FQDNを明確にし、VPNクライアント用アドレスプールを専用化し、アクセス先セグメントを必要最小限に分け、DNS配布を明示し、TCP利用の必要性を早めに判断しておくと後戻りが少なくなります。
移行案件では、設定画面だけを見ていると単なる置き換えに見えますが、実際には「認証・経路・名前解決・利用者運用」の4点セットで考えたほうがうまくいきます。この視点があると、トラブル時の切り分けもかなり楽になります。
まとめ
FortiGateのSSL-VPNからIPsec VPNへの移行は、単なる機能変更ではなく、今後のFortiOS運用を見据えた実務対応です。特に重要なのは、アップグレード前に移行計画を立てること、SSL-VPNの現行要件を棚卸しすること、FortiClient側まで含めて準備すること、そして少人数検証を挟んでから本番展開することです。
移行で失敗しやすいポイントは、ポリシー不足、経路不足、DNS配布漏れ、利用者案内不足の4つです。逆に言えば、この4つを丁寧に潰していけば、移行はそこまで怖い作業ではありません。
「とりあえずアップグレードしてから考える」は、このテーマでは避けたほうが安全です。まずは今のSSL-VPN構成を整理し、IPsec VPNで同じ業務要件を満たせる形に落とし込み、その上で段階的に切り替えていくのが現実的です。地味ですが、この順番がいちばん事故を減らします。
