ネットワークの問題をトラブルシューティングするためのFirepowerファイアウォールキャプチャの分析
内容
はじめに
このドキュメントでは、ネットワークの問題を効果的にトラブルシューティングするための、さまざまなパケットキャプチャ分析手法について説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- Firepower プラットフォーム アーキテクチャ
- NGFW ログ
- NGFW パケットトレーサ
さらに、パケットキャプチャの分析を開始する前に、次の要件を満たすことを強くお勧めします。
- プロトコルの動作を把握する：キャプチャされたプロトコルの動作を理解できない場合は、パケットキャプチャのチェックを開始しないでください。
- トポロジを把握する：中継デバイスをエンドツーエンドで把握する必要があります。これが不可能な場合は、少なくともアップストリームデバイスとダウンストリームデバイスを知っている必要があります。
- アプライアンスの把握：デバイスでのパケットの処理方法、関連するインターフェイス（入力/出力）、デバイスアーキテクチャ、さまざまなキャプチャポイントを把握しておく必要があります。
- 設定の理解：デバイスによってパケットフローが処理される方法を、次の観点から理解している必要があります。
- ルーティング/出力インターフェイス
- 適用されているポリシー
- ネットワーク アドレス変換（NAT）
- 使用可能なツールを把握する：キャプチャに加えて、他のツールや手法（ロギングやトレーサなど）を適用する準備を整え、必要に応じてキャプチャされたパケットと関連付けることを推奨します。
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- FTD ソフトウェア 6.5.x を実行している FP4140（ほとんどのシナリオがこれに基づいています）
- FTD ソフトウェア 6.5.x を実行している FMC
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
背景説明
パケットキャプチャは、現在利用可能なトラブルシューティング ツールのなかで最も見過ごされているものの一つです。Cisco TACは、キャプチャされたデータの分析を通じて、多くの問題を解決します。
このドキュメントの目的は、ネットワークエンジニアとセキュリティエンジニアが、主にパケットキャプチャ分析に基づいて一般的なネットワークの問題を特定し、トラブルシューティングできるようにすることです。
このドキュメントに示されているすべてのシナリオは、Cisco Technical Assistance Center（TAC）で確認された実際のユーザーの事例に基づいています。
このドキュメントでは、シスコ次世代ファイアウォール（NGFW）の観点でのパケットキャプチャについて説明していますが、同じ概念が他のデバイスタイプにも適用されます。
NGFW 製品ファミリでキャプチャを収集およびエクスポートする方法
Firepower アプライアンス（1xxx、21xx、41xx、93xx）と Firepower Threat Defense（FTD）アプリケーションを使用している場合、パケット処理を図示すると次のようになります。
- パケットが入力インターフェイスに入り、シャーシの内部スイッチによって処理されます。
- パケットが、主に L3/L4 チェックを行う FTD LINA エンジンに入ります。
- ポリシーで要求される場合、パケットが Snort エンジンによって検査されます（主に L7 検査）。
- Snort エンジンがパケットに対する判定を返します。
- LINA エンジンは、Snort の判定に基づいてパケットをドロップまたは転送する.
- パケットがシャーシの内部スイッチを通過してシャーシから出ます。
示されているアーキテクチャに基づいて、FTDキャプチャは3つの異なる場所で取得できます。
- FXOS
- FTD LINA エンジン
- FTD Snort エンジン
FXOS キャプチャの収集
このプロセスについては、次のドキュメントで説明されています。
次の図のように、FXOS キャプチャは、内部スイッチの観点から入力方向でのみ取得できます。
次の図では、方向ごとに2つのキャプチャポイントが示されています（内部スイッチアーキテクチャによる）。
ポイント 2、3、および 4 でキャプチャされるパケットは、仮想ネットワークタグ（VNTag）を持ちます。
FTD LINA キャプチャの有効化および収集
主なキャプチャポイントは、次のとおりです。
- 入力インターフェイス
- 出力インターフェイス
- 高速セキュリティパス（ASP）
Firepower Management Center ユーザーインターフェイス（FMC UI）または FTD CLI のいずれかを使用して、FTD LINA キャプチャを有効にして収集することができます。
CLI から INSIDE インターフェイスでのキャプチャを有効にします。
firepower# capture CAPI interface INSIDE match icmp host 192.168.103.1 host 192.168.101.1
このキャプチャは、IP 192.168.103.1 と 192.168.101.1 の間のトラフィックを双方向で照合します。
ASP キャプチャを有効にして、FTD LINA エンジンによってドロップされたすべてのパケットを表示します。
firepower# capture ASP type asp-drop all
FTD LINA キャプチャを FTP サーバーにエクスポートします。
firepower# copy /pcap capture:CAPI ftp://ftp_username:ftp_password@192.168.78.73/CAPI.pcap
FTD LINA キャプチャを TFTP サーバーにエクスポートします。
firepower# copy /pcap capture:CAPI tftp://192.168.78.73
FMC バージョン 6.2.x 以降では、FMC UI から FTD LINA キャプチャを有効にして収集することができます。
FMC 管理対象ファイアウォールから FTD キャプチャを収集するもう一つの方法は、次のとおりです。
手順 1
LINAまたはASPキャプチャの場合は、キャプチャをFTDディスクにコピーします。
firepower# copy /pcap capture:capin disk0:capin.pcap Source capture name [capin]? Destination filename [capin.pcap]? !!!!
手順 2
エキスパートモードに移行し、保存されたキャプチャを見つけて、それを /ngfw/var/common にコピーします。
firepower# Console connection detached. > expert admin@firepower:~$ sudo su Password: root@firepower:/home/admin# cd /mnt/disk0 root@firepower:/mnt/disk0# ls -al | grep pcap -rwxr-xr-x 1 root root 24 Apr 26 18:19 CAPI.pcap -rwxr-xr-x 1 root root 30110 Apr 8 14:10 capin.pcap -rwxr-xr-x 1 root root 6123 Apr 8 14:11 capin2.pcap root@firepower:/mnt/disk0# cp capin.pcap /ngfw/var/common
手順 3
FTD を管理している FMC にログインし、[デバイス（Devices）] > [デバイス管理（Device Management）] に移動します。FTD デバイスを見つけて、トラブルシューティングのアイコンを選択します。
手順 4
[高度なトラブルシューティング（Advanced Troubleshooting）] を選択します。
キャプチャファイル名を指定し、[ダウンロード（Download）] を選択します。
FMC UI からキャプチャを有効化/収集する方法の他の例については、次のドキュメントを参照してください。
FTD Snort キャプチャの有効化および収集
次の図にキャプチャポイントが示されています。
Snort レベルのキャプチャを有効にします。
> capture-traffic Please choose domain to capture traffic from: 0 - br1 1 - Router Selection? 1 Please specify tcpdump options desired. (or enter '?' for a list of supported options) Options: -n host 192.168.101.1
キャプチャを capture.pcap という名前のファイルに書き込み、FTP 経由でリモートサーバーにコピーするには、次の手順に従います。
> capture-traffic Please choose domain to capture traffic from: 0 - br1 1 - Router Selection? 1 Please specify tcpdump options desired. (or enter '?' for a list of supported options) Options: -w capture.pcap host 192.168.101.1 CTRL + C <- to stop the capture
> file copy 10.229.22.136 ftp / capture.pcap Enter password for ftp@10.229.22.136: Copying capture.pcap Copy successful. >
さまざまなキャプチャフィルタを含む Snort レベルのキャプチャの例については、次のドキュメントを参照してください。
トラブルシュート
Case 1.出力インターフェイスにTCP SYNなし
このトポロジは、次のとおりです。
問題の説明：HTTPが機能しない
影響を受けるフロー：
送信元IP:192.168.0.100
宛先IP:10.10.1.100
プロトコル：TCP 80
キャプチャ分析
FTD LINA エンジンでのキャプチャを有効にします。
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
キャプチャ - 機能シナリオ：
機能シナリオのキャプチャを持っておくことは、基準として常に非常に役立ちます。
次の図は、NGFW の INSIDE インターフェイスで取得されたキャプチャを示しています。
キー ポイント：
- TCP 3 ウェイハンドシェイクです。
- 双方向のデータ交換です。
- パケット間の遅延なし（パケット間の時間差に基づく）
- 送信元 MAC は正しいダウンストリームデバイスです。
次の図は、NGFW の OUTSIDE インターフェイスで取得されたキャプチャを示しています。
キー ポイント：
- CAPI キャプチャと同じデータです。
- 宛先 MAC は正しいアップストリームデバイスです。
キャプチャ - 非機能シナリオ：
デバイス CLI では、キャプチャは次のように示されます。
firepower# show capture capture CAPI type raw-data interface INSIDE [Capturing - 484 bytes] match ip host 192.168.0.100 host 10.10.1.100 capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes] match ip host 192.168.0.100 host 10.10.1.100
CAPI の内容：
firepower# show capture CAPI 6 packets captured 1: 11:47:46.911482 192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 2: 11:47:47.161902 192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 3: 11:47:49.907683 192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 4: 11:47:50.162757 192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 5: 11:47:55.914640 192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,nop,sackOK> 6: 11:47:56.164710 192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,nop,sackOK>
firepower# show capture CAPO 0 packet captured 0 packet shown
次の図は、Wireshark での CAPI キャプチャを示しています。
キー ポイント：
- TCP SYN パケットのみが表示されています（TCP 3 ウェイハンドシェイクは表示されていません）。
- 確立できない 2 つの TCP セッション（送信元ポート 3171 および 3172）があります。送信元クライアントが TCP SYN パケットを再送信します。これらの再送信されたパケットは、Wireshark によって TCP 再送信として識別されます。
- TCPの再送信は、～3秒から6秒の間隔で発生します。
- 送信元 MAC アドレスは正しいダウンストリームデバイスのものです。
2 つのキャプチャに基づいて、次のことが結論付けられます。
- 特定の 5 タプル（src/dst IP、src/dst ポート、プロトコル）のパケットが、予期されたインターフェイス（INSIDE）のファイアウォールに到着しています。
- パケットは、予期されたインターフェイス（OUTSIDE）でファイアウォールを出ていません。
推奨される対処法
このセクションに示されているアクションは、問題を絞り込むことを目的としています。
アクション1:エミュレートされたパケットのトレースを確認します。
パケットトレーサツールを使用して、ファイアウォールでのパケットの予期される処理方法を確認します。パケットがファイアウォール アクセス ポリシーによってドロップされた場合、エミュレートされたパケットのトレースの出力は、次のようなものになります。
firepower# packet-tracer input INSIDE tcp 192.168.0.100 11111 10.10.1.100 80 Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Phase: 4 Type: ACCESS-LIST Subtype: log Result: DROP Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268439946 event-log flow-start access-list CSM_FW_ACL_ remark rule-id 268439946: ACCESS POLICY: FTD_Policy - Default access-list CSM_FW_ACL_ remark rule-id 268439946: L4 RULE: DEFAULT ACTION RULE Additional Information: Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x00005647a4f4b120 flow (NA)/NA
アクション2:ライブパケットのトレースを確認します。
パケットトレースを有効にして、実際の TCP SYN パケットがファイアウォールによってどのように処理されたかを確認します。デフォルトでは、最初の 50 の入力パケットのみがトレースされます。
firepower# capture CAPI trace
キャプチャバッファをクリアします。
firepower# clear capture /all
パケットがファイアウォール アクセス ポリシーによってドロップされた場合、トレースの出力は、次のようなものになります。
firepower# show capture CAPI packet-number 1 trace 6 packets captured 1: 12:45:36.279740 192.168.0.100.3630 > 10.10.1.100.80: S 2322685377:2322685377(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Phase: 4 Type: ACCESS-LIST Subtype: log Result: DROP Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268439946 event-log flow-start access-list CSM_FW_ACL_ remark rule-id 268439946: ACCESS POLICY: FTD_Policy - Default access-list CSM_FW_ACL_ remark rule-id 268439946: L4 RULE: DEFAULT ACTION RULE Additional Information: Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x00005647a4f4b120 flow (NA)/NA 1 packet shown
アクション3:FTD Linaログを確認します。
FMC を介して FTD の Syslog を設定する方法については、次のドキュメントを参照してください。
FTD LINA ログ用に外部 Syslog サーバーを設定することを強くお勧めします。リモート Syslog サーバーが設定されていない場合は、トラブルシューティング中にファイアウォールでローカルバッファログを有効にします。この例に示されているログ設定は、設定を行うための優れた出発点となります。
firepower# show run logging … logging enable logging timestamp logging buffer-size 1000000 logging buffered informational
端末ページャを制御するには、端末ページャを 24 行に設定します。
firepower# terminal pager 24
キャプチャバッファをクリアします。
firepower# clear logging buffer
接続をテストし、パーサーフィルタを使用してログを確認します。この例では、パケットは、ファイアウォール アクセス ポリシーによってドロップされています。
firepower# show logging | include 10.10.1.100 Oct 09 2019 12:55:51: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3696 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0] Oct 09 2019 12:55:51: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3697 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0] Oct 09 2019 12:55:54: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3696 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0] Oct 09 2019 12:55:54: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3697 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]
アクション4:ファイアウォールのASPドロップを確認します。
パケットがファイアウォールによってドロップされていると思われる場合は、ファイアウォールによってドロップされたすべてのパケットの数をソフトウェアレベルで確認できます。
firepower# show asp drop Frame drop: No route to host (no-route) 234 Flow is denied by configured rule (acl-drop) 71 Last clearing: 07:51:52 UTC Oct 10 2019 by enable_15 Flow drop: Last clearing: 07:51:52 UTC Oct 10 2019 by enable_15
キャプチャを有効にして、すべての ASP ソフトウェアレベルのドロップを確認できます。
firepower# capture ASP type asp-drop all buffer 33554432 headers-only
キャプチャの内容を確認する場合、フィルタを使用して検索を絞り込むことができます。
firepower# show capture ASP | include 10.10.1.100 18: 07:51:57.823672 192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 19: 07:51:58.074291 192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 26: 07:52:00.830370 192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 29: 07:52:01.080394 192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 45: 07:52:06.824282 192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,nop,sackOK> 46: 07:52:07.074230 192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,nop,sackOK>
この場合、パケットはすでにインターフェイスレベルでトレースされているため、ドロップの理由は ASP キャプチャに示されていません。パケットは 1 つの場所（入力インターフェイスまたは ASP ドロップ）でしかトレースできないことに注意してください。その場合は、複数の ASP ドロップを取得し、特定の ASP ドロップ理由を設定することをお勧めします。推奨されるアプローチを次に示します。
1. 現在の ASP ドロップカウンタをクリアします。
firepower# clear asp drop
2. トラブルシューティングするフローを、ファイアウォールを介して送信します（テストを実行します）。
3. ASPドロップカウンタをもう一度確認し、増加したカウンタをメモします。
firepower# show asp drop Frame drop: No route to host (no-route) 234 Flow is denied by configured rule (acl-drop) 71
4. 確認した特定のドロップの ASP キャプチャを有効にします。
firepower# capture ASP_NO_ROUTE type asp-drop no-route firepower# capture ASP_ACL_DROP type asp-drop acl-drop
5. トラブルシューティングするフローを、ファイアウォールを介して送信します（テストを実行します）。
6. ASP キャプチャを確認します。この場合、ルートがないためにパケットがドロップされています。
firepower# show capture ASP_NO_ROUTE | include 192.168.0.100.*10.10.1.100 93: 07:53:52.381663 192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 95: 07:53:52.632337 192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 101: 07:53:55.375392 192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 102: 07:53:55.626386 192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 116: 07:54:01.376231 192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,nop,sackOK> 117: 07:54:01.626310 192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,nop,sackOK>
アクション5:FTD回線の接続テーブルをチェックします。
インターフェイス「X」から出ると予期されているパケットが、何らかの理由でインターフェイス「Y」から出る場合があります。ファイアウォールの出力インターフェイスは、次の動作順序に基づいて決定されます。
- 確立された接続のルックアップ
- ネットワークアドレス変換（NAT）のルックアップ（UN-NAT（宛先 NAT）フェーズは、PBR およびルートのルックアップよりも優先されます）
- ポリシーベース ルーティング（PBR）
- ルーティングテーブルのルックアップ
FTD 接続テーブルを確認するには、次の手順に従います。
firepower# show conn
2 in use, 4 most used
Inspect Snort:
preserve-connection: 2 enabled, 0 in effect, 4 most enabled, 0 most in effect
TCP DMZ 10.10.1.100:80 INSIDE 192.168.0.100:11694, idle 0:00:01, bytes 0, flags aA N1
TCP DMZ 10.10.1.100:80 INSIDE 192.168.0.100:11693, idle 0:00:01, bytes 0, flags aA N1
キー ポイント：
- フラグ（Aa）により、接続が初期状態（ハーフオープン：TCP SYN のみがファイアウォールによって認識されている）であることが分かります。
- 送信元/宛先ポートにより、入力インターフェイスが INSIDE であり、出力インターフェイスが DMZ であることが分かります。
これは、次のように図示されます。
firepower# show interface detail | i Interface number is|Interface [P|E].*is up
...
Interface Ethernet1/2 "INSIDE", is up, line protocol is up
Interface number is 19
Interface Ethernet1/3.202 "OUTSIDE", is up, line protocol is up
Interface number is 20
Interface Ethernet1/3.203 "DMZ", is up, line protocol is up
Interface number is 22
出力 1:
firepower# show conn long ... TCP OUTSIDE: 192.168.2.200/80 (192.168.2.200/80) INSIDE: 192.168.1.100/46050 (192.168.1.100/46050), flags aA N1, idle 3s, uptime 6s, timeout 30s, bytes 0 Initiator: 192.168.1.100, Responder: 192.168.2.200 Connection lookup keyid: 228982375
出力 2:
firepower# show conn detail
...
TCP OUTSIDE: 192.168.2.200/80 INSIDE: 192.168.1.100/46050,
flags aA N1, idle 4s, uptime 11s, timeout 30s, bytes 0
Initiator: 192.168.1.100, Responder: 192.168.2.200
Connection lookup keyid: 228982375
さらに、ネットワークアドレス変換の場合は、show conn long により、カッコ内に NAT 化された IP が表示されます。
firepower# show conn long ... TCP OUTSIDE: 192.168.2.222/80 (192.168.2.222/80) INSIDE: 192.168.1.100/34792 (192.168.2.150/34792), flags aA N1, idle 0s, uptime 0s, timeout 30s, bytes 0, xlate id 0x2b5a8a4314c0 Initiator: 192.168.1.100, Responder: 192.168.2.222 Connection lookup keyid: 262895
アクション6:ファイアウォールのアドレス解決プロトコル(ARP)キャッシュをチェックします。
ファイアウォールがネクストホップを解決できない場合、そのファイアウォールは、元のパケット（この場合は TCP SYN）をサイレントにドロップし、ネクストホップを解決するまで ARP 要求を継続的に送信します。
ファイアウォール ARP キャッシュを表示するには、次のコマンドを使用します。
firepower# show arp
さらに、未解決のホストがあるかどうかを確認するには、次のコマンドを使用します。
firepower# show arp statistics
Number of ARP entries in ASA: 0
Dropped blocks in ARP: 84
Maximum Queued blocks: 3
Queued blocks: 0
Interface collision ARPs Received: 0
ARP-defense Gratuitous ARPS sent: 0
Total ARP retries: 182 < indicates a possible issue for some hosts
Unresolved hosts: 1 < this is the current status
Maximum Unresolved hosts: 2
ARP の動作をさらに確認する場合は、ARP 固有のキャプチャを有効にすることができます。
firepower# capture ARP ethernet-type arp interface OUTSIDE firepower# show capture ARP ... 4: 07:15:16.877914 802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50 5: 07:15:18.020033 802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50
この出力では、ファイアウォール（192.168.2.50）がネクストホップ（192.168.2.72）の解決を試みていますが、ARP 応答はありません。
次の出力は、適切な ARP 解決が発生した機能シナリオを示しています。
firepower# show capture ARP 2 packets captured 1: 07:17:19.495595 802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50 2: 07:17:19.495946 802.1Q vlan#202 P0 arp reply 192.168.2.72 is-at 4c:4e:35:fc:fc:d8 2 packets shown
firepower# show arp
INSIDE 192.168.1.71 4c4e.35fc.fcd8 9
OUTSIDE 192.168.2.72 4c4e.35fc.fcd8 9
適切な ARP エントリがない場合、ライブ TCP SYN パケットのトレースは次のようになります。
firepower# show capture CAPI packet-number 1 trace 6 packets captured 1: 07:03:43.270585 192.168.0.100.11997 > 10.10.1.100.80: S 4023707145:4023707145(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE … Phase: 14 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 4814, packet dispatched to next module … Phase: 17 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: allow
出力からわかるように、ネクストホップに到達できず、パケットがファイアウォールによって通知なしに廃棄された場合でも、トレースにはAction: allowと表示されます。この場合、より正確な出力が提供されるパケットトレーサツールも確認する必要があります。
firepower# packet-tracer input INSIDE tcp 192.168.0.100 1111 10.10.1.100 80 Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE … Phase: 14 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 4816, packet dispatched to next module … Phase: 17 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (no-v4-adjacency) No valid V4 adjacency, Drop-location: frame 0x00005647a4e86109 flow (NA)/NA
最近のASA/Firepowerバージョンでは、以前のメッセージは次の目的に最適化されています。
Drop-reason: (no-v4-adjacency) No valid V4 adjacency. Check ARP table (show arp) has entry for nexthop., Drop-location: f
考えられる原因と推奨されるアクションの概要
TCP SYN パケットが入力インターフェイスにしか表示されず、予期される出力インターフェイスから TCP SYN パケットが送信されない場合、考えられる原因は次のとおりです。
| 考えられる原因 |
推奨される対処法 |
| パケットがファイアウォール アクセス ポリシーによってドロップされています。 |
|
| キャプチャフィルタが適切ではありません。 |
|
| パケットが別の出力インターフェイスに送信されています。 |
パケットが現在の接続に一致するために誤ったインターフェイスに送信される場合は、clear conn addressコマンドを使用して、クリアする接続の5タプルを指定します。 |
| 宛先へのルートが存在しません。 |
|
| 出力インターフェイスに ARP エントリがありません。 |
|
| 出力インターフェイスがダウンしています。 |
ファイアウォールに関する show interface ip brief コマンドの出力を調べて、インターフェイスのステータスを確認します。 |
Case 2.クライアントからのTCP SYN、サーバからのTCP RST
次の図は、このトポロジを示しています。
問題の説明：HTTPが機能しない
影響を受けるフロー：
送信元IP:192.168.0.100
宛先IP:10.10.1.100
プロトコル：TCP 80
キャプチャ分析
FTD LINA エンジンでのキャプチャを有効にします。
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
キャプチャ - 非機能シナリオ：
デバイスCLIからのキャプチャは次のようになります。
firepower# show capture capture CAPI type raw-data trace interface INSIDE [Capturing - 834 bytes] match ip host 192.168.0.100 host 10.10.1.100 capture CAPO type raw-data interface OUTSIDE [Capturing - 878 bytes] match ip host 192.168.0.100 host 10.10.1.100
CAPI の内容：
firepower# show capture CAPI 1: 05:20:36.654217 192.168.0.100.22195 > 10.10.1.100.80: S 1397289928:1397289928(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 2: 05:20:36.904311 192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 3: 05:20:36.905043 10.10.1.100.80 > 192.168.0.100.22196: R 1850052503:1850052503(0) ack 2171673259 win 0 4: 05:20:37.414132 192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 5: 05:20:37.414803 10.10.1.100.80 > 192.168.0.100.22196: R 31997177:31997177(0) ack 2171673259 win 0 6: 05:20:37.914183 192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,nop,sackOK> ...
CAPO の内容：
firepower# show capture CAPO 1: 05:20:36.654507 802.1Q vlan#202 P0 192.168.0.100.22195 > 10.10.1.100.80: S 2866789268:2866789268(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 2: 05:20:36.904478 802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4785344:4785344(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 3: 05:20:36.904997 802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4785345 win 0 4: 05:20:37.414269 802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4235354730:4235354730(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 5: 05:20:37.414758 802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4235354731 win 0 6: 05:20:37.914305 802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4118617832:4118617832(0) win 8192 <mss 1380,nop,nop,sackOK>
次の図は、Wireshark での CAPI のキャプチャを示しています。
キー ポイント：
- 送信元が TCP SYN パケットを送信しています。
- TCP RST が送信元に向けて送信されています。
- 送信元が TCP SYN パケットを再送信しています。
- MAC アドレスは適切です（入力パケットでは、送信元 MAC アドレスがダウンストリームルータに属し、宛先 MAC アドレスがファイアウォールの INSIDE インターフェイスに属しています）。
次の図は、Wireshark での CAPO のキャプチャを示しています。
キー ポイント：
- 送信元が TCP SYN パケットを送信しています。
- TCP RST が OUTSIDE インターフェイスに到着しています。
- 送信元が TCP SYN パケットを再送信しています。
- MAC アドレスは適切です（出力パケットでは、ファイアウォールの OUTSIDE が送信元 MAC であり、アップストリームルータが宛先 MAC です）。
2 つのキャプチャに基づいて、次のことが結論付けられます。
- クライアントとサーバー間の TCP 3 ウェイハンドシェイクが完了していません。
- ファイアウォールの出力インターフェイスに到着する TCP RST が存在します。
- ファイアウォールは、MAC アドレスに基づいて適切なアップストリームおよびダウンストリームデバイスと「対話」しています。
推奨される対処法
このセクションに示されているアクションは、問題を絞り込むことを目的としています。
アクション1:TCP RSTを送信する送信元MACアドレスをチェックします。
TCP SYN パケットに見られる宛先 MAC が、TCP RST パケットに見られる送信元 MAC と同じであることを確認します。
この確認は、次の 2 つのことの確認が目的です。
- 非対称フローが存在しないことを確認します。
- MAC が予期されるアップストリームデバイスに属していることを確認します。
アクション2:入力パケットと出力パケットを比較します。
Wireshark 上の 2 つのパケットを視覚的に比較して、ファイアウォールがパケットを変更したり、破損させたりしていないことを確認します。いくつかの予期される相違点が強調表示されています。
キー ポイント：
- タイムスタンプが異なっています。そのこと自体は問題ありませんが、その差は小さく、妥当な範囲である必要があります。これは、パケットに適用される機能およびポリシーチェックと、デバイスの負荷によって異なります。
- パケットの長さは、特にdot1Qヘッダーが片側だけでファイアウォールによって追加/削除される場合に異なります。
- MAC アドレスが異なっています。
- キャプチャがサブインターフェイスで取得された場合は、dot1Q ヘッダーがある可能性があります。
- NAT またはポートアドレス変換（PAT）がパケットに適用されている場合、IP アドレスが異なります。
- NAT または PAT がパケットに適用されている場合、送信元ポートまたは宛先ポートが異なります。
- Wireshark の [相対シーケンス番号（Relative Sequence Number）] オプションを無効にすると、初期シーケンス番号（ISN）のランダム化により、ファイアウォールによって TCP シーケンス番号/確認応答番号が変更されていることが分かります。
- 一部のTCPオプションは上書きできます。たとえば、ファイアウォールは、中継パスでのパケットのフラグメント化を避けるために、デフォルトで TCP 最大セグメントサイズ（MSS）を 1380 に変更します。
アクション3:目的地でキャプチャを取ります。
可能であれば、宛先自体でキャプチャを取得します。不可能な場合は、宛先のできるだけ近くでキャプチャを取得します。目的は、TCP RST の送信元（宛先サーバーか、パス内の他のデバイスか）を確認することです。
Case 3.1つのエンドポイントからのTCP 3ウェイハンドシェイク+ RST
次の図は、このトポロジを示しています。
問題の説明：HTTPが機能しない
影響を受けるフロー：
送信元IP:192.168.0.100
宛先IP:10.10.1.100
プロトコル：TCP 80
キャプチャ分析
FTD LINA エンジンでのキャプチャを有効にします。
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
キャプチャ - 非機能シナリオ：
この問題は、いくつかの異なる形でキャプチャに現れます。
3.1：クライアントからの TCP 3 ウェイハンドシェイク + 遅延 RST
次の図のように、ファイアウォールキャプチャの CAPI と CAPO の両方に同じパケットが含まれています。
キー ポイント：
- TCP 3 ウェイハンドシェイクがファイアウォールを通過しています。
- サーバーが SYN/ACK を再送信しています。
- クライアントが ACK を再送信しています。
- 約 20 秒後、クライアントは中断して TCP RST を送信しています。
推奨される対処法
このセクションに示されているアクションは、問題を絞り込むことを目的としています。
アクション1:2つのエンドポイントにできるだけ近い場所からキャプチャを取得します。
ファイアウォールキャプチャは、クライアント ACK がサーバーによって処理されなかったことを示しています。これは、次の事実に基づいています。
- サーバーが SYN/ACK を再送信しています。
- クライアントが ACK を再送信しています。
- クライアントが、データの前に TCP RST または FIN/ACK を送信しています。
サーバーでのキャプチャは、問題の発生を示しています。TCP 3 ウェイハンドシェイクからのクライアント ACK が到着していません。
3.2：クライアントからの TCP 3 ウェイハンドシェイク + 遅延 FIN/ACK + サーバーからの遅延 RST
次の図のように、ファイアウォールキャプチャの CAPI と CAPO の両方に同じパケットが含まれています。
キー ポイント：
- TCP 3 ウェイハンドシェイクがファイアウォールを通過しています。
- 約 5 秒後、クライアントが FIN/ACK を送信しています。
- 約 20 秒後、サーバーは中断して TCP RST を送信しています。
このキャプチャに基づいて、ファイアウォールを通過した TCP 3 ウェイハンドシェイクが存在するものの 1 つのエンドポイントで実際に完了していないように見えると結論付けることができます（再送信がこれを示しています）。
推奨される対処法
ケース 3.1 と同じです。
3.3：クライアントからの TCP 3 ウェイハンドシェイク + 遅延 RST
次の図のように、ファイアウォールキャプチャの CAPI と CAPO の両方に同じパケットが含まれています。
キー ポイント：
- TCP 3 ウェイハンドシェイクがファイアウォールを通過しています。
- 約 20 秒後、クライアントは中断して TCP RST を送信しています。
これらのキャプチャに基づいて、次のことが結論付けられます。
- 5 ～ 20 秒後に、1 つのエンドポイントが中断し、接続を終了することを決定しています。
推奨される対処法
ケース 3.1 と同じです。
3.4：サーバーからの TCP 3 ウェイハンドシェイク + 即時 RST
次の図のように、ファイアウォールキャプチャの CAPI と CAPO の両方にこれらのパケットが含まれています。
キー ポイント：
- TCP 3 ウェイハンドシェイクがファイアウォールを通過しています。
- ACK パケットの数ミリ秒後に、サーバーからの TCP RST が存在しています。
推奨される対処法
処置：可能な限りサーバの近くでキャプチャを実行します。
サーバーからの即時の TCP RST は、TCP RST を送信するパス内のサーバーまたはデバイスの誤動作を示している可能性があります。サーバー自体でキャプチャを取得し、TCP RST の送信元を特定します。
ケース 4.クライアントからのTCP RST
次の図は、このトポロジを示しています。
問題の説明：HTTP が機能しない
影響を受けるフロー：
送信元IP:192.168.0.100
宛先IP:10.10.1.100
プロトコル：TCP 80
キャプチャ分析
FTD LINA エンジンでのキャプチャを有効にします。
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
キャプチャ - 非機能シナリオ：
CAPI の内容は、次のとおりです。
firepower# show capture CAPI 14 packets captured 1: 12:32:22.860627 192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 2: 12:32:23.111307 192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 3: 12:32:23.112390 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 4: 12:32:25.858109 192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 5: 12:32:25.868698 192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0 6: 12:32:26.108118 192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 7: 12:32:26.109079 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 8: 12:32:26.118295 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 9: 12:32:31.859925 192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,nop,sackOK> 10: 12:32:31.860902 192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0 11: 12:32:31.875229 192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0 12: 12:32:32.140632 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 13: 12:32:32.159995 192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,nop,sackOK> 14: 12:32:32.160956 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 14 packets shown
CAPO の内容は、次のとおりです。
firepower# show capture CAPO 11 packets captured 1: 12:32:22.860780 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 2: 12:32:23.111429 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3000518857:3000518857(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 3: 12:32:23.112405 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 3514091874:3514091874(0) win 0 4: 12:32:25.858125 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 5: 12:32:25.868729 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 2968892337:2968892337(0) win 0 6: 12:32:26.108240 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3822259745:3822259745(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 7: 12:32:26.109094 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 40865466:40865466(0) win 0 8: 12:32:31.860062 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 4294058752:4294058752(0) win 8192 <mss 1380,nop,nop,sackOK> 9: 12:32:31.860917 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 1581733941:1581733941(0) win 0 10: 12:32:32.160102 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 4284301197:4284301197(0) win 8192 <mss 1380,nop,nop,sackOK> 11: 12:32:32.160971 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 502906918:502906918(0) win 0 11 packets shown
ファイアウォールログは、次のようになります。
firepower# show log | i 47741 Oct 13 2019 13:57:36: %FTD-6-302013: Built inbound TCP connection 4869 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80) Oct 13 2019 13:57:36: %FTD-6-302014: Teardown TCP connection 4869 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE Oct 13 2019 13:57:39: %FTD-6-302013: Built inbound TCP connection 4870 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80) Oct 13 2019 13:57:39: %FTD-6-302014: Teardown TCP connection 4870 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE Oct 13 2019 13:57:45: %FTD-6-302013: Built inbound TCP connection 4871 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80) Oct 13 2019 13:57:45: %FTD-6-302014: Teardown TCP connection 4871 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE
これらのログは、ファイアウォールの INSIDE インターフェイスに到着する TCP RST が存在することを示しています。
Wireshark での CAPI キャプチャ：
次の図のように、最初の TCP ストリームを追跡します。
[Wireshark] で、[編集（Edit）] > [設定（Preferences）] > [プロトコル（Protocols）] > [TCP] に移動し、図のように、[相対シーケンス番号（Relative sequence numbers）] オプションをオフにします。
次の図は、CAPI キャプチャにおける最初のフローの内容を示しています。
キー ポイント：
- クライアントが TCP SYN パケットを送信しています。
- クライアントが TCP RST パケットを送信しています。
- TCP SYN パケットのシーケンス番号の値は 4098574664 です。
CAPO キャプチャの同じフローには、次のものが含まれます。
キー ポイント：
- クライアントが TCP SYN パケットを送信しています。ファイアウォールが ISN をランダム化しています。
- クライアントが TCP RST パケットを送信しています。
2 つのキャプチャに基づいて、次のことが結論付けられます。
- クライアントとサーバーの間に TCP 3 ウェイハンドシェイクは存在しません。
- クライアントから送信された TCP RST が存在します。CAPI キャプチャの TCP RST シーケンス番号の値は 1386249853 です。
推奨される対処法
このセクションに示されているアクションは、問題を絞り込むことを目的としています。
アクション1:クライアントでキャプチャを取得します。
ファイアウォールで収集されたキャプチャによると、非対称フローの強い兆候が存在します。これは、クライアントが 1386249853の値（ランダム化された ISN）で TCP RST を送信しているという事実に基づいています。
キー ポイント：
- クライアントが TCP SYN パケットを送信しています。シーケンス番号は 4098574664 であり、ファイアウォールの INSIDE インターフェイス（CAPI）で見られるものと同じです。
- ACK 番号が 1386249853 の TCP SYN/ACK が存在します（これは ISN のランダム化によって予期されるものです）。このパケットは、ファイアウォールキャプチャには表示されていません。
- クライアントは、ACK 番号の値が 4098574665 の SYN/ACK を予期していましたが、受信した値は 1386249853 であったため、TCP RST を送信しています。
それを図で示します。
アクション2:クライアントとファイアウォール間のルーティングを確認します。
次の項目を確認します。
- キャプチャに表示される MAC アドレスが、予期されたものである。
- ファイアウォールとクライアントの間のルーティングが対称である。
内部ネットワークに非対称ルーティングが存在するときにファイアウォールとクライアントの間にあるデバイスから RST が送信されるシナリオがあります。次の図は、その典型的なケースを示しています。
この場合、キャプチャの内容は、次のようになります。TCP SYN パケットの送信元 MAC アドレスと TCP RST の送信元 MAC アドレスおよび TCP SYN/ACK パケットの宛先 MAC アドレスの違いに注意してください。
firepower# show capture CAPI detail
1: 13:57:36.730217 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Length: 66
192.168.0.100.47740 > 10.10.1.100.80: S [tcp sum ok] 3045001876:3045001876(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 25661)
2: 13:57:36.981104 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Length: 66
192.168.0.100.47741 > 10.10.1.100.80: S [tcp sum ok] 3809380540:3809380540(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 25662)
3: 13:57:36.981776 00be.75f6.1dae a023.9f92.2a4d 0x0800 Length: 66
10.10.1.100.80 > 192.168.0.100.47741: S [tcp sum ok] 1304153587:1304153587(0) ack 3809380541 win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK> (DF) (ttl 127, id 23339)
4: 13:57:36.982126 a023.9f92.2a4d 00be.75f6.1dae 0x0800 Length: 54
192.168.0.100.47741 > 10.10.1.100.80: R [tcp sum ok] 3809380541:3809380541(0) ack 1304153588 win 8192 (ttl 255, id 48501)
...
ケース 5.遅いTCP転送（シナリオ1）
事象の説明:
ホスト 10.11.4.171 とホスト 10.77.19.11 の間の SFTP 転送が低速になっています。2 つのホスト間の最小帯域幅（BW）は 100 Mbps ですが、転送速度は 5 Mbps を超えていません。
一方で、ホスト 10.11.2.124 とホスト 172.25.18.134 の間の転送速度はかなり高速です。
背景理論:
単一の TCP フローの最大転送速度は、帯域幅遅延積（BDP）によって決定されます。次の図は、使用される式を示しています。
BDP の詳細については、次の資料を参照してください。
- 『Why Your Application only Uses 10Mbps Even the Link is 1Gbps?』
- BRKSEC-3021 - Advanced：『Maximizing Firewall Performance』
シナリオ 1.遅い転送
次の図は、このトポロジを示しています。
影響を受けるフロー：
送信元IP:10.11.4.171
宛先IP:10.77.19.11
プロトコル：SFTP(FTP over SSH)
キャプチャ分析
FTD LINA エンジンでのキャプチャを有効にします。
firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11 firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11
firepower# capture CAPI type raw-data trace interface inside match icmp any any WARNING: Running packet capture can have an adverse impact on performance.
推奨される対処法
このセクションに示されているアクションは、問題を絞り込むことを目的としています。
ラウンドトリップ時間（RTT）計算
まず、転送フローを特定し、それを追跡します。
Wireshark の [表示（View）] を変更して、[前に表示されたパケットからの秒数（Seconds Since the Previous Displayed Packet）] を表示します。これにより、RTT の計算が容易になります。
RTTは、2つのパケット交換（1つは送信元に向かうパケット交換で、もう1つは宛先に向かうパケット交換）の間の時間値の加算によって計算できます。今回の場合、パケット番号 2 は、ファイアウォールと SYN/ACK パケットを送信したデバイス（サーバー）の間の RTT を示しています。パケット番号 3 は、ファイアウォールと ACK パケットを送信したデバイス（クライアント）の間の RTT を示しています。2 つの数値を加算すると、エンドツーエンドの RTT に関する適切な概算値が得られます。
RTT ≒ 80 ミリ秒
TCP ウィンドウサイズの計算
TCP パケットを展開して、TCP ヘッダーを展開し、[計算されたウィンドウサイズ（Calculated window size）] を選択して、[列として適用（Apply as Column）] を選択します。
[計算されたウィンドウサイズ（Calculated window size）] 列の値を調べて、TCP セッション中の最大ウィンドウサイズ値を確認します。列名を選択して値をソートすることも可能です。
ファイルのダウンロード（サーバーからクライアントへ）をテストする場合は、サーバーによってアドバタイズされる値を確認する必要があります。サーバーによってアドバタイズされる最大ウィンドウサイズの値によって、達成される最大転送速度が決まります。
この場合、TCP ウィンドウサイズは約 50000 バイトです。
これらの値に基づき、帯域幅遅延積の式を使用すると、理論上の最大帯域幅50000*8/0.08 = 5 Mbpsという条件下で達成可能な理論上の最大帯域幅が得られます。
これは、今回のクライアントの状況と一致します。
TCP 3 ウェイハンドシェイクを詳しく確認します。両側（特に重要なのはサーバー）は、2^0 = 1（ウィンドウスケーリングなし）を意味する 0 のウィンドウスケール値をアドバタイズしています。これは、転送速度に悪影響を与えます。
この時点で、サーバ上でキャプチャを実行し、ウィンドウスケール= 0をアドバタイズしたサーバであることを確認し、再設定する必要があります（この方法については、サーバのマニュアルを参照してください）。
シナリオ 2.高速転送
次に、優れたシナリオ（同じネットワークを介した高速転送）について説明します。
トポロジ：
関連するフロー：
送信元IP:10.11.2.124
宛先IP:172.25.18.134
プロトコル：SFTP(FTP over SSH)
FTD LINA エンジンでのキャプチャを有効にします。
firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134 firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134
ラウンドトリップ時間(RTT)の計算：この場合、RTTは≈ 300ミリ秒です。
TCPウィンドウサイズの計算：サーバはTCPウィンドウスケール係数7をアドバタイズします。
サーバーの TCP ウィンドウサイズは約 1600000 バイトです。
これらの値に基づき、帯域幅遅延積の式は次のようになります。
1600000*8/0.3 = 43 Mbps の最大理論転送速度
Case 6.遅いTCP転送（シナリオ2）
問題の説明：ファイアウォール経由のFTPファイル転送（ダウンロード）が遅い。
次の図は、このトポロジを示しています。
影響を受けるフロー：
送信元IP:192.168.2.220
宛先IP:192.168.1.220
プロトコル：FTP
キャプチャ分析
FTD LINA エンジンでのキャプチャを有効にします。
firepower# capture CAPI type raw-data buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220 firepower# cap CAPO type raw-data buffer 33554432 interface OUTSIDE match tcp host 192.168.2.220 host 192.168.1.220
FTP-DATA パケットを選択し、FTD INSIDE キャプチャ（CAPI）の FTP データチャネルを追跡します。
FTP-DATA ストリームの内容：
CAPO キャプチャの内容：
キー ポイント：
- TCP Out-Of-Order（OOO）パケットが存在します。
- TCP 再送信が存在します。
- パケット損失（ドロップされたパケット）の兆候が存在します。
推奨される対処法
このセクションに示されているアクションは、問題を絞り込むことを目的としています。
アクション1:パケット損失の場所を特定します。
このような場合、同時にキャプチャを取得し、分割統治法を使用して、パケット損失の原因となっているネットワークセグメントを特定する必要があります。ファイアウォールの観点では、主なシナリオは次の 3 つです。
- パケット損失は、ファイアウォール自体が原因です。
- パケット損失がファイアウォールデバイスへのダウンストリーム（サーバーからクライアントへの方向）で発生しています。
- パケット損失がファイアウォールデバイスへのアップストリーム（クライアントからサーバーへの方向）で発生しています。
ファイアウォールによるパケット損失：パケット損失の原因がファイアウォールであるかどうかを特定するには、入力キャプチャと出力キャプチャを比較する必要があります。2 つの異なるキャプチャは、さまざまな方法で比較できます。このセクションでは、このタスクを実行する 1 つの方法を示します。
パケット損失を特定するために 2 つのキャプチャを比較する手順
ステップ 1：2つのキャプチャに同じ時間帯のパケットが含まれていることを確認します。言い換えると、これは、一方のキャプチャに、他方のキャプチャの前後でキャプチャされたパケットが存在していないということです。これは、いくつかの方法で実行できます。
- 最初と最後のパケットについて、その IP 識別子（ID）の値を確認します。
- 最初と最後のパケットについて、そのタイムスタンプの値を確認します。
この例では、各キャプチャの最初のパケットが持つ IP ID の値が同じであることを確認できます。
それらが同じでない場合は、次の手順を実行します。
- 各キャプチャの最初のパケットでタイムスタンプを比較します。
- 一番最後のタイムスタンプを持つキャプチャでフィルタを用意し、タイムスタンプフィルタを [==] から [>=]（最初のパケット）および [<=]（最後のパケット）に変更します。たとえば、次のようになります。
(frame.time >= "Oct 16, 2019 16:13:43.244692000") &&(frame.time <= "Oct 16, 2019 16:20:21.785130000")
3. 指定したパケットを新しいキャプチャにエクスポートします。[ファイル（File）] > [指定したパケットのエクスポート（Export Specified Packets）] を選択し、[表示された（Displayed）] パケットを保存してください。この時点で、両方のキャプチャに、同じ時間枠を対象とするパケットが含まれている必要があります。これで、2 つのキャプチャの比較を開始できます。
ステップ 2：2つのキャプチャ間の比較に使用するパケットフィールドを指定します。使用できるフィールドの例：
- IP ID
- RTP シーケンス番号
- ICMP シーケンス番号
ステップ1で指定した各パケットのフィールドを含む各キャプチャのテキストバージョンを作成します。これを行うには、対象の列のみを残します。たとえば、IP IDに基づいてパケットを比較する場合は、図に示すようにキャプチャを変更します。
結果は、次のとおりです。
ステップ 3：図に示すように、キャプチャのテキストバージョンを作成します(File > Export Packet Dissections > As Plain Text...)。
表示されたフィールドの値のみをエクスポートするには、図のように、[カラムヘッダーを含める（Include column headers）] オプションと [パケットの詳細（Packet details）] オプションをオフにします。
ステップ 4：ファイル内のパケットを並べ替えます。これを行うには、Linux の sort コマンドを使用します。
# sort CAPI_IDs > file1.sorted # sort CAPO_IDs > file2.sorted
ステップ 5：テキスト比較ツール（WinMergeなど）またはLinuxのdiffコマンドを使用して、2つのキャプチャの違いを見つけます。
この場合、FTP データトラフィックの CAPI および CAPO キャプチャは同一です。これは、パケット損失の原因がファイアウォールではないことの証明となります。
アップストリーム/ダウンストリームのパケット損失を識別します。
キー ポイント：
1. このパケットは TCP 再送信です。具体的には、パッシブモードの FTP データのためにクライアントからサーバーに送信される TCP SYN パケットです。クライアントがパケットを再送信しており、最初の SYN（パケット番号 1）が確認できるため、パケットはファイアウォールへのアップストリームで失われています。
この場合、SYNパケットはサーバに到達したものの、SYN/ACKパケットが戻る途中で失われた可能性があります。
2. サーバーからのパケットが存在し、Wireshark は前のセグメントが確認/キャプチャされていないことを識別しています。キャプチャされていないパケットは、サーバーからクライアントに送信されていますが、ファイアウォールキャプチャでは確認されていません。つまり、パケットはサーバーとファイアウォールの間で失われています。
これは、FTP サーバーとファイアウォールの間にパケット損失があることを示しています。
アクション2:追加のキャプチャを取得します。
エンドポイントでのキャプチャとともに、追加のキャプチャを取得します。分割統治法を適用して、パケット損失の原因となっている問題のあるセグメントの絞り込みを試みます。
キー ポイント：
- 受信者（この場合は FTP クライアント）は、着信 TCP シーケンス番号を追跡しています。パケットが失われた（予期されたシーケンス番号がスキップされた）ことを検出すると、ACK=「予期されていたもののスキップされたシーケンス番号」の ACK パケットを生成します。この例では、Ack=2224386800 です。
- Dup ACKにより、TCP高速再送信（Duplicate ACK受信後20ミリ秒以内の再送信）がトリガーされます。
重複 ACK は、次のことを意味します。
- 複数回の重複 ACK があり、実際の再送信がない場合は、到着順序が不正なパケットが存在する可能性が高いことを示しています。
- 実際の再送信に続く重複 ACK は、ある程度のパケット損失があることを示しています。
アクション3:中継パケットのファイアウォール処理時間を計算します。
2 つの異なるインターフェイスに同じキャプチャを適用します。
firepower# capture CAPI buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220 firepower# capture CAPI interface OUTSIDE
キャプチャをエクスポートし、入力パケットと出力パケットの時間差を確認します。
Case 7.TCP接続の問題（パケット破損）
事象の説明:
ワイヤレスクライアント（192.168.21.193）は宛先サーバー（192.168.14.250：HTTP）への接続を試み、次の 2 つの異なるシナリオが存在します。
- クライアントがアクセスポイント（AP）「A」に接続すると、HTTP 接続が機能しません。
- クライアントがアクセスポイント（AP）「B」に接続すると、HTTP 接続が機能します。
次の図は、このトポロジを示しています。
影響を受けるフロー：
送信元IP:192.168.21.193
宛先IP:192.168.14.250
プロトコル：TCP 80
キャプチャ分析
FTD LINA エンジンでのキャプチャを有効にします。
firepower# capture CAPI int INSIDE match ip host 192.168.21.193 host 192.168.14.250 firepower# capture CAPO int OUTSIDE match ip host 192.168.21.193 host 192.168.14.250
キャプチャ - 機能シナリオ：
ベースラインとして、既知の正常なシナリオからキャプチャを取得すると常に非常に便利です。
次の図は、NGFW の INSIDE インターフェイスで取得されたキャプチャを示しています。
次の図は、NGFW の OUTSIDE インターフェイスで取得されたキャプチャを示しています。
キー ポイント：
- 2 つのキャプチャはほぼ同じです（ISN のランダム化を考慮）。
- パケット損失の兆候は存在しません。
- 順序不正（OOO）パケットは存在しません。
- 3 つの HTTP GET 要求が存在します。最初のものは 404「Not Found」、2 つ目のものは 200「OK」、3 つ目のものは 304「Not Modified」リダイレクトメッセージを受け取っています。
キャプチャ：既知の障害があるシナリオ：
入力キャプチャ（CAPI）の内容は、次のとおりです。
キー ポイント：
- TCP 3 ウェイハンドシェイクが存在します。
- TCP 再送信があり、パケット損失の兆候が存在します。
- Wireshark によって「Malformed」（不正）として識別されたパケット（TCP ACK）が存在します。
この図は、出力キャプチャ（CAPO）の内容を示しています。
キー ポイント：
2 つのキャプチャはほぼ同じです（ISN のランダム化を考慮）。
- TCP 3 ウェイハンドシェイクが存在します。
- TCP 再送信があり、パケット損失の兆候が存在します。
- Wireshark によって「Malformed」（不正）として識別されたパケット（TCP ACK）が存在します。
不正なパケットを確認します。
キー ポイント：
- パケットは Wireshark によって「Malformed」（不正）と識別されています。
- 長さは 2 バイトです。
- 2 バイトの TCP ペイロードが存在します。
- ペイロードは 4 つの追加のゼロ（00 00）です。
推奨される対処法
このセクションに示されているアクションは、問題を絞り込むことを目的としています。
アクション1:追加のキャプチャを取得します。エンドポイントでキャプチャを含め、可能であれば、パケット破損の原因を切り分けるために分割統治法を適用してみてください。次に例を示します。
この場合、スイッチ「A」のインターフェイスドライバによって 2 つの追加バイトが付加されており、解決策は破損の原因となっているスイッチを交換することでした。
Case 8.UDP接続の問題（欠落パケット）
問題の説明：宛先syslogサーバにsyslog(UDP 514)メッセージが表示されない。
次の図は、このトポロジを示しています。
影響を受けるフロー：
送信元IP:192.168.1.81
宛先IP:10.10.1.73
プロトコル：UDP 514
キャプチャ分析
FTD LINA エンジンでのキャプチャを有効にします。
firepower# capture CAPI int INSIDE trace match udp host 192.168.1.81 host 10.10.1.73 eq 514 firepower# capture CAPO int OUTSIDE match udp host 192.168.1.81 host 10.10.1.73 eq 514
FTD キャプチャにはパケットが表示されていません。
firepower# show capture capture CAPI type raw-data trace interface INSIDE [Capturing - 0 bytes] match udp host 192.168.1.81 host 10.10.1.73 eq syslog capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes] match udp host 192.168.1.81 host 10.10.1.73 eq syslog
推奨される対処法
このセクションに示されているアクションは、問題を絞り込むことを目的としています。
アクション1:FTD接続テーブルをチェックします。
特定の接続を確認するには、次の構文を使用します。
firepower# show conn address 192.168.1.81 port 514
10 in use, 3627189 most used
Inspect Snort:
preserve-connection: 6 enabled, 0 in effect, 74 most enabled, 0 most in effect
UDP INSIDE 10.10.1.73:514 INSIDE 192.168.1.81:514, idle 0:00:00, bytes 480379697, flags -oN1
キー ポイント：
- 入力インターフェイスと出力インターフェイスが同じです（U ターンしています）。
- バイト数が非常に大きな値（約 5 GB）になっています。
- フラグ「o」は、フローオフロード（ハードウェア アクセラレーション フロー）を示します。これが、FTD キャプチャにパケットが表示されない理由です。フローオフロードは、41xx プラットフォームと 93xx プラットフォームでのみサポートされています。この場合、デバイスは 41xx です。
アクション2:シャーシレベルのキャプチャを取得します。
次の図のように、Firepower のシャーシマネージャに接続し、入力インターフェイス（この場合は E1/2）およびバックプレーン インターフェイス（E1/9 と E1/10）でのキャプチャを有効にします。
数秒後に、次のようになります。
変更前：
変更後：
キー ポイント：
- 表示フィルタが適用され、パケットの重複が削除されて、Syslog のみが表示されています。
- パケット間の時間差はマイクロ秒レベルです。これは、パケットレートが非常に高いことを示しています。
- 存続可能時間（TTL）の値が継続的に減少しています。これは、パケットのループを示しています。
アクション3:パケットトレーサを使用します。
パケットがファイアウォールの LINA エンジンを通過しないため、ライブトレース（トレース付きのキャプチャ）は実行できませんが、パケットトレーサを使用してエミュレートされたパケットをトレースできます。
firepower# packet-tracer input INSIDE udp 10.10.1.73 514 192.168.1.81 514 Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: FLOW-LOOKUP Subtype: Result: ALLOW Config: Additional Information: Found flow with id 25350892, using existing flow Phase: 4 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Verdict: (fast-forward) fast forward this flow Phase: 5 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.1.81 using egress ifc INSIDE Phase: 6 Type: ADJACENCY-LOOKUP Subtype: next-hop and adjacency Result: ALLOW Config: Additional Information: adjacency Active next-hop mac address a023.9f92.2a4d hits 1 reference 1 Phase: 7 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: INSIDE output-status: up output-line-status: up Action: allow
アクション4:FTDルーティングを確認します。
ファイアウォール ルーティング テーブルを調べて、ルーティングに問題がないか確認します。
firepower# show route 10.10.1.73
Routing entry for 10.10.1.0 255.255.255.0
Known via "eigrp 1", distance 90, metric 3072, type internal
Redistributing via eigrp 1
Last update from 192.168.2.72 on OUTSIDE, 0:03:37 ago
Routing Descriptor Blocks:
* 192.168.2.72, from 192.168.2.72, 0:02:37 ago, via OUTSIDE
Route metric is 3072, traffic share count is 1
Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 29/255, Hops 1
キー ポイント：
- ルートは正しい出力インターフェイスに向かっています。
- ルートは数分前（0:02:37）に学習されています。
アクション5:接続の稼働時間を確認します。
接続の継続時間を調べて、この接続がいつ確立されたのかを確認します。
firepower# show conn address 192.168.1.81 port 514 detail
21 in use, 3627189 most used
Inspect Snort:
preserve-connection: 19 enabled, 0 in effect, 74 most enabled, 0 most in effect
Flags: A - awaiting responder ACK to SYN, a - awaiting initiator ACK to SYN,
b - TCP state-bypass or nailed,
C - CTIQBE media, c - cluster centralized,
D - DNS, d - dump, E - outside back connection, e - semi-distributed,
F - initiator FIN, f - responder FIN,
G - group, g - MGCP, H - H.323, h - H.225.0, I - initiator data,
i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
k - Skinny media, L - decap tunnel, M - SMTP data, m - SIP media
N - inspected by Snort (1 - preserve-connection enabled, 2 - preserve-connection in effect)
n - GUP, O - responder data, o - offloaded,
P - inside back connection, p - passenger flow
q - SQL*Net data, R - initiator acknowledged FIN,
R - UDP SUNRPC, r - responder acknowledged FIN,
T - SIP, t - SIP transient, U - up,
V - VPN orphan, v - M3UA W - WAAS,
w - secondary domain backup,
X - inspected by service module,
x - per session, Y - director stub flow, y - backup stub flow,
Z - Scansafe redirection, z - forwarding stub flow
UDP INSIDE: 10.10.1.73/514 INSIDE: 192.168.1.81/514,
flags -oN1, idle 0s, uptime 3m49s, timeout 2m0s, bytes 4801148711
重要なポイント：
- 接続は約 4 分前（ルーティングテーブルに EIGRP ルートがインストールされる前）に確立されています。
アクション6:確立された接続をクリアします。
この場合、パケットは確立された接続に一致し、誤った出力インターフェイスにルーティングされます。これによりループが発生します。これは、ファイアウォールの次の動作順序が原因です。
- 確立された接続のルックアップ（これは、グローバル ルーティング テーブルのルックアップよりも優先されます）
- ネットワークアドレス変換（NAT）のルックアップ（UN-NAT（宛先 NAT）フェーズは、PBR およびルートのルックアップよりも優先されます）
- ポリシーベース ルーティング（PBR）
- グローバル ルーティング テーブルのルックアップ
接続は決してタイムアウトしない（UDP 接続がアイドルタイムアウトする 2 分間の間に Syslog クライアントがパケットを継続的に送信します）ため、接続を手動でクリアする必要があります。
firepower# clear conn address 10.10.1.73 address 192.168.1.81 protocol udp port 514 1 connection(s) deleted.
新しい接続が確立されることを確認します。
firepower# show conn address 192.168.1.81 port 514 detail | b 10.10.1.73.*192.168.1.81
UDP OUTSIDE: 10.10.1.73/514 INSIDE: 192.168.1.81/514,
flags -oN1, idle 1m15s, uptime 1m15s, timeout 2m0s, bytes 408
アクション7:フローティングコネクトタイムアウトを設定します。
これは、特に UDP フローについて、問題に対処し、最適でないルーティングを回避するために適切なソリューションです。[デバイス（Devices）] > [プラットフォーム設定（Platform Settings）] > [タイムアウト（Timeouts）] に移動し、値を設定します。
フローティング接続タイムアウトの詳細については、コマンドリファレンスを参照してください。
Case 9.HTTPS接続の問題（シナリオ1）
問題の説明：クライアント192.168.201.105とサーバ192.168.202.101間のHTTPS通信が確立できない
次の図は、このトポロジを示しています。
影響を受けるフロー：
送信元IP:192.168.201.111
宛先IP:192.168.202.111
プロトコル：TCP 443(HTTPS)
キャプチャ分析
FTD LINA エンジンでのキャプチャを有効にします。
OUTSIDE キャプチャで使用される IP は、ポートアドレス変換の設定により異なります。
firepower# capture CAPI int INSIDE match ip host 192.168.201.111 host 192.168.202.111 firepower# capture CAPO int OUTSIDE match ip host 192.168.202.11 host 192.168.202.111
次の図は、NGFW の INSIDE インターフェイスで取得されたキャプチャを示しています。
キー ポイント：
- TCP 3 ウェイハンドシェイクが存在します。
- SSL ネゴシエーションが開始されています。クライアントが Client Hello メッセージを送信しています。
- クライアントに送信された TCP ACK が存在します。
- クライアントに送信された TCP RST が存在します。
次の図は、NGFW の OUTSIDE インターフェイスで取得されたキャプチャを示しています。
キー ポイント：
- TCP 3 ウェイハンドシェイクが存在します。
- SSL ネゴシエーションが開始されています。クライアントが Client Hello メッセージを送信しています。
- ファイアウォールからサーバーに送信された TCP 再送信が存在します。
- サーバーに送信された TCP RST が存在します。
推奨される対処法
このセクションに示されているアクションは、問題を絞り込むことを目的としています。
アクション1:追加のキャプチャを取得します。
サーバーで取得したキャプチャから、サーバーが破損した TCP チェックサムをともなう TLS Client Hello を受信しており、それらをサイレントにドロップしたことが分かります（クライアントへの TCP RST またはその他の応答パケットは存在しません）。
すべてを組み合わせると、次のように結論付けられます。
この場合、理解するために、Wiresharkで「Validate the TCP checksum if possible」オプションを有効にする必要があります。次の図のように、[編集（Edit）] > [設定（Preferences）] > [プロトコル（Protocols）] > [TCP] に移動します。
この場合、全体像を把握するためにキャプチャを並べて配置すると便利です。
キー ポイント：
- TCP 3 ウェイハンドシェイクが存在します。IP ID は同じです。これは、フローがファイアウォールによってプロキシされなかったことを意味します。
- TLS Client Helloは、IP ID 12083のクライアントから送信されます。パケットはファイアウォールによってプロキシされ（この場合、ファイアウォールはTLS復号化ポリシーで設定されています）、IP IDは52534に変更されます。また、パケットのTCPチェックサムが破損します(後で修正されたソフトウェア不具合が原因)。
- ファイアウォールはTCPプロキシモードで、クライアント（サーバをスプーフィングする）にACKを送信します。
- ファイアウォールはサーバーから TCP ACK パケットを受信しておらず、TLS Client Hello メッセージを再送信しています。これも、ファイアウォールがアクティブ化した TCP プロキシモードが原因です。
- 約 30 秒後、ファイアウォールは中断し、TCP RST をクライアントに送信しています。
- ファイアウォールがサーバーに向けて TCP RST を送信しています。
次のドキュメントを参照してください。
Case 10.HTTPS接続の問題（シナリオ2）
問題の説明：FMC スマートライセンスの登録に失敗します。
次の図は、このトポロジを示しています。
影響を受けるフロー：
送信元IP:192.168.0.100
宛先：tools.cisco.com
プロトコル：TCP 443(HTTPS)
キャプチャ分析
FMC 管理インターフェイスでのキャプチャを有効にします。
登録を再試行します。エラーメッセージが表示されたら、Ctrl + C キーを押してキャプチャを停止します。
root@firepower:/Volume/home/admin# tcpdump -i eth0 port 443 -s 0 -w CAP.pcap HS_PACKET_BUFFER_SIZE is set to 4. tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes ^C264 packets captured <- CTRL-C 264 packets received by filter 0 packets dropped by kernel root@firepower:/Volume/home/admin#
次の図のように、FMC からキャプチャを収集します（[システム（System）] > [ヘルス（Health）] > [モニター（Monitor）] に移動し、デバイスを選択して、[高度なトラブルシューティング（Advanced Troubleshooting）] を選択します）。
次の図は、Wireshark での FMC キャプチャを示しています。
次の図のように、いずれかの TCP フローを追跡します（[追跡（Follow）] > [TCPストリーム（TCP Stream）]）。
キー ポイント：
- TCP 3 ウェイハンドシェイクが存在します。
- クライアント（FMC）が SSL Client Hello メッセージをスマートライセンスポータルに送信しています。
- SSLセッションIDは0です。これは、セッションが再開されていないことを意味します。
- 宛先サーバーが Server Hello、Certificate、および Server Hello Done メッセージで応答しています。
- クライアントは、「不明なCA」に関するSSL致命的アラートを送信します。
- クライアントが TCP RST を送信してセッションを終了しています。
- TCP セッションの時間は全体（確立から終了まで）で約 0.5 秒でした。
サーバーの証明書（Certificate） を選択し、[発行者（issuer）] フィールドを展開して、commonName を表示します。この場合、この共通名は、中間者（MITM）を実行しているデバイスを示しています。
次の図は、このことを示しています。
推奨される対処法
このセクションに示されているアクションは、問題を絞り込むことを目的としています。
アクション1:追加のキャプチャを取得します。
中継ファイアウォールデバイスでキャプチャを取得します。
CAPI の内容は、次のとおりです。
CAPO の内容は、次のとおりです。
これらのキャプチャから、中継ファイアウォールがサーバー証明書を変更（MITM）したことが分かります。
アクション2:デバイスログを確認します。
このドキュメントで説明するように、FMC TS バンドルを収集できます。
この場合、/dir-archives/var-log/process_stdout.log ファイルに次のようなメッセージが表示されます。
SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-ERROR: ch_pf_curl_send_msg[494],
failed to perform, err code 60, err string "SSL peer certificate or SSH remote key was not OK" ...
SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-TRACE: ch_pf_curl_is_cert_issue[514],
cert issue checking, ret 60, url "https://tools.cisco.com/its/
推奨される解決策
特定のフローの MITM を無効にして、FMC がスマートライセンスクラウドに正常に登録できるようにします。
Case 11.IPv6接続の問題
問題の説明：内部ホスト（ファイアウォールのINSIDEインターフェイスの背後にある）は外部ホスト（ファイアウォールのOUTSIDEインターフェイスの背後にあるホスト）と通信できません。
次の図は、このトポロジを示しています。
影響を受けるフロー：
送信元IP:fc00:1:1:1::100
宛先IP:fc00:1:1:2::2
プロトコル：任意
キャプチャ分析
FTD LINA エンジンでのキャプチャを有効にします。
firepower# capture CAPI int INSIDE match ip any6 any6 firepower# capture CAPO int OUTSIDE match ip any6 any6
キャプチャ - 非機能シナリオ：
これらのキャプチャは、IP fc00:1:1:1::100（内部ルータ）から IP fc00:1:1:2::2（アップストリームルータ）への ICMP 接続テストと並行して取得されています。
ファイアウォールの INSIDE インターフェイスでのキャプチャには、次の内容が含まれています。
キー ポイント：
- ルータはIPv6ネイバー送信要求メッセージを送信し、アップストリームデバイスのMACアドレス(IP fc00:1:1:1::1)を要求します。
- ファイアウォールが IPv6 の Neighbor Advertisement で応答しています。
- ルータが ICMP エコー要求を送信しています。
- ファイアウォールはIPv6ネイバー送信要求メッセージを送信し、ダウンストリームデバイスのMACアドレス(fc00:1:1:1::100)を要求します。
- ルータが IPv6 の Neighbor Advertisement で応答しています。
- ルータが追加の IPv6 ICMP エコー要求を送信しています。
ファイアウォールの OUTSIDE インターフェイスでのキャプチャには、次の内容が含まれています。
キー ポイント：
- ファイアウォールは、アップストリームデバイスのMACアドレス(IP fc00:1:1:2::2)を要求するIPv6ネイバー送信要求メッセージを送信します。
- ルータが IPv6 の Neighbor Advertisement で応答しています。
- ファイアウォールが IPv6 ICMP エコー要求を送信しています。
- アップストリームデバイス（ルータfc00:1:1:2::2）は、IPv6アドレスfc00:1:1:1::100のMACアドレスを要求するIPv6ネイバー送信要求メッセージを送信します。
- ファイアウォールが追加の IPv6 ICMP エコー要求を送信しています。
- アップストリームルータは、追加のIPv6ネイバー送信要求メッセージを送信し、IPv6アドレスfc00:1:1:1::100のMACアドレスを要求します。
ポイント 4 は非常に興味深い点です。通常、アップストリームルータはファイアウォールのOUTSIDEインターフェイス(fc00:1:1:2::2)のMACを要求しますが、代わりにfc00:1:1:1::100を要求します。これは設定ミスを示しています。
推奨される対処法
このセクションに示されているアクションは、問題を絞り込むことを目的としています。
アクション1:IPv6ネイバーテーブルをチェックします。
ファイアウォールの IPv6 ネイバーテーブルは適切に入力されています。
firepower# show ipv6 neighbor | i fc00 fc00:1:1:2::2 58 4c4e.35fc.fcd8 STALE OUTSIDE fc00:1:1:1::100 58 4c4e.35fc.fcd8 STALE INSIDE
アクション2:IPv6設定を確認します。
ファイアウォールの設定は、次のとおりです。
firewall# show run int e1/2 ! interface Ethernet1/2 nameif INSIDE cts manual propagate sgt preserve-untag policy static sgt disabled trusted security-level 0 ip address 192.168.0.1 255.255.255.0 ipv6 address fc00:1:1:1::1/64 ipv6 enable firewall# show run int e1/3.202 ! interface Ethernet1/3.202 vlan 202 nameif OUTSIDE cts manual propagate sgt preserve-untag policy static sgt disabled trusted security-level 0 ip address 192.168.103.96 255.255.255.0 ipv6 address fc00:1:1:2::1/64 ipv6 enable
次のアップストリームデバイス設定により、設定ミスが分かります。
Router# show run interface g0/0.202 ! interface GigabitEthernet0/0.202 encapsulation dot1Q 202 vrf forwarding VRF202 ip address 192.168.2.72 255.255.255.0 ipv6 address FC00:1:1:2::2/48
キャプチャ - 機能シナリオ：
サブネットマスクの変更（/48 から /64 へ）により、問題が修正されています。機能シナリオでの CAPI キャプチャの内容は、次のとおりです。
重要なポイント：
- ルータは、アップストリームデバイスのMACアドレス(IP fc00:1:1:1::1)を要求するIPv6ネイバー送信要求メッセージを送信します。
- ファイアウォールが IPv6 の Neighbor Advertisement で応答しています。
- ルータが ICMP エコー要求を送信し、エコー応答を受信しています。
CAPO の内容：
キー ポイント：
- ファイアウォールは、アップストリームデバイスのMACアドレス(IP fc00:1:1:2::2)を要求するIPv6ネイバー送信要求メッセージを送信します。
- ファイアウォールが IPv6 の Neighbor Advertisement で応答しています。
- ファイアウォールが ICMP エコー要求を送信しています。
- ルータは、ダウンストリームデバイスのMACアドレス(IP fc00:1:1:1::1)を要求するIPv6ネイバー送信要求メッセージを送信します。
- ファイアウォールが IPv6 の Neighbor Advertisement で応答しています。
- ファイアウォールが ICMP エコー要求を送信し、エコー応答を受信しています。
Case 12.断続的な接続の問題（ARPポイズニング）
問題の説明：内部ホスト(192.168.0.x/24)に、同じサブネット内のホストとの断続的な接続の問題がある
次の図は、このトポロジを示しています。
影響を受けるフロー：
送信元IP:192.168.0.x/24
宛先IP:192.168.0.x/24
プロトコル：任意
内部ホストの ARP キャッシュでポイゾニングが発生していると見られます。
キャプチャ分析
FTD LINA エンジンでのキャプチャを有効にします。
次のキャプチャでは、INSIDE インターフェイスの ARP パケットのみがキャプチャされます。
firepower# capture CAPI_ARP interface INSIDE ethernet-type arp
キャプチャ - 非機能シナリオ：
ファイアウォールの INSIDE インターフェイスでのキャプチャには、次の内容が含まれています。
キー ポイント：
- ファイアウォールが 192.168.0.x/24 ネットワーク内の IP に関するさまざまな ARP 要求を受信しています。
- ファイアウォールが、それらすべて（プロキシ ARP）に独自の MAC アドレスで応答しています。
推奨される対処法
このセクションに示されているアクションは、問題を絞り込むことを目的としています。
アクション1:NAT設定をチェックします。
NAT設定に関して、no-proxy-arpキーワードが以前の動作を妨げる可能性がある場合があります。
firepower# show run nat nat (INSIDE,OUTSIDE) source static NET_1.1.1.0 NET_2.2.2.0 destination static NET_192.168.0.0 NET_4.4.4.0 no-proxy-arp
アクション2:ファイアウォールインターフェイスでproxy-arp機能を無効にします。
「no-proxy-arp」キーワードを使用しても問題が解決しない場合は、インターフェイス自体でプロキシARPを無効にしてみてください。FTDの場合は、このドキュメントの作成時点で、FlexConfigを使用してコマンドを展開する必要があります（適切なインターフェイス名を指定します）。
sysopt noproxyarp INSIDE
Case 13.CPU Hogを引き起こすSNMPオブジェクトID(OID)の特定
このケースでは、SNMP バージョン 3（SNMPv3）パケットのキャプチャの分析に基づいて、メモリポーリングの特定の SNMP OID を CPU 占有（パフォーマンスの問題）の根本原因として特定する方法を説明します。
問題の説明：データインターフェイスのオーバーランは継続的に増加します。さらに調査を進めると、インターフェイスオーバーランの根本原因であるCPUホグ（SNMPプロセスによって引き起こされる）も存在することが判明しました。
トラブルシューティング プロセスの次のステップは、SNMP プロセスによって引き起こされる CPU 占有の根本原因を特定すること、特に、問題の範囲を絞り込んで、ポーリング時に潜在的に CPU 占有を発生させる可能性がある SNMP オブジェクト識別子（OID）を特定することでした。
現在、FTD LINA エンジンでは、ポーリングされている SNMP OID をリアルタイムで確認するための「show」コマンドは提供されていません。
ポーリング用のSNMP OIDのリストはSNMPモニタリングツールから取得できますが、この場合は次の予防要因があります。
- FTD 管理者が SNMP モニタリングツールにアクセスできませんでした。
- プライバシーのために、FTD で SNMP バージョン 3 が認証とデータ暗号化によって設定されました。
キャプチャ分析
FTD 管理者は、SNMP バージョン 3 の認証とデータ暗号化のログイン情報を持っていたため、次のアクションプランが提案されました。
- SNMP パケットのキャプチャを取得します。
- キャプチャを保存し、Wireshark の SNMP プロトコル設定を使用して、SNMP バージョン 3 パケットを復号するための SNMP バージョン 3 のログイン情報を指定します。復号されたキャプチャは、SNMP OID の分析と取得に使用されます。
snmp-server ホスト設定で使用されるインターフェイスでの SNMP パケットのキャプチャを設定します。
firepower# show run snmp-server | include host snmp-server host management 192.168.10.10 version 3 netmonv3 firepower# show ip address management System IP Address: Interface Name IP address Subnet mask Method Management0/0 management 192.168.5.254 255.255.255.0 CONFIG Current IP Address: Interface Name IP address Subnet mask Method Management0/0 management 192.168.5.254 255.255.255.0 CONFIG firepower# capture capsnmp interface management buffer 10000000 match udp host 192.168.10.10 host 192.168.5.254 eq snmp firepower# show capture capsnmp capture capsnmp type raw-data buffer 10000000 interface outside [Capturing - 9512 bytes] match udp host 192.168.10.10 host 192.168.5.254 eq snmp
キー ポイント：
- SNMP 送信元および宛先のアドレス/ポートです。
- privKey が Wireshark に認識されていないため、SNMP プロトコル PDU を復号できませんでした。
- encryptedPDU プリミティブの値です。
推奨される対処法
このセクションに示されているアクションは、問題を絞り込むことを目的としています。
アクション1:SNMPキャプチャを復号化します。
キャプチャを保存し、Wireshark の SNMP プロトコル設定を編集して、パケットを復号するための SNMP バージョン 3 のログイン情報を指定します。
firepower# copy /pcap capture: tftp: Source capture name [capsnmp]? Address or name of remote host []? 192.168.10.253 Destination filename [capsnmp]? capsnmp.pcap !!!!!! 64 packets copied in 0.40 secs
図のように、Wireshark でキャプチャファイルを開き、SNMP パケットを選択して、[プロトコル設定（Protocol Preferences）] > [ユーザーテーブル（Users Table）] に移動します。
SNMP ユーザーテーブルで、SNMP バージョン 3 のユーザー名、認証モデル、認証パスワード、プライバシープロトコル、およびプライバシーパスワードが指定されています（次の図には実際のログイン情報は表示されていません）。
SNMP ユーザー設定が適用されると、Wireshark に復号された SNMP PDU が表示されます。
キー ポイント：
- SNMP モニタリングツールが、SNMP getBulkRequest を使用して、親 OID 1.3.6.1.4.1.9.9.221.1 および関連する OID を照会し、処理しています。
- FTDは、1.3.6.1.4.1.9.9.221.1に関連するOIDを含むget-responseで各getBulkRequestに応答しました。
アクション2:SNMP OIDを特定します。
次の図のように、SNMP Object Navigator には、OID 1.3.6.1.4.1.9.9.221.1 が CISCO-ENHANCED-MEMPOOL-MIB という名前の Management Information Base（MIB）に属していることが示されています。
WiresharkでOIDを人間が読める形式で表示するには、次の手順を実行します。
- 次の図のように、MIB CISCO-ENHANCED-MEMPOOL-MIB とその依存関係をダウンロードします。
2. Wireshark の [編集（Edit）] > [設定（Preferences）] > [名前解決（Name Resolution）] ウィンドウでは、[OID解決を有効にする（Enable OID Resolution）] がオンになっています。[SMI（MIBおよびPIBパス）（SMI (MIB and PIB modules)）] ウィンドウで、ダウンロードした MIB を含むフォルダと SMI（MIB および PIB モジュール）を指定します。CISCO-ENHANCED-MEMPOOL-MIB は、モジュールのリストに自動的に追加されます。
3. Wireshark が再起動すると、OID 解決がアクティブになります。
キャプチャファイルの復号された出力に基づいて、SNMP モニタリングツールは、FTD のメモリプールの使用率に関するデータを定期的に（10 秒間隔で）ポーリングしています。TechNoteの記事「メモリ関連統計情報のASA SNMPポーリング」で説明されているように、SNMPを使用してグローバル共有プール(GSP)の使用率をポーリングすると、CPUの使用率が高くなります。この場合、キャプチャから、グローバル共有プールの使用率が SNMP getBulkRequest プリミティブの一部として定期的にポーリングされていたことが分かります。
SNMP プロセスによって発生する CPU 占有を最小限に抑えるために、記事に記載されている SNMP に関する CPU 占有の軽減手順に従い、GSP に関連する OID をポーリングしないことが推奨されています。GSP に関連する OID の SNMP ポーリングがない場合、SNMP プロセスによって発生する CPU 占有は見られず、オーバーランのレートは大幅に減少しています。
関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
3.0 |
31-Jul-2024 |
再認定、代替テキスト、固定ヘッダー、句読点、およびhtml SEO最適化。 |
2.0 |
02-Jun-2023 |
再認定 |
1.0 |
21-Nov-2019 |
初版 |
フィードバック