内容

はじめに

前提条件

要件

使用するコンポーネント

背景説明

NGFW 製品ファミリでキャプチャを収集およびエクスポートする方法

FXOS キャプチャの収集

FTD LINA キャプチャの有効化および収集

FTD Snort キャプチャの有効化および収集

トラブルシュート

Case 1.出力インターフェイスにTCP SYNなし

キャプチャ分析

推奨される対処法

考えられる原因と推奨されるアクションの概要

Case 2.クライアントからのTCP SYN、サーバからのTCP RST

キャプチャ分析

推奨される対処法

Case 3.1つのエンドポイントからのTCP 3ウェイハンドシェイク+ RST

キャプチャ分析

3.1：クライアントからの TCP 3 ウェイハンドシェイク + 遅延 RST

推奨される対処法

3.2：クライアントからの TCP 3 ウェイハンドシェイク + 遅延 FIN/ACK + サーバーからの遅延 RST

推奨される対処法

3.3：クライアントからの TCP 3 ウェイハンドシェイク + 遅延 RST

推奨される対処法

3.4：サーバーからの TCP 3 ウェイハンドシェイク + 即時 RST

推奨される対処法

ケース 4.クライアントからのTCP RST

キャプチャ分析

推奨される対処法

ケース 5.遅いTCP転送（シナリオ1）

シナリオ 1.遅い転送

キャプチャ分析

推奨される対処法

シナリオ 2.高速転送

Case 6.遅いTCP転送（シナリオ2）

キャプチャ分析

推奨される対処法

キャプチャをエクスポートして、入力パケットと出力パケットの時間差をチェックします。ケース7.TCP接続の問題（パケット破損）

キャプチャ分析

推奨される対処法

Case 8.UDP接続の問題（欠落パケット）

キャプチャ分析

推奨される対処法

キャプチャ分析

推奨される対処法

Case 10.HTTPS接続の問題（シナリオ2）

キャプチャ分析

推奨される対処法

キャプチャ分析

推奨される対処法

Case 12.断続的な接続の問題（ARPポイズニング）

キャプチャ分析

推奨される対処法

Case 13.CPU Hogを引き起こすSNMPオブジェクトID(OID)の特定

キャプチャ分析

推奨される対処法

関連情報

はじめに

このドキュメントでは、ネットワークの問題を効果的にトラブルシューティングするための、さまざまなパケットキャプチャ分析手法について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

- 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）アプリケーションを使用している場合、パケット処理を図示すると次のようになります。

1. パケットが入力インターフェイスに入り、シャーシの内部スイッチによって処理されます。

2. パケットが、主に L3/L4 チェックを行う FTD LINA エンジンに入ります。

3. ポリシーで要求される場合、パケットが Snort エンジンによって検査されます（主に L7 検査）。

4. Snort エンジンがパケットに対する判定を返します。

5. LINA エンジンは、Snort の判定に基づいてパケットをドロップまたは転送する.

6. パケットがシャーシの内部スイッチを通過してシャーシから出ます。

示されているアーキテクチャに基づいて、FTDキャプチャは3つの異なる場所で取得できます。

- FXOS

- FTD LINA エンジン

- FTD Snort エンジン

FXOS キャプチャの収集

このプロセスについては、次のドキュメントで説明されています。

https://www.cisco.com/c/en/us/td/docs/security/firepower/fxos/fxos271/web-guide/b_GUI_FXOS_ConfigGuide_271/troubleshooting.html#concept_E8823CC63C934A909BBC0DF12F301DED

次の図のように、FXOS キャプチャは、内部スイッチの観点から入力方向でのみ取得できます。

次の図では、方向ごとに2つのキャプチャポイントが示されています（内部スイッチアーキテクチャによる）。

ポイント 2、3、および 4 でキャプチャされるパケットは、仮想ネットワークタグ（VNTag）を持ちます。

注:FXOSシャーシレベルのキャプチャは、FP41xxおよびFP93xxプラットフォームでのみ使用できます。FP1xxx および FP21xx では、この機能は提供されません。

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 からキャプチャを有効化/収集する方法の他の例については、次のドキュメントを参照してください。

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212474-working-with-firepower-threat-defense-f.html

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 レベルのキャプチャの例については、次のドキュメントを参照してください。

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212474-working-with-firepower-threat-defense-f.html

