Cisco Secure Access の通信障害｜MSS 調整と切り分け

はじめに

Cisco Secure Access へ拠点の通信を誘導した直後に、IPsec トンネルも BGP も正常なのに Web サイトが開かない、という状況に遭遇することがあります。Secure Access のログには通信が記録され、TCP 443 への接続テストも成功するため、どこに問題があるのか判断しにくい障害です。

本記事では、2026 年 10 月 15 日に Cisco dCloud のラボ環境で発生した Web 通信のタイムアウトを題材に、PBR の有無による比較、TCP とアプリケーション層の確認、Secure Access のログ、Embedded Packet Capture による TCP の調査、MTU と MSS の変更までの切り分けを、各確認で何が分かったかとあわせて解説します。

結論として、今回の環境では、Tunnel の MTU を Cisco の要件である 1390 バイトに変更しても改善せず、TCP MSS を 1280 から 1000 に下げた後に Google と ChatGPT が正常に表示されました。ただし、パケットが欠落した機器や通信区間は特定できておらず、MSS 1000 は切り分けの中で試した値であり、推奨値ではありません。

Secure Access の全体像は概要編の『Cisco の SASE｜Secure Access の構成と導入のポイント』で、IPsec・BGP の確認や PBR の設定は基本編『Cisco Secure Access の設定｜ChatGPT の可視化と遮断』で解説しています。本記事では構築手順は繰り返さず、障害の切り分けに絞って説明します。

Cisco Secure Access 経由で発生した障害と構成

障害が発生したのは、基本編で構成した検証環境です。切り分けに関係する構成は次のとおりです。

拠点の通常のインターネット通信は OSPF のデフォルトルートで WAN 側へ出ており、検証端末の Web 通信だけが PBR で Secure Access へ転送される構成です。ICMP は PBR の対象ではないため、ping が成功しても、Secure Access を経由した Web 通信が正常であるとは判断できません。

Google と ChatGPT で ERR_TIMED_OUT が発生

PBR を有効にすると、検証端末の Chrome で https://www.google.com/ と https://chatgpt.com/ が開けなくなり、ERR_TIMED_OUT が表示されました。ChatGPT だけでなく Google でも同じ症状が出たため、ChatGPT 固有のアプリケーション制御だけを原因と考えるべき状況ではありませんでした。

一方、このとき次の状態を確認しています。

• IPsec の 2 本のトンネルは確立していた
• eBGP の 2 つのピアは Established だった
• Secure Access の Activity Search に Web 通信が記録され、アクションは Allow だった

Activity Search に記録が残っていることから、通信は Secure Access まで到達しています。しかし、Secure Access へ通信が到達していることと、端末が Web ページを正常に受信できることは別です。この食い違いが、今回の切り分けの出発点になりました。

PBR の解除で通常経路と比較する

最初に、PBR の有無で結果を比較しました。

この比較により、検証端末やブラウザーだけの問題ではなく、Secure Access を経由する通信経路またはその処理に調査対象を絞れました。ただし、PBR 自体の設定不良が確定したわけではありません。PBR を外すと通信が通常経路を通るため、経路上のどこかに原因がある可能性が残るという意味です。

検証時は、次のコマンドで GigabitEthernet4 から PBR の適用を解除し、通常経路へ切り戻しました。Route Map を削除するのではなく、インターフェースへの適用だけを解除する操作です。

configure terminal
interface GigabitEthernet4
 no ip policy route-map LAB-SSE-WEB-PBR
end

本番環境で PBR を解除・再適用すると、対象の通信経路が切り替わります。影響を受ける端末や通信、切り戻しの手順を事前に確認してから実施してください。

なお、今回の検証端末には業務・検証用 LAN と管理用ネットワークの両方の接続がありました。PBR の対象は送信元アドレスで決まるため、切り分けの前に、送信元の IP アドレスとデフォルトゲートウェイを確認し、検証対象の端末と経路を使っていることを確かめておく必要があります。Test-NetConnection の出力に表示される SourceAddress も確認材料になります。

