FortiGateのSSL-VPNは、在宅勤務や外出先から社内ネットワークへ安全に接続するために広く使われています。設定自体は比較的わかりやすい一方で、実際の運用では「急につながらなくなった」「認証は通るのに途中で切れる」「接続はできたのに社内へ通信できない」といったトラブルがよく発生します。
厄介なのは、原因が1つとは限らないことです。公開IPやFQDNの到達性、待受ポート、証明書、ユーザー認証、グループ設定、ポータル割り当て、IPプール、ポリシー、ルーティング、DNS、FortiClientのバージョンなど、確認すべき場所が広いので、慣れていないと切り分けに時間がかかります。
現場でも、最初は「FortiGateの設定ミスでは」と思って調査を始めたのに、実際には自宅ルータ側のポート制御や、ユーザーを入れ替えた際のグループ設定漏れ、あるいはトンネル確立後のポリシー不足が原因だった、ということがよくあります。SSL-VPNは単純に見えて、実際には複数の設定が連動して成立している機能です。
この記事では、FortiGate SSL-VPNがつながらないときに、何から確認すべきかを順番に整理しながら解説します。単に設定例を並べるのではなく、どの段階で止まると何を疑うべきか、どのコマンドで確認するか、どう直すかまで、実務で使いやすい流れでまとめています。これからFortiGateを扱う方はもちろん、運用保守で障害対応を担当する方にも使いやすい内容です。
FortiGate SSL-VPNの基本的な仕組み
最初に、SSL-VPNがどういう流れで接続するのかをざっくり押さえておくと、障害の切り分けがしやすくなります。クライアントはまず、インターネット越しにFortiGateの公開IPまたはFQDNへアクセスします。そこでSSL-VPNの待受ポートに接続し、証明書の確認やTLSセッションの確立、ユーザー認証、ポータルの割り当て、トンネルの作成、IPアドレスの払い出し、ポリシーによる通信許可という順番で処理が進みます。
つまり、どこで止まっているかによって、見るべき場所が変わります。そもそもアクセス先に届かないなら公開経路や待受設定、認証で失敗するならユーザーや認証サーバ、接続後に通信できないならポリシーやルーティング、特定ユーザーだけ問題が出るならグループやポータル、特定PCだけ失敗するならFortiClientや端末側設定を疑うべきです。
このように段階で切る考え方ができると、やみくもに設定全体を見直す必要がなくなります。SSL-VPN障害は「つながらない」という結果だけを見ると全部同じに見えますが、実際には止まる地点ごとに原因の傾向がはっきり違います。
FortiGate SSL-VPNがつながらないときの代表的な症状
SSL-VPNの障害は、利用者の言い方だけだと状況が曖昧になりがちです。「つながらない」という言葉でも、実際にはいくつかのパターンがあります。ここを最初に整理しておくと、調査の方向を間違えにくくなります。
URLやFQDNにアクセスしても応答しない
この場合は、FortiGateまで到達していない可能性が高いです。公開IPの誤り、DNS名前解決の誤り、上位ルータやFWでのポート遮断、NAT転送設定漏れ、SSL-VPNの待受インターフェース違いなどを優先して確認します。FortiGate本体の問題というより、到達性の問題であることが多いです。
ログイン画面は出るが認証に失敗する
この場合は、ユーザー情報、パスワード、認証サーバ連携、証明書認証、二要素認証、グループ参照、ポータル割り当てあたりが怪しくなります。利用者から見ると「ログインできない」だけですが、FortiGate側ではどの認証段階で失敗したかをログで確認できます。
認証後に接続が途中で止まる
認証は通るのにトンネルが張れない場合、IPプール枯渇、ポータル設定不備、クライアントバージョン差分、TLS設定不一致、ローカル端末のセキュリティソフト干渉などを疑います。ここは一見ネットワーク問題に見えますが、実際にはクライアント側要因もよくあります。
接続はできるが社内ネットワークへ通信できない
この症状はかなり多いです。SSL-VPNのセッション自体は確立しているため、利用者は「つながった」と思っていますが、実際にはポリシーが足りない、ルートがない、DNSが解決できない、許可ネットワークの設定が足りない、split tunnelの対象漏れ、といった問題で社内リソースへ到達できません。
一部ユーザーだけ失敗する
この場合は、回線やFortiGate本体よりも、ユーザー単位の条件差分を疑うのが効率的です。グループメンバーシップ、AD連携、トークン設定、ポータル割り当て、接続元IP制限、自宅回線側の制限などが原因になりやすいです。
最初に確認したい基本ポイント
いきなり詳細なデバッグに入る前に、まずは大枠の前提が崩れていないかを確認します。ここを飛ばすと、細かい設定ばかり見て時間を失いがちです。
公開IPまたはFQDNが正しいか
まず確認したいのは、利用者が接続先として入力している公開IPやFQDNが正しいかどうかです。意外と多いのが、旧回線のFQDNを使い続けている、DNSレコードの切り替え後に古いキャッシュを参照している、マニュアルのURLが古いままになっている、といった初歩的な問題です。
特に回線更改やHA構成変更のあとに発生した場合は、接続先情報の食い違いをまず疑うべきです。手順書や社内ポータルに載っているURLと、実際に公開されている宛先が一致しているかを確認してください。
SSL-VPNの待受インターフェースとポートが正しいか
FortiGateでは、SSL-VPNがどのインターフェースで待ち受けるか、どのポート番号を使うかを設定します。ここが誤っていると、GUIにはアクセスできてもSSL-VPNだけ失敗することがあります。運用途中で管理GUIポートと競合しないように変更したまま、利用者側へ周知されていないケースもあります。
また、インターネット側に複数回線がある環境では、どの回線のどのIFでSSL-VPNを受けるかが重要です。想定と違うWAN側にだけ設定が入っていると、一部回線からは見えるが別回線からは見えない、といったわかりにくい症状になります。
NATや上位FWでポート転送が正しいか
FortiGateの前段に別ルータやFWがある構成では、SSL-VPN用ポートが適切にFortiGateへ転送されているか確認が必要です。特に小規模拠点や暫定構成では、回線終端装置やISP提供機器でのポート転送設定漏れが原因になることがあります。
現場では、以前は別サービス用に使っていたポート転送設定が残っていて、想定外の宛先へ流れていたということもあります。FortiGate本体だけ見ていても解決しないため、前段装置まで含めて経路を確認することが大切です。
接続元IP制限や地理制限に引っかかっていないか
セキュリティを高めるために、SSL-VPNの接続元IP制限や国別制限をかけている環境は少なくありません。こうした設定があると、社内テスト回線では成功するのに、利用者の自宅回線からだけ失敗することがあります。
特に在宅勤務環境では、プロバイダ変更やモバイル回線利用への切り替えによって接続元グローバルIPが変わるため、「昨日まで使えていたのに急に接続できない」という問い合わせにつながりやすいです。
認証まわりでよくある原因
ログイン画面までは到達するのに、その先で失敗する場合は、認証処理を疑います。ここは利用者から見ると全部同じに見えますが、実際には失敗地点が複数あります。
ローカルユーザーの設定ミス
最も基本的なのは、ユーザー名やパスワードの誤りです。ただし、実務で多いのは単純な入力ミスだけではありません。ユーザー自体は存在していても、SSL-VPN用グループに属していない、無効化されている、想定とは別の認証方式で参照されているといったズレがよくあります。
たとえば、退職者アカウントを削除して新規ユーザーを作り直した際に、グループへの再所属が漏れていて接続できなくなる、というのは現場で起こりやすいです。
LDAPやRADIUS連携の不具合
社内ディレクトリと連携している環境では、FortiGate単体の設定が正しくても、認証サーバ側の到達性や設定不備で失敗することがあります。ADサーバへ名前解決できない、ポートが閉じている、バインドアカウントがロックしている、証明書検証に失敗している、といった要因です。
ここは「VPNがつながらない」ように見えて、実際には社内認証基盤の障害であることもあります。FortiGateだけを疑うのではなく、連携先まで含めて確認することが大切です。
二要素認証やトークン設定の不備
FortiTokenなどを使っている環境では、パスワードが正しくてもワンタイムコードの扱いで失敗することがあります。トークンの紐付け漏れ、時刻ずれ、ユーザー再作成による関連付け不整合などが原因になります。
セキュリティ強化後に問い合わせが増えた場合は、この認証強化施策が関係していないかを疑うべきです。特に運用切り替え直後は、設定投入は済んでいても利用者側案内が不足していることがあります。
トンネル確立で失敗する原因
認証は通るのに接続が最後まで行かない場合は、トンネルそのものの確立処理やクライアント環境を確認します。
FortiClientのバージョン差分
FortiClientとFortiOSの組み合わせによっては、不具合や挙動差が出ることがあります。特定のPCだけ失敗する場合や、FortiGateアップグレード後にだけ接続不良が増えた場合は、FortiClient側のバージョンを確認してください。
現場では、新PCにだけ新しいFortiClientが入り、旧PCと挙動が違っていたということが実際によくあります。利用者からは同じように見えても、内部では違うバージョンが動いていることがあるので要注意です。
TLSや証明書の問題
証明書の期限切れ、証明書チェーン不備、端末側での信頼エラーなどがあると、接続の初期段階で失敗することがあります。ブラウザ経由だと警告表示で気づけても、FortiClient側では単に接続失敗に見えることがあります。
証明書更新作業のあとに不具合が出た場合は、インポートした証明書が正しいか、中間証明書を含めて問題ないかを確認してください。自己署名証明書のまま運用している環境では、端末更新をきっかけに急に弾かれることもあります。
IPプール枯渇
SSL-VPN接続時に利用者へ払い出すIPアドレスプールが不足すると、新規接続が失敗します。ユーザー側からは「認証後に落ちる」「つながったりつながらなかったりする」と見えるため、わかりにくい障害です。
長時間接続が多い環境や、切断済みセッションが残りやすい環境では、想定より早く枯渇することがあります。利用者数が増えたのにプールを見直していない場合は、かなり疑わしいポイントです。
ポータル割り当ての不備
ユーザーやグループに対して、どのSSL-VPNポータルを割り当てるかも重要です。ポータルによってトンネルモードの有無や許可ネットワークの扱いが異なるため、想定と違うポータルが当たると接続挙動が変わります。
よくあるのは、テスト用ポータルのまま本番ユーザーへ割り当ててしまい、接続はできるが必要なネットワークへ行けない、というケースです。ユーザー追加時にグループだけ見て安心し、ポータルの違いを見落とすことがあります。
接続後に社内へ通信できない原因
運用上いちばん多いのは、実はこのパターンです。利用者からは「VPNはつながるけど使えない」と言われるため、障害か設定不足かの判断がつきにくくなります。
ファイアウォールポリシー不足
SSL-VPNユーザーが社内ネットワークへアクセスするには、SSL-VPNインターフェースから内部セグメントへのポリシーが必要です。このポリシーがない、または送信元ユーザーグループが一致していないと、トンネル自体は張れても通信は通りません。
特にユーザー追加や部門追加のときに、認証グループだけ更新してポリシー側の条件を更新していないと、接続成功後に一部通信だけ失敗する状態になります。
ルーティング不足
内部ネットワーク側からSSL-VPNクライアント宛の戻り経路がないと、片方向通信になります。FortiGate配下で完結する構成なら気づきにくいですが、内部に別のL3スイッチやルータがいる環境では、戻りルート漏れが非常によくあります。
pingを打つと片側だけ見える、あるいはセッションは張るがアプリ通信が成立しない場合は、経路の往復を必ず確認してください。
DNS設定の不備
社内サーバへは名前でアクセスする運用が多いため、VPN接続後のDNS設定が不足していると、IP直打ちは通るのにホスト名では使えないという現象が起きます。利用者は「社内システムに入れない」と表現しますが、実際にはアプリ障害ではなくDNSの問題であることがあります。
split tunnel環境では、社内向けDNS問い合わせが正しくVPN側へ流れるかも重要です。ここが崩れると、一見VPNが不安定に見えることがあります。
Split Tunnelの対象漏れ
全トラフィックをVPNへ流さず、社内宛だけをトンネルへ流すsplit tunnel構成では、許可ネットワークの定義が不足していると、一部社内セグメントだけ通信できません。拠点追加やサーバ移設のあとにこの問題が起こりやすいです。
たとえば、既存の10.10.0.0/16だけ許可していたところへ、新しく10.20.0.0/16のサーバ群を追加したのに、SSL-VPN側の許可ネットワークを更新していないと、新サーバだけ使えないという問い合わせになります。
確認に使いやすいコマンド例
障害調査では、まずshow系コマンドやセッション確認から入るのが基本です。いきなり詳細デバッグを取るより、現状把握をしてから深掘りした方が早いことが多いです。
SSL-VPN設定の確認
show vpn ssl settings
show user local
show user group
show firewall policy
get vpn ssl settings
get user group
get router info routing-table allshow vpn ssl settings では、待受インターフェース、ポート、サーバ証明書、IPプール、ポータル設定などを確認します。まずはここで、想定している設定が本当に入っているかを見てください。
ログ確認
execute log filter category 1
execute log display認証失敗や接続失敗のログが見える場合、どの段階で落ちているかの手がかりになります。本番環境ではログ量が多いので、対象ユーザー名や時間帯を絞って確認すると追いやすいです。
デバッグの基本例
diagnose debug reset
diagnose debug application sslvpn -1
diagnose debug enableこれでSSL-VPN関連のデバッグを確認できます。ただし、本番環境では出力量に注意が必要です。確認後は必ず停止します。
diagnose debug disable
diagnose debug resetユーザー認証関連の確認
diagnose test authserver ldap
diagnose test authserver radius LDAPやRADIUS連携を使っている場合は、FortiGateから認証サーバへ正しく問い合わせできるかを確認します。VPNが悪いように見えて、実は認証連携が失敗しているだけということは珍しくありません。
IPプールや接続状況の確認
get vpn ssl monitor
diagnose vpn ssl list現在の接続ユーザーや払い出しアドレスを確認できます。接続数が想定より多い、切断済みのように見えるセッションが残っている、プールに余裕がないといった状況を把握できます。
よくある設定ミスの具体例
ポリシーにSSL-VPNの送信元が入っていない
SSL-VPNユーザー向けのポリシーを作ったつもりでも、送信元インターフェースやユーザーグループ条件が違っていると、接続後の通信が通りません。GUIで見ると似た名前のオブジェクトが並びやすいため、思い込みで設定してしまうことがあります。
config firewall policy
edit 100
set name "SSLVPN_to_LAN"
set srcintf "ssl.root"
set dstintf "internal"
set srcaddr "all"
set dstaddr "LAN_SUBNET"
set action accept
set schedule "always"
set service "ALL"
set groups "SSLVPN_Users"
set nat disable
next
endこの種の設定では、srcintf、dstintf、groups のどれかが少しでもずれていると、接続だけ成功して通信が通らない状態になります。
SSL-VPNポータルと認証ルールの組み合わせがずれている
認証ルールでどのグループにどのポータルを当てるかを設定しますが、ここがずれると意図しない権限や通信範囲になります。特にテストユーザー追加時に、一時的なポータルがそのまま残ることがあります。
config vpn ssl web portal
edit "full-access"
set tunnel-mode enable
set split-tunneling enable
set ip-pools "SSLVPN_POOL"
next
end
config vpn ssl settings
config authentication-rule
edit 1
set groups "SSLVPN_Users"
set portal "full-access"
next
end
endユーザーは認証できるのに必要な宛先へ届かない場合、このポータル割り当ても確認してください。
Split Tunnelの許可ネットワークが古い
運用中に社内セグメントが増えても、SSL-VPNの対象ネットワークを更新し忘れることがあります。結果として、古いサーバ群へは行けるのに、新しいシステムだけ使えないという中途半端な障害になります。
このパターンは、利用者からは「特定システムだけ不安定」と見えるため、アプリ担当へ誤ってエスカレーションされやすいです。実際にはVPN側の対象ネットワーク不足ということがよくあります。
切り分けを速くする実務的な順番
SSL-VPN障害は、確認する場所が多いぶん、順番を決めておくとかなり効率が上がります。現場では次の流れで見ると無駄が少ないです。
1. まず到達性を見る
FQDN、公開IP、待受ポート、前段NAT、上位FWを確認します。ログイン画面すら出ないなら、まずここです。
2. 認証段階かどうかを切り分ける
認証失敗なのか、認証後失敗なのかを分けるだけで、確認範囲がかなり狭まります。ユーザー情報、LDAP、RADIUS、二要素認証を見ます。
3. トンネル確立条件を確認する
FortiClientバージョン、証明書、ポータル、IPプール、端末側ソフト干渉を確認します。特定端末だけ失敗するなら、この観点が重要です。
4. 接続後の通信条件を確認する
ポリシー、ルーティング、DNS、split tunnel、宛先側戻りルートを見ます。ここは「接続できるのに使えない」系の障害で特に重要です。
5. 最後にログとデバッグで裏を取る
show系と設定比較で見えない場合に、ログやデバッグで確定させます。最初から深追いするより、ある程度仮説を立ててから確認した方が速いです。
再発防止のために見直したいこと
SSL-VPN障害は、その場で直して終わりにすると再発しやすいです。原因の多くが、利用者追加時の手順漏れ、ネットワーク変更後の更新漏れ、バージョン管理不足、設計書未整備にあります。
まず、ユーザー追加時に確認する項目をテンプレート化しておくと効果があります。ユーザー作成、グループ所属、二要素認証、ポータル割り当て、ポリシー条件、接続確認までを一連で定義しておくと、人的ミスが減ります。
次に、社内ネットワーク変更時はSSL-VPN影響確認をセットにしてください。サーバ移設や新セグメント追加のたびに、split tunnel対象、ポリシー、ルート、DNSを確認する運用にしておくと、接続後の通信不良を防ぎやすくなります。
また、FortiClientとFortiOSのバージョン管理も重要です。利用者ごとにバージョンがばらばらだと、障害発生時の再現性が低くなります。配布バージョンをある程度そろえ、更新ポリシーを持っておくと、切り分けがかなり楽になります。
以前、ユーザー数増加に合わせてVPN利用者を一気に追加した際、設定自体は正しく見えたのに、一部ユーザーだけ社内システムへ行けないことがありました。最終的には、追加した業務サーバ群がsplit tunnelの対象に入っていなかったのが原因でした。接続成功だけを確認して作業完了にすると、この手の問題は見逃しやすいです。SSL-VPNでは「ログインできた」ではなく「必要な業務通信が成立する」まで確認して初めて完了と考えた方が安全です。
FortiGate SSL-VPNでよくある質問
ログイン画面は出るのに接続できません
到達性ではなく、認証、ポータル、証明書、FortiClient、IPプールあたりを疑ってください。特に認証後に落ちる場合は、ユーザー情報が正しいだけでは不十分で、接続後処理まで成立しているかを見る必要があります。
接続はできるのに社内サーバへ行けません
ポリシー不足、戻りルート不足、DNS不備、split tunnel対象漏れが代表的です。VPNが張れたことと、社内通信が成立することは別問題として考える方が切り分けしやすいです。
一部ユーザーだけ失敗します
グループ所属、二要素認証、接続元IP制限、自宅回線差分、端末側FortiClient差分を優先して見てください。FortiGate本体より、ユーザーごとの差分が原因であることが多いです。
ブラウザでは見えるのにFortiClientで失敗します
FortiClientのバージョン、証明書信頼、TLS設定、端末側セキュリティソフト、ローカルネットワーク制限を確認してください。ブラウザ到達性とトンネル確立は別の段階です。
まとめ
FortiGate SSL-VPNがつながらないときは、単に「VPN障害」とひとくくりにせず、どの段階で止まっているかを切り分けることが重要です。まず公開IPやFQDN、待受ポート、NATなどの到達性を確認し、その次に認証、ポータル、トンネル確立、接続後通信という順番で見ていくと、かなり効率よく原因を絞れます。
特に実務で多いのは、認証そのものの失敗よりも、接続後のポリシー不足、ルーティング漏れ、DNS不備、split tunnel対象漏れです。利用者からは全部「VPNがつながらない」と聞こえますが、実際には接続自体は成功していて、その先の業務通信だけが失敗しているケースが非常に多いです。
FortiGateのSSL-VPNは便利な機能ですが、運用が長くなるほど設定の積み重ねで見えにくい差分が増えます。だからこそ、障害対応では場当たり的に見るのではなく、到達性、認証、トンネル、通信許可の順番で機械的に確認できるようにしておくことが大切です。この流れを手順化しておくだけでも、障害対応のスピードと再現性はかなり変わります。