トラブルシュート

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 インターフェイスで取得されたキャプチャを示しています。

キー ポイント：

1. TCP 3 ウェイハンドシェイクです。

2. 双方向のデータ交換です。

3. パケット間の遅延なし（パケット間の時間差に基づく）

4. 送信元 MAC は正しいダウンストリームデバイスです。

次の図は、NGFW の OUTSIDE インターフェイスで取得されたキャプチャを示しています。

キー ポイント：

1. CAPI キャプチャと同じデータです。

2. 宛先 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 キャプチャを示しています。

キー ポイント：

1. TCP SYN パケットのみが表示されています（TCP 3 ウェイハンドシェイクは表示されていません）。

2. 確立できない 2 つの TCP セッション（送信元ポート 3171 および 3172）があります。送信元クライアントが TCP SYN パケットを再送信します。これらの再送信されたパケットは、Wireshark によって TCP 再送信として識別されます。

3. TCPの再送信は、～3秒から6秒の間隔で発生します。

4. 送信元 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 を設定する方法については、次のドキュメントを参照してください。

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/200479-Configure-Logging-on-FTD-via-FMC.html

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

ヒント：パケットの内容に興味がない場合は、パケットヘッダーだけをキャプチャできます（ヘッダーのみのオプション）。これにより、同じキャプチャバッファでより多くのパケットをキャプチャできます。さらに、キャプチャバッファのサイズ（デフォルトでは 500KB）を最大 32MB に増やすことができます（buffer オプション）。最後に、FTD バージョン 6.3 以降では、file-size オプションを使用して、最大 10GB のキャプチャファイルを設定できます。その場合、キャプチャの内容は pcap 形式でのみ表示されます。

キャプチャの内容を確認する場合、フィルタを使用して検索を絞り込むことができます。

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」から出る場合があります。ファイアウォールの出力インターフェイスは、次の動作順序に基づいて決定されます。

1. 確立された接続のルックアップ

2. ネットワークアドレス変換（NAT）のルックアップ（UN-NAT（宛先 NAT）フェーズは、PBR およびルートのルックアップよりも優先されます）

3. ポリシーベース ルーティング（PBR）

4. ルーティングテーブルのルックアップ

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 であることが分かります。

これは、次のように図示されます。

注：すべてのFTDインターフェイスのセキュリティレベルは0であるため、show conn の出力でのインターフェイスの順序はインターフェイス番号に基づきます。具体的には、vpif-num（仮想プラットフォームのインターフェイス番号）の大きいインターフェイスが内部として選択され、vpif-num の小さいインターフェイスが外部として選択されます。show interface detailコマンドを使用して、インターフェイスのvpif値を確認できます。関連する機能拡張、Cisco Bug ID CSCvi15290 ENH:FTDはFTDの「show conn」出力に接続方向を示します

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

注：Firepowerソフトウェアリリース6.5以降のASAリリース9.13.xでは、show conn longおよびshow conn detailコマンドの出力によって、接続の発信側と応答側に関する情報が提供されます

出力 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 パケットが送信されない場合、考えられる原因は次のとおりです。

考えられる原因

推奨される対処法

パケットがファイアウォール アクセス ポリシーによってドロップされています。

- packet-tracer または capture w/trace を使用して、ファイアウォールによるパケットの処理方法を確認します。

- ファイアウォールログを確認します。

- ファイアウォール ASP ドロップを確認します（show asp drop または capture type asp-drop）。

- FMC 接続イベントを確認します。これは、ルールでログ記録が有効になっていることが前提となります。

キャプチャフィルタが適切ではありません。

- packet-tracer または capture w/trace を使用して、送信元 IP または宛先 IP を変更する NAT 変換が存在するかどうかを確認します。この場合は、キャプチャフィルタを調整します。

- show conn long コマンドの出力には、NAT 化された IP が示されます。

パケットが別の出力インターフェイスに送信されています。

- packet-tracer または capture w/trace を使用して、ファイアウォールによるパケットの処理方法を確認します。出力インターフェイスの決定、現在の接続、UN-NAT、PBR、およびルーティングテーブルのルックアップに関する動作の順序を覚えておいてください。

- ファイアウォールログを確認します。

- ファイアウォール接続テーブルを確認します（show conn）。