TCP 接続は成功するのに Web が開かない原因を切り分ける

次に、TCP の接続、アプリケーション層の応答、Secure Access のログを順に確認し、どこまでの処理が成功しているかを切り分けました。

Test-NetConnection で TCP 443 の接続を確認

PowerShell で TCP 443 への接続を確認しました。

Test-NetConnection www.google.com -Port 443
Test-NetConnection chatgpt.com -Port 443

どちらも TcpTestSucceeded : True となりました。これは TCP の 3 ウェイハンドシェイクが成立したことを示します。TCP 接続の成功は、TLS ハンドシェイクや HTTP レスポンスの受信が成功することまでは示しません。「443 番ポートに接続できるから HTTPS は正常」とは判断できません。

curl で HTTPS・HTTP GET・HEAD の応答を確認

続いて curl でアプリケーション層の応答を確認しました。

curl.exe -v --http1.1 --connect-timeout 10 --max-time 25 -o NUL https://www.google.com/
curl.exe -v --http1.1 --connect-timeout 10 --max-time 20 -o NUL http://www.google.com/
curl.exe -v -I --http1.1 --connect-timeout 10 --max-time 20 http://www.google.com/

平文の HTTP でもリクエスト送信後にタイムアウトしているため、HTTPS の証明書や TLS 復号だけの問題とは考えにくい状況でした。ただし、HEAD の応答が小さいとは限らないため、HEAD が失敗したことだけでパケットサイズに関連する問題の可能性は除外できません。この段階では、故障箇所を特定する材料はまだありませんでした。

Secure Access の HTTP 200 と端末の 0 bytes received を比較

curl の HEAD 試験に対応する Secure Access のイベントには、次の値が記録されていました。

Secure Access が HTTP 200 を記録していても、その応答がクライアントに届いたとは限りません。Secure Access のログは Secure Access 側の処理結果であり、端末での受信成功を示すものではありません。1435 B も Secure Access のイベント上の記録値で、そのデータが端末へ届いたことを示す数値ではありません。この結果から、「Secure Access が応答しているのだからルーター以降に問題はない」とも断定できず、Secure Access から端末までの戻り方向の通信を調べる必要がありました。

MTU と TCP パケットを調査する

戻り方向の応答が端末へ届いていない可能性があるため、トンネルの MTU と、LAN 側での TCP の状態を確認しました。

Tunnel MTU を 1422 から 1390 へ変更しても改善せず

Cisco の公式資料「Network Tunnel Groups」の「Maximum Transmission Unit (MTU) Size」では、Secure Access の IPsec トンネルの内部パケットの MTU を 1390 バイト以下にする必要があると説明されています。

検証環境の Tunnel1 / Tunnel2 を確認すると、MTU は 1422 バイトでした。

Router# show ip interface Tunnel1 | include MTU
  MTU is 1422 bytes
Router# show ip interface Tunnel2 | include MTU
  MTU is 1422 bytes

両方のトンネルに ip mtu 1390 を設定し、MTU is 1390 bytes に変わったことを確認しました。

interface Tunnel1
 ip mtu 1390
interface Tunnel2
 ip mtu 1390

しかし、MTU を 1390 に変更しただけでは障害は解消しませんでした。変更後も eBGP の両ピアは Established のままで、HTTP HEAD は引き続き 0 bytes received でタイムアウトしました。

Embedded Packet Capture で LAN 側の TCP を確認

次に、C8000V の LAN 側 GigabitEthernet4 で Embedded Packet Capture（EPC）を使い、検証端末とやり取りされる TCP パケットを確認しました。今回の検証で実行を確認できているのは、キャプチャ結果を表示する show monitor capture LABHTTP buffer detailed です。