パケットが現在の接続に一致するために誤ったインターフェイスに送信される場合は、clear conn addressコマンドを使用して、クリアする接続の5タプルを指定します。

宛先へのルートが存在しません。

- packet-tracer または capture w/trace を使用して、ファイアウォールによるパケットの処理方法を確認します。

- ファイアウォール ASP ドロップ（show asp drop）で no-route ドロップの理由を確認します。

出力インターフェイスに ARP エントリがありません。

- ファイアウォール ARP キャッシュを確認します（show arp）。

- packet-tracer を使用して、有効な隣接関係（アジャセンシー）が存在するかどうかを確認します。

出力インターフェイスがダウンしています。

ファイアウォールに関する 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 のキャプチャを示しています。

キー ポイント：

1. 送信元が TCP SYN パケットを送信しています。

2. TCP RST が送信元に向けて送信されています。

3. 送信元が TCP SYN パケットを再送信しています。

4. MAC アドレスは適切です（入力パケットでは、送信元 MAC アドレスがダウンストリームルータに属し、宛先 MAC アドレスがファイアウォールの INSIDE インターフェイスに属しています）。

次の図は、Wireshark での CAPO のキャプチャを示しています。

キー ポイント：

1. 送信元が TCP SYN パケットを送信しています。

2. TCP RST が OUTSIDE インターフェイスに到着しています。

3. 送信元が TCP SYN パケットを再送信しています。

4. 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 つのパケットを視覚的に比較して、ファイアウォールがパケットを変更したり、破損させたりしていないことを確認します。いくつかの予期される相違点が強調表示されています。

キー ポイント：

1. タイムスタンプが異なっています。そのこと自体は問題ありませんが、その差は小さく、妥当な範囲である必要があります。これは、パケットに適用される機能およびポリシーチェックと、デバイスの負荷によって異なります。

2. パケットの長さは、特にdot1Qヘッダーが片側だけでファイアウォールによって追加/削除される場合に異なります。

3. MAC アドレスが異なっています。

4. キャプチャがサブインターフェイスで取得された場合は、dot1Q ヘッダーがある可能性があります。

5. NAT またはポートアドレス変換（PAT）がパケットに適用されている場合、IP アドレスが異なります。

6. NAT または PAT がパケットに適用されている場合、送信元ポートまたは宛先ポートが異なります。

7. Wireshark の [相対シーケンス番号（Relative Sequence Number）] オプションを無効にすると、初期シーケンス番号（ISN）のランダム化により、ファイアウォールによって TCP シーケンス番号/確認応答番号が変更されていることが分かります。

8. 一部の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 の両方に同じパケットが含まれています。

キー ポイント：

1. TCP 3 ウェイハンドシェイクがファイアウォールを通過しています。

2. サーバーが SYN/ACK を再送信しています。

3. クライアントが ACK を再送信しています。

4. 約 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 の両方に同じパケットが含まれています。

キー ポイント：

1. TCP 3 ウェイハンドシェイクがファイアウォールを通過しています。

2. 約 5 秒後、クライアントが FIN/ACK を送信しています。

3. 約 20 秒後、サーバーは中断して TCP RST を送信しています。

このキャプチャに基づいて、ファイアウォールを通過した TCP 3 ウェイハンドシェイクが存在するものの 1 つのエンドポイントで実際に完了していないように見えると結論付けることができます（再送信がこれを示しています）。

推奨される対処法

ケース 3.1 と同じです。

3.3：クライアントからの TCP 3 ウェイハンドシェイク + 遅延 RST

次の図のように、ファイアウォールキャプチャの CAPI と CAPO の両方に同じパケットが含まれています。

キー ポイント：

1. TCP 3 ウェイハンドシェイクがファイアウォールを通過しています。

2. 約 20 秒後、クライアントは中断して TCP RST を送信しています。

これらのキャプチャに基づいて、次のことが結論付けられます。

- 5 ～ 20 秒後に、1 つのエンドポイントが中断し、接続を終了することを決定しています。

推奨される対処法

ケース 3.1 と同じです。

3.4：サーバーからの TCP 3 ウェイハンドシェイク + 即時 RST

次の図のように、ファイアウォールキャプチャの CAPI と CAPO の両方にこれらのパケットが含まれています。

キー ポイント：

1. TCP 3 ウェイハンドシェイクがファイアウォールを通過しています。

2. 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 キャプチャにおける最初のフローの内容を示しています。

キー ポイント：

1. クライアントが TCP SYN パケットを送信しています。

2. クライアントが TCP RST パケットを送信しています。

3. TCP SYN パケットのシーケンス番号の値は 4098574664 です。

CAPO キャプチャの同じフローには、次のものが含まれます。

キー ポイント：

1. クライアントが TCP SYN パケットを送信しています。ファイアウォールが ISN をランダム化しています。

2. クライアントが TCP RST パケットを送信しています。

2 つのキャプチャに基づいて、次のことが結論付けられます。

- クライアントとサーバーの間に TCP 3 ウェイハンドシェイクは存在しません。

- クライアントから送信された TCP RST が存在します。CAPI キャプチャの TCP RST シーケンス番号の値は 1386249853 です。

推奨される対処法

このセクションに示されているアクションは、問題を絞り込むことを目的としています。

アクション1:クライアントでキャプチャを取得します。

ファイアウォールで収集されたキャプチャによると、非対称フローの強い兆候が存在します。これは、クライアントが 1386249853の値（ランダム化された ISN）で TCP RST を送信しているという事実に基づいています。

キー ポイント：

1. クライアントが TCP SYN パケットを送信しています。シーケンス番号は 4098574664 であり、ファイアウォールの INSIDE インターフェイス（CAPI）で見られるものと同じです。

2. ACK 番号が 1386249853 の TCP SYN/ACK が存在します（これは ISN のランダム化によって予期されるものです）。このパケットは、ファイアウォールキャプチャには表示されていません。

3. クライアントは、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

警告:FP1xxxおよびFP21xxのキャプチャLINAキャプチャは、FTDを通過するトラフィックの転送速度に影響を与えます。パフォーマンスの問題（FTD を介した低速転送）をトラブルシューティングする場合は、FP1xxx および FP21xxx プラットフォームで LINA キャプチャを有効にしないでください。代わりに、送信元ホストおよび宛先ホストでのキャプチャに加えて、SPAN または HW タップデバイスを使用してください。この問題は、Cisco Bug ID CSCvo30697に記載されています。

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 キャプチャの内容：

キー ポイント：

1. TCP Out-Of-Order（OOO）パケットが存在します。

2. TCP 再送信が存在します。

3. パケット損失（ドロップされたパケット）の兆候が存在します。

ヒント:File > Export Specified Packetsの順に移動するときに、キャプチャを保存します。その後、[表示された（Displayed）] パケット範囲のみを保存します。

推奨される対処法

このセクションに示されているアクションは、問題を絞り込むことを目的としています。

アクション1:パケット損失の場所を特定します。

このような場合、同時にキャプチャを取得し、分割統治法を使用して、パケット損失の原因となっているネットワークセグメントを特定する必要があります。ファイアウォールの観点では、主なシナリオは次の 3 つです。

1. パケット損失は、ファイアウォール自体が原因です。

2. パケット損失がファイアウォールデバイスへのダウンストリーム（サーバーからクライアントへの方向）で発生しています。

3. パケット損失がファイアウォールデバイスへのアップストリーム（クライアントからサーバーへの方向）で発生しています。

ファイアウォールによるパケット損失：パケット損失の原因がファイアウォールであるかどうかを特定するには、入力キャプチャと出力キャプチャを比較する必要があります。2 つの異なるキャプチャは、さまざまな方法で比較できます。このセクションでは、このタスクを実行する 1 つの方法を示します。

パケット損失を特定するために 2 つのキャプチャを比較する手順

ステップ 1：2つのキャプチャに同じ時間帯のパケットが含まれていることを確認します。言い換えると、これは、一方のキャプチャに、他方のキャプチャの前後でキャプチャされたパケットが存在していないということです。これは、いくつかの方法で実行できます。

- 最初と最後のパケットについて、その IP 識別子（ID）の値を確認します。

- 最初と最後のパケットについて、そのタイムスタンプの値を確認します。

この例では、各キャプチャの最初のパケットが持つ IP ID の値が同じであることを確認できます。

それらが同じでない場合は、次の手順を実行します。

1. 各キャプチャの最初のパケットでタイムスタンプを比較します。

2. 一番最後のタイムスタンプを持つキャプチャでフィルタを用意し、タイムスタンプフィルタを [==] から [>=]（最初のパケット）および [<=]（最後のパケット）に変更します。たとえば、次のようになります。