EPC の設定・開始・停止・表示・削除の流れは、Cisco の EPC 設定例に記載されています。この資料の例は TCP 全体（any any）を対象とし、インターフェースも検証環境とは異なる参考値です。また、対象は IOS XE 3.7 以降で、17.4 系の個別の構文までは確認できていません。

本番環境でキャプチャする場合は、対象の端末・宛先・プロトコルを絞り込み、取得時間とバッファーの容量を限定してください。広い条件で長時間取得すると、機器の負荷や、業務通信の内容を不要に取得することにつながります。使用するコマンドは、自環境のバージョンのコマンドヘルプや公式資料で確認してください。

今回のキャプチャについて、検証時の解析メモには次の内容が記録されています。元のパケット出力全体は本記事の資料に含まれていないため、記載はこのメモの範囲にとどめます。

1. SYN、SYN/ACK、ACK による TCP 接続の成立
2. Windows から HTTP HEAD のリクエストが送信されていること
3. 戻り方向に、215 バイトの TCP データを含むパケットが到着していること
4. そのデータのシーケンス番号が、期待されるシーケンス番号から 1268 バイト先に進んでいたこと
5. その次に観測された ACK に、SACK オプションが含まれていたこと

TCP のシーケンス番号の欠番と SACK の読み方

TCP では、送信するデータの各バイトにシーケンス番号が割り当てられ、受信側は「次に受け取りたいシーケンス番号」を ACK 番号として返します。途中のデータが届かずに後続のデータだけが届いた場合、受信側は ACK 番号を進めることができず、SACK オプションで「どの範囲は受信済みか」を送信側へ知らせます。

参考: RFC 2018 – TCP Selective Acknowledgment Options
“to inform the data sender of non-contiguous blocks of data that have been received and queued”
（受信してキューに保持している、連続していないデータのブロックをデータ送信側へ知らせるため）
https://www.rfc-editor.org/rfc/rfc2018.html

RFC 2018 では、SACK を使っても ACK 番号の意味は変わらないと説明されています。ACK 番号は引き続き「まだ受け取れていない最初のシーケンス番号」を示し、SACK ブロックは、それより先で受信済みの範囲を、先頭（left edge）と末尾の次の番号（right edge）で示します。

解析メモの記録をこの仕組みに当てはめると、後続の 215 バイトは受信されたものの、その前にある 1268 バイト分のデータが受信されていないため、ACK 番号が進まず、受信済みの範囲が SACK で通知された状態と解釈できます。ただし、SACK ブロックの具体的な範囲や ACK 番号の値は解析メモに記録しておらず、本記事では示していません。

アプリケーションには連続したデータしか渡されないため、先行データが欠けたままでは、curl は HTTP の応答を受け取れません。これは、curl が 0 bytes received でタイムアウトしたこととも整合します。

現時点で判断できること、できないこと

キャプチャの結果は重要な手がかりですが、そこから言える範囲には限りがあります。

LAN 側のキャプチャだけでは、データがルーター内部、トンネル区間、Secure Access 側のどこで失われたのかを区別できません。キャプチャの取りこぼしの可能性も、厳密には否定できません。

MSS の変更による復旧を確認する

MTU の変更では改善しなかったため、次に TCP MSS を調整しました。

TCP MSS を 1280 から 1000 へ変更

ip tcp adjust-mss は、ルーターを通過する TCP 接続の SYN パケットに含まれる MSS の値を書き換え、接続で使われるセグメントの最大サイズを抑えるコマンドです。

参考: IP Addressing Configuration Guide, Cisco IOS XE 17.x – TCP
“The ip tcp adjust-mss command is effective only for TCP connections passing through the device.”
（ip tcp adjust-mss コマンドは、デバイスを通過する TCP 接続に対してのみ有効です。）
https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ip-addressing/b-ip-addressing/m_iap-tcp_for_xe.html

検証環境の Tunnel1 / Tunnel2 には ip tcp adjust-mss 1280 が設定されていました。これを両方のトンネルで 1000 に変更しました。