(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:追加のキャプチャを取得します。

エンドポイントでのキャプチャとともに、追加のキャプチャを取得します。分割統治法を適用して、パケット損失の原因となっている問題のあるセグメントの絞り込みを試みます。

キー ポイント：

1. 受信者（この場合は FTP クライアント）は、着信 TCP シーケンス番号を追跡しています。パケットが失われた（予期されたシーケンス番号がスキップされた）ことを検出すると、ACK=「予期されていたもののスキップされたシーケンス番号」の ACK パケットを生成します。この例では、Ack=2224386800 です。

2. 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 インターフェイスで取得されたキャプチャを示しています。

キー ポイント：

1. 2 つのキャプチャはほぼ同じです（ISN のランダム化を考慮）。

2. パケット損失の兆候は存在しません。

3. 順序不正（OOO）パケットは存在しません。

4. 3 つの HTTP GET 要求が存在します。最初のものは 404「Not Found」、2 つ目のものは 200「OK」、3 つ目のものは 304「Not Modified」リダイレクトメッセージを受け取っています。

キャプチャ：既知の障害があるシナリオ：

入力キャプチャ（CAPI）の内容は、次のとおりです。

キー ポイント：

1. TCP 3 ウェイハンドシェイクが存在します。

2. TCP 再送信があり、パケット損失の兆候が存在します。

3. Wireshark によって「Malformed」（不正）として識別されたパケット（TCP ACK）が存在します。

この図は、出力キャプチャ（CAPO）の内容を示しています。

キー ポイント：

2 つのキャプチャはほぼ同じです（ISN のランダム化を考慮）。

1. TCP 3 ウェイハンドシェイクが存在します。

2. TCP 再送信があり、パケット損失の兆候が存在します。

3. Wireshark によって「Malformed」（不正）として識別されたパケット（TCP ACK）が存在します。

不正なパケットを確認します。

キー ポイント：

1. パケットは Wireshark によって「Malformed」（不正）と識別されています。

2. 長さは 2 バイトです。

3. 2 バイトの TCP ペイロードが存在します。

4. ペイロードは 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

キー ポイント：

1. 入力インターフェイスと出力インターフェイスが同じです（U ターンしています）。

2. バイト数が非常に大きな値（約 5 GB）になっています。

3. フラグ「o」は、フローオフロード（ハードウェア アクセラレーション フロー）を示します。これが、FTD キャプチャにパケットが表示されない理由です。フローオフロードは、41xx プラットフォームと 93xx プラットフォームでのみサポートされています。この場合、デバイスは 41xx です。

アクション2:シャーシレベルのキャプチャを取得します。

次の図のように、Firepower のシャーシマネージャに接続し、入力インターフェイス（この場合は E1/2）およびバックプレーン インターフェイス（E1/9 と E1/10）でのキャプチャを有効にします。

数秒後に、次のようになります。

ヒント:Wiresharkでは、VNタグ付きパケットを除外して、物理インターフェイスレベルでのパケットの重複を排除します

変更前：

変更後：

キー ポイント：

1. 表示フィルタが適用され、パケットの重複が削除されて、Syslog のみが表示されています。

2. パケット間の時間差はマイクロ秒レベルです。これは、パケットレートが非常に高いことを示しています。

3. 存続可能時間（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

キー ポイント：

1. ルートは正しい出力インターフェイスに向かっています。

2. ルートは数分前（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

重要なポイント：

1. 接続は約 4 分前（ルーティングテーブルに EIGRP ルートがインストールされる前）に確立されています。

アクション6:確立された接続をクリアします。

この場合、パケットは確立された接続に一致し、誤った出力インターフェイスにルーティングされます。これによりループが発生します。これは、ファイアウォールの次の動作順序が原因です。

1. 確立された接続のルックアップ（これは、グローバル ルーティング テーブルのルックアップよりも優先されます）

2. ネットワークアドレス変換（NAT）のルックアップ（UN-NAT（宛先 NAT）フェーズは、PBR およびルートのルックアップよりも優先されます）

3. ポリシーベース ルーティング（PBR）

4. グローバル ルーティング テーブルのルックアップ

接続は決してタイムアウトしない（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）] に移動し、値を設定します。

フローティング接続タイムアウトの詳細については、コマンドリファレンスを参照してください。

https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/T-Z/asa-command-ref-T-Z.html#pgfId-1649892

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 インターフェイスで取得されたキャプチャを示しています。

キー ポイント：

1. TCP 3 ウェイハンドシェイクが存在します。

2. SSL ネゴシエーションが開始されています。クライアントが Client Hello メッセージを送信しています。

3. クライアントに送信された TCP ACK が存在します。

4. クライアントに送信された TCP RST が存在します。

次の図は、NGFW の OUTSIDE インターフェイスで取得されたキャプチャを示しています。

キー ポイント：

1. TCP 3 ウェイハンドシェイクが存在します。

2. SSL ネゴシエーションが開始されています。クライアントが Client Hello メッセージを送信しています。

3. ファイアウォールからサーバーに送信された TCP 再送信が存在します。

4. サーバーに送信された TCP RST が存在します。

推奨される対処法

このセクションに示されているアクションは、問題を絞り込むことを目的としています。

アクション1:追加のキャプチャを取得します。

サーバーで取得したキャプチャから、サーバーが破損した TCP チェックサムをともなう TLS Client Hello を受信しており、それらをサイレントにドロップしたことが分かります（クライアントへの TCP RST またはその他の応答パケットは存在しません）。

すべてを組み合わせると、次のように結論付けられます。

この場合、理解するために、Wiresharkで「Validate the TCP checksum if possible」オプションを有効にする必要があります。次の図のように、[編集（Edit）] > [設定（Preferences）] > [プロトコル（Protocols）] > [TCP] に移動します。

この場合、全体像を把握するためにキャプチャを並べて配置すると便利です。

キー ポイント：

1. TCP 3 ウェイハンドシェイクが存在します。IP ID は同じです。これは、フローがファイアウォールによってプロキシされなかったことを意味します。

2. TLS Client Helloは、IP ID 12083のクライアントから送信されます。パケットはファイアウォールによってプロキシされ（この場合、ファイアウォールはTLS復号化ポリシーで設定されています）、IP IDは52534に変更されます。また、パケットのTCPチェックサムが破損します(後で修正されたソフトウェア不具合が原因)。

3. ファイアウォールはTCPプロキシモードで、クライアント（サーバをスプーフィングする）にACKを送信します。

4. ファイアウォールはサーバーから TCP ACK パケットを受信しておらず、TLS Client Hello メッセージを再送信しています。これも、ファイアウォールがアクティブ化した TCP プロキシモードが原因です。

5. 約 30 秒後、ファイアウォールは中断し、TCP RST をクライアントに送信しています。

6. ファイアウォールがサーバーに向けて TCP RST を送信しています。

次のドキュメントを参照してください。

Firepower の TLS/SSL ハンドシェイク処理

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セッションを確認するには、Wiresharkでtcp.flags==0x2表示フィルタを使用します。これにより、キャプチャされたすべての TCP SYN パケットがフィルタ処理されます。

ヒント:SSL Client HelloのServer Nameフィールドを列として適用します。

ヒント：この表示フィルタを適用すると、Client Helloメッセージssl.handshake.type == 1だけが表示されます。

注：本書の執筆時点では、スマートライセンシングポータル(tools.cisco.com)は72.163.4.38、173.37.145.8のIPを使用しています。

次の図のように、いずれかの TCP フローを追跡します（[追跡（Follow）] > [TCPストリーム（TCP Stream）]）。

キー ポイント：

1. TCP 3 ウェイハンドシェイクが存在します。

2. クライアント（FMC）が SSL Client Hello メッセージをスマートライセンスポータルに送信しています。

3. SSLセッションIDは0です。これは、セッションが再開されていないことを意味します。

4. 宛先サーバーが Server Hello、Certificate、および Server Hello Done メッセージで応答しています。

5. クライアントは、「不明なCA」に関するSSL致命的アラートを送信します。

6. クライアントが TCP RST を送信してセッションを終了しています。

7. TCP セッションの時間は全体（確立から終了まで）で約 0.5 秒でした。

サーバーの証明書（Certificate） を選択し、[発行者（issuer）] フィールドを展開して、commonName を表示します。この場合、この共通名は、中間者（MITM）を実行しているデバイスを示しています。

次の図は、このことを示しています。

推奨される対処法

このセクションに示されているアクションは、問題を絞り込むことを目的としています。