interface Tunnel1
 ip tcp adjust-mss 1000
interface Tunnel2
 ip tcp adjust-mss 1000

curl、ブラウザー、Secure Access のログで復旧を確認

変更後、curl で HEAD の応答を確認しました。

curl.exe -I --http1.1 --max-time 10 http://www.google.com/

今度は HTTP/1.1 200 OK の応答を受信し、応答ヘッダーには Secure Access のプロキシを経由したことを示す Via ヘッダーも含まれていました（プロキシ名は記載を省略）。あわせて、ブラウザーで Google と ChatGPT が正常に表示され、Secure Access の Activity Search にも両サービスの Web 通信が記録されました。

このように、端末側（curl とブラウザー）と Secure Access 側（Activity Search）の両方で復旧を確認しました。今回の環境では、MSS を 1280 から 1000 に変更した後に通信が復旧した、と説明できます。

MSS 1000 を推奨値としない理由

Cisco の公式資料「Network Tunnel Groups」の「TCP MSS (Maximum Segment Size) Clamping」では、Secure Access 側で TCP MSS を 1350 バイトにクランプすると説明されており、接続する機器側の MSS クランプは無効にするか、1350 に合わせることが推奨されています。公式の値と今回のラボの値は次のとおりです。

MSS 1000 は、障害の切り分けの中で試した値です。次の点は確認できていません。

• 実際にパケットが欠落した機器・通信区間
• PMTUD や IPsec のカプセル化との具体的な因果関係
• MSS を 1000 からどこまで大きくしても問題が起きないか
• この環境での最適な MSS の値
• MSS 変更後のスループットや性能への影響
• 長期間の安定性と、フェイルオーバー時の動作

したがって、今回の結果から言えるのは「MSS を小さくすると正常化したため、パケットサイズに関連する問題が疑われる」という範囲までです。MTU が原因だった、MSS 1280 が不正だった、Secure Access に不具合があった、とは断定できません。MTU と MSS の基本的な関係は『MTU/MSS とは｜PPPoE・IPsec で通信が止まる原因と対策』で解説しています。

同様の障害が起きた場合の確認ポイント

今回の事例から、確認の順序と判断の根拠を整理します。唯一の正しい手順ではありませんが、どの結果を根拠に次へ進むかの目安になります。

今回の事例から整理した確認フロー

誤解しやすい判断

MTU / MSS を変更する前後に確認すること

• 変更する値を、Cisco の公式資料の値（内部 MTU 1390 バイト以下、MSS 1350）と比較し、公式の値と異なる値を使う理由を記録する
• Tunnel1 / Tunnel2 の両方に同じ変更を入れ、冗長構成の片側だけ設定が異なる状態を避ける
• 公式資料の「Path MTU Detection」では、PMTUD のために Secure Access からローカルネットワークへの ICMP Fragmentation Needed を通過させることが求められているため、経路上のフィルターを確認する（今回のラボでは未確認）
• 変更前後で、同じ curl コマンドと同じ Secure Access のログ項目を比較し、切り戻しのコマンドも事前に用意する

まとめ

IPsec / BGP のセッションが確立し、TCP 接続にも成功していても、Secure Access 経由の HTTP / HTTPS がタイムアウトすることがあります。今回の検証では、各段階を一つずつ確認し、TCP の欠番と SACK を手がかりに MSS を調整した結果、通信が復旧しましたが、欠落が起きた箇所は特定できていません。

• SSE 側の HTTP 200 と端末の受信結果を照合すると、戻り方向の問題に気づけます。
• Tunnel MTU を 1390 に変更しただけでは改善しませんでした。
• MSS を 1280 から 1000 に下げた後、端末側と SSE 側の両方で復旧を確認しました。
• MSS 1000 は切り分けで試した値で、推奨値ではありません。

以上、最後までお読みいただきありがとうございました。