アクション1:追加のキャプチャを取得します。

中継ファイアウォールデバイスでキャプチャを取得します。

CAPI の内容は、次のとおりです。

CAPO の内容は、次のとおりです。

これらのキャプチャから、中継ファイアウォールがサーバー証明書を変更（MITM）したことが分かります。

アクション2:デバイスログを確認します。

このドキュメントで説明するように、FMC TS バンドルを収集できます。

https://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html

この場合、/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 インターフェイスでのキャプチャには、次の内容が含まれています。

キー ポイント：

1. ルータはIPv6ネイバー送信要求メッセージを送信し、アップストリームデバイスのMACアドレス(IP fc00:1:1:1::1)を要求します。

2. ファイアウォールが IPv6 の Neighbor Advertisement で応答しています。

3. ルータが ICMP エコー要求を送信しています。

4. ファイアウォールはIPv6ネイバー送信要求メッセージを送信し、ダウンストリームデバイスのMACアドレス(fc00:1:1:1::100)を要求します。

5. ルータが IPv6 の Neighbor Advertisement で応答しています。

6. ルータが追加の IPv6 ICMP エコー要求を送信しています。

ファイアウォールの OUTSIDE インターフェイスでのキャプチャには、次の内容が含まれています。

キー ポイント：

1. ファイアウォールは、アップストリームデバイスのMACアドレス(IP fc00:1:1:2::2)を要求するIPv6ネイバー送信要求メッセージを送信します。

2. ルータが IPv6 の Neighbor Advertisement で応答しています。

3. ファイアウォールが IPv6 ICMP エコー要求を送信しています。

4. アップストリームデバイス（ルータfc00:1:1:2::2）は、IPv6アドレスfc00:1:1:1::100のMACアドレスを要求するIPv6ネイバー送信要求メッセージを送信します。

5. ファイアウォールが追加の IPv6 ICMP エコー要求を送信しています。

6. アップストリームルータは、追加の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 キャプチャの内容は、次のとおりです。

重要なポイント：

1. ルータは、アップストリームデバイスのMACアドレス(IP fc00:1:1:1::1)を要求するIPv6ネイバー送信要求メッセージを送信します。

2. ファイアウォールが IPv6 の Neighbor Advertisement で応答しています。

3. ルータが ICMP エコー要求を送信し、エコー応答を受信しています。

CAPO の内容：

キー ポイント：

1. ファイアウォールは、アップストリームデバイスのMACアドレス(IP fc00:1:1:2::2)を要求するIPv6ネイバー送信要求メッセージを送信します。

2. ファイアウォールが IPv6 の Neighbor Advertisement で応答しています。

3. ファイアウォールが ICMP エコー要求を送信しています。

4. ルータは、ダウンストリームデバイスのMACアドレス(IP fc00:1:1:1::1)を要求するIPv6ネイバー送信要求メッセージを送信します。

5. ファイアウォールが IPv6 の Neighbor Advertisement で応答しています。

6. ファイアウォールが 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 インターフェイスでのキャプチャには、次の内容が含まれています。

キー ポイント：

1. ファイアウォールが 192.168.0.x/24 ネットワーク内の IP に関するさまざまな ARP 要求を受信しています。

2. ファイアウォールが、それらすべて（プロキシ 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 の認証とデータ暗号化のログイン情報を持っていたため、次のアクションプランが提案されました。

1. SNMP パケットのキャプチャを取得します。

2. キャプチャを保存し、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

キー ポイント：

1. SNMP 送信元および宛先のアドレス/ポートです。

2. privKey が Wireshark に認識されていないため、SNMP プロトコル PDU を復号できませんでした。

3. 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 が表示されます。

キー ポイント：

1. SNMP モニタリングツールが、SNMP getBulkRequest を使用して、親 OID 1.3.6.1.4.1.9.9.221.1 および関連する OID を照会し、処理しています。

2. 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を人間が読める形式で表示するには、次の手順を実行します。

1. 次の図のように、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 占有は見られず、オーバーランのレートは大幅に減少しています。

関連情報

- Cisco Firepower Management Center のコンフィギュレーション ガイド

- Firepower Threat Defense アクセス コントロール ポリシー ルール アクションの明確化

- 『Work with Firepower Threat Defense Captures and Packet Tracer』

- 「Learn Wireshark」