分析Firepower防火牆捕獲以排除網路故障

簡介

本文件說明各種封包擷取分析技術，旨在有效對網路問題進行疑難排解。  

必要條件

需求

思科建議您瞭解以下主題：

• Firepower平台架構
• NGFW日誌
• NGFW Packet Tracer

此外，在開始分析資料包捕獲之前，強烈建議滿足以下要求：

• 瞭解協定操作- 如果您不瞭解捕獲的協定的工作原理，請勿開始檢查資料包捕獲。
• 瞭解拓撲 -您必須端到端瞭解傳輸裝置。如果不可行，您至少必須知道上游和下游裝置。
• 瞭解裝置- 您必須瞭解裝置如何處理資料包、所涉及的介面（入口/出口）、裝置架構是什麼，以及各個捕獲點是什麼。
• 瞭解配置- 您必須瞭解資料包流應該如何由裝置根據以下方面來處理：
  • 路由/輸出介面
  • 應用的策略
  • 網路位址翻譯(NAT)
• 瞭解可用工具- 建議準備使用捕獲和其他工具和技術（例如日誌記錄和跟蹤器），如果需要，請將其與捕獲的資料包相關聯。

採用元件

本文中的資訊係根據以下軟體和硬體版本：

• 大多數場景基於運行FTD軟體6.5.x的FP4140。
• 運行軟體6.5.x的FMC。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

資料包捕獲是當今最被忽視的故障排除工具之一。每天，Cisco TAC可解決捕獲的資料分析方面的許多問題。

本文檔的目標是幫助網路和安全工程師主要根據資料包捕獲分析來辨識和排除常見的網路問題。

本文檔中顯示的所有場景都基於在思科技術支援中心(TAC)中看到的真實使用者案例。

本檔案介紹從思科下一代防火牆(NGFW)的角度擷取封包，但相同的概念也可套用於其他裝置型別。

如何收集和導出NGFW產品系列的捕獲資訊？

如果是Firepower裝置(1xxx、21xx、41xx、93xx)和Firepower威脅防禦(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、3和4中捕獲的資料包具有虛擬網路標籤(VNTag)。

註：FXOS機箱級捕獲僅在FP41xx和FP93xx平台上可用。FP1xxx和FP21xx不提供此功能。

啟用和收集FTD Lina擷取

主要擷取點：

• 入口介面
• 輸出介面
• 加速安全路徑(ASP)

您可以使用Firepower管理中心使用者介面(FMC UI)或FTD CLI來啟用和收集FTD Lina擷取。

在內部介面上從CLI啟用捕獲：

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

導航到expert模式，找到儲存的捕獲，並將其複製到/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

選擇高級故障排除：

指定捕獲檔名並選擇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

疑難排解

案例 1.輸出介面上沒有TCP SYN

拓撲如下圖所示：

問題描述： HTTP無法運作

受影響的流程：

源IP：192.168.0.100

Dst 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三次握手。
2. 雙向資料交換。
3. 資料包之間無延遲（基於資料包之間的時間差）。
4. 源MAC是正確的下游裝置。

在NGFW外部介面上捕獲的流量如下圖所示：

重點：

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

這是CAPI捕獲在Wireshark中的影象：

重點：

1. 只看到TCP SYN資料包（無TCP三次握手）。
2. 無法建立2個TCP作業階段（來源連線埠3171和3172）。來源使用者端重新傳送TCP SYN封包。Wireshark將這些重新傳輸的資料包標識為TCP重新傳輸。
3. TCP重新傳輸每―3秒，然後每6秒執行一次。
4. 來源MAC位址來自正確的下游裝置。

根據2條捕獲資訊，可以得出結論：

• 特定5元組(src/dst IP、src/dst port、protocol)的資料包到達預期介面(INSIDE)上的防火牆。
• 封包不會離開預期介面(OUTSIDE)上的防火牆。

建議的動作

本節列出的動作旨在進一步縮小問題範圍。

行動1.檢查模擬資料包的跟蹤。

使用Packet Tracer工具檢視防火牆應如何處理資料包。如果防火牆訪問策略丟棄資料包，則模擬資料包的跟蹤看起來與以下輸出類似：

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上設定系統日誌，請查閱本檔案：

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

強烈建議為FTD Lina記錄設定外部系統日誌伺服器。如果未配置遠端系統日誌伺服器，請在進行故障排除時啟用防火牆上的本地緩衝區日誌。本示例中顯示的日誌配置是一個很好的起點：

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）增加到最多32 MB的值（緩衝區選項）。最後，從FTD版本6.3開始，檔案大小選項可讓您設定最高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捕獲中未提及丟棄的原因。請記住，只能在一個位置跟蹤資料包（入口介面或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 Lina連線表。

有時您會期望資料包輸出介面「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）。
• 根據來源/目的地連線埠，輸入介面為內部，輸出介面為dmz。

您可以在以下圖片中看到此內容：

注意：由於所有FTD介面的安全級別均為0，show conn輸出中的介面順序取決於介面號。具體而言，具有更高vpif-num（虛擬平台介面號）的介面被選為inside，而具有更低vpif-num的介面被選為outside。您可以使用show interface detail命令來檢視介面vpif值。相關增強，思科漏洞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

此外，如果是Network Address Translation，show conn long 還會在括弧內顯示NATed 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，即使無法到達下一跳，並且防火牆以靜默方式丟棄資料包！在這種情況下，還必須檢查Packet Tracer工具，因為它提供了更精確的輸出：

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 命令輸出顯示NATed 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命令輸出並驗證介面狀態。

案例 2.使用者端的TCP SYN、伺服器的TCP RST

下圖顯示拓撲：

問題描述： HTTP無法運作

受影響的流程：

源IP：192.168.0.100

Dst 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>

下圖顯示了CAPI在Wireshark中的捕獲。

重點：

1. 來源傳送TCP SYN封包。
2. TCP RST會傳送至來源。
3. 來源重新傳輸TCP SYN封包。
4. MAC位址正確（在輸入封包上，來源MAC位址屬於下游路由器，目的地MAC位址屬於防火牆內部介面）。

下圖顯示了CAPO在Wireshark中的捕獲：

重點：

1. 來源傳送TCP SYN封包。
2. TCP RST到達外部介面。
3. 來源重新傳輸TCP SYN封包。
4. MAC地址正確（在出口資料包上，防火牆OUTSIDE為源MAC，上游路由器為目的MAC）。

根據2條捕獲資訊，可以得出結論：

• 客戶端和伺服器之間的TCP三次握手未完成
• 到達防火牆輸出介面的TCP RST
• 防火牆與適當的上游和下游裝置「通訊」（基於MAC地址）

建議的動作

本節列出的動作旨在進一步縮小問題範圍。

行動1.檢查傳送TCP RST的源MAC地址。

確認TCP SYN封包中顯示的目的地MAC與TCP RST封包中顯示的來源MAC相同。

此檢查的目的是確認兩件事：

• 驗證沒有非對稱流。
• 驗證MAC是否屬於預期的上行裝置。

行動2.比較入口和出口資料包。

目視比較Wireshark上的2個資料包，驗證防火牆沒有修改/損壞這些資料包。某些預期差異會突出顯示。

重點：

1. 時間戳不同。另一方面，這種差異必須小而合理。這取決於應用到資料包的功能和策略檢查以及裝置上的負載。
2. 資料包的長度不同，尤其是當只有一側防火牆增加/刪除了dot1Q報頭時。
3. MAC地址不同。
4. 如果捕獲是在子介面上進行的，則可以使用dot1Q報頭。
5. 在資料包應用NAT或埠地址轉換(PAT)時，IP地址是不同的。
6. 如果將NAT或PAT應用於資料包，則源埠或目標埠會有所不同。
7. 如果停用Wireshark Relative Sequence Number選項，您會看到TCP序列號/確認號由於初始序列號(ISN)隨機化而被防火牆修改。
8. 某些TCP選項可能被覆蓋。例如，防火牆預設會將TCP最大區段大小(MSS)變更為1380，以避免傳輸路徑中的封包分段。

行動3.在目的地進行擷取。

如有可能，在目的地本身進行擷取。如果無法執行此作業，請儘可能將擷取位置靠近目的地。此處的目標是驗證誰傳送了TCP RST（是目標伺服器還是路徑中的其他裝置？）。

案例 3.來自一個終端的TCP三次握手+ RST

下圖顯示拓撲：

問題描述： HTTP無法運作

受影響的流程：

源IP：192.168.0.100

Dst 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三次握手+延遲的RST

防火牆都會擷取CAPI和CAPO包含相同封包，如下圖所示。

重點：

1. TCP三次握手會透過防火牆。
2. 伺服器重新傳輸SYN/ACK。
3. 客戶端重新傳輸ACK。
4. 約20秒後，客戶端放棄並傳送TCP RST。

建議的動作

本節列出的動作旨在進一步縮小問題範圍。

行動1.儘可能在靠近兩個端點的位置捕獲資訊。

防火牆捕獲資訊表明，伺服器未處理客戶端ACK。這是基於以下事實：

• 伺服器重新傳輸SYN/ACK。
• 客戶端重新傳輸ACK。
• 客戶端在任何資料之前傳送TCP RST或FIN/ACK。

伺服器上的擷取顯示問題。TCP三次握手中的客戶端ACK從未到達：

3.2 - TCP三次握手+來自客戶端的延遲FIN/ACK +來自伺服器的延遲RST

防火牆都會擷取CAPI和CAPO包含相同封包，如下圖所示。

重點：

1. TCP三次握手會透過防火牆。
2. 約5秒後，客戶端傳送FIN/ACK。
3. 約20秒後，伺服器放棄並傳送TCP RST。

根據此捕獲，可以推斷出，雖然存在透過防火牆的TCP三次握手，但似乎在一個終端上從未真正完成握手（重新傳輸表明如此）。

建議的動作

與案例3.1相同

3.3 -來自客戶端的TCP三次握手+延遲的RST

防火牆都會擷取CAPI和CAPO包含相同封包，如下圖所示。

重點：

1. TCP三次握手會透過防火牆。
2. 約20秒後，客戶端放棄並傳送TCP RST。

根據這些捕獲，可以得出以下結論：

• 5-20秒後，一個終端放棄並決定終止連線。
  
  

建議的動作

與案例3.1相同

3.4 -來自伺服器的TCP三次握手+立即RST

兩個防火牆都會擷取CAPI和CAPO包含這些封包，如下圖所示。

重點：

1. TCP三次握手會透過防火牆。
2. 在ACK封包之後數毫秒內，伺服器便會發出TCP RST。

建議的動作

動作：儘可能在靠近伺服器的位置進行擷取。

來自伺服器的立即TCP RST可能表示伺服器發生故障或傳送TCP RST的路徑中的裝置。在伺服器自身上進行捕獲並確定TCP RST的源。

案例 4.來自客戶端的TCP RST

下圖顯示拓撲：

問題描述： HTTP無法運作。

受影響的流程：

源IP：192.168.0.100

Dst 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下，導航到編輯>首選項>協定> TCP，然後取消選擇相對序列號選項，如圖所示。

此影像顯示CAPI擷取中第一個流程的內容：

重點：

1. 使用者端傳送TCP SYN封包。
2. 使用者端傳送TCP RST封包。
3. TCP SYN資料包的序列號值等於4098574664。

CAPO捕獲中的相同流包含：

重點：

1. 使用者端傳送TCP SYN封包。防火牆隨機分配ISN。
2. 使用者端傳送TCP RST封包。

根據這兩個擷取，可以得出結論：

• 客戶端和伺服器之間沒有TCP三次握手。
• 有一個來自客戶端的TCP RST。CAPI捕獲中的TCP RST序列號值為1386249853。

建議的動作

本節列出的動作旨在進一步縮小問題範圍。

行動1.在使用者端上執行擷取。

根據在防火牆上收集的擷取，有強烈的不對稱流量指示。這是基於使用者端傳送值為1386249853的TCP RST （隨機ISN）這一事實：

重點：

1. 使用者端傳送TCP SYN封包。序列號為4098574664，與防火牆INSIDE介面(CAPI)上看到的序列號相同
2. 有一個ACK號為1386249853的TCP SYN/ACK（由於隨機化，預計會如此）。防火牆擷取中看不到此封包
3. 客戶端傳送一個TCP RST，因為它預期的SYN/ACK的ACK號值為4098574665，但它收到的值為1386249853

其視覺化結果為：

行動2.檢查客戶端和防火牆之間的路由。

確認：

• 捕獲中看到的MAC地址是預期的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傳輸很慢。雖然兩台主機之間的最低頻寬(BW)為100 Mbps，但傳輸速度不超過5 Mbps。

同時，主機10.11.2.124和172.25.18.134之間的傳輸速度要高得多。

背景理論：

單個TCP流的最大傳輸速度由頻寬延遲產品(BDP)確定。使用的公式如下圖所示：

有關BDP的更多詳細資訊，請點選此處檢視資源：

• 為什麼即使鏈路為1Gbps，您的應用程式也只使用10Mbps？
• BRKSEC-3021 -高級-最大化防火牆效能

案例 1.傳輸緩慢

下圖顯示拓撲：

受影響的流程：

源IP：10.11.4.171

Dst IP：10.77.19.11

通訊協定：SFTP（透過SSH的FTP）

擷取分析

在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分流器裝置。此問題已記錄在思科漏洞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檢視以顯示自上次顯示資料包以來經過的秒數。這可簡化RTT的計算：

RTT可以透過增加2個資料包交換（一個指向源，一個指向目的）之間的時間值來計算。在這種情況下，封包#2會顯示防火牆與傳送SYN/ACK封包（伺服器）的裝置之間的RTT。Packet #3顯示防火牆和傳送ACK資料包的裝置（客戶端）之間的RTT。將兩個數字相加，可以很好地估計端到端RTT：

RTT ≈ 80毫秒

TCP窗口大小計算

展開TCP資料包，展開TCP報頭，選擇Calculated window size並選擇Apply as Column：

檢查Calculated window size value列，檢視TCP會話期間的最大窗口大小值。您也可以選取欄名稱並排序值。

如果測試檔案下載(server > client)，則必須檢查伺服器通告的值。伺服器通告的最大窗口大小值決定了達到的最大傳輸速度。

在這種情況下，TCP窗口大小為≈ 50000位元組

根據這些值並使用「頻寬延遲乘積」公式，您可以得到在這些條件下可以達到的最大理論頻寬：50000*8/0.08 = 5 Mbps的最大理論頻寬。

這與客戶端在這種情況下遇到的情況相符。

仔細檢查TCP三次握手。兩端（更重要的是伺服器）都會通告視窗縮放值0，這表示2^0 = 1 （無視窗縮放）。這會對傳輸率產生負面影響：

此時，需要在伺服器上執行捕獲，確認是通告window scale = 0的伺服器，然後重新配置它（請檢視伺服器文檔以瞭解如何執行此操作）。

案例 2.快速傳輸

現在，讓我們來檢查好的方案（透過同一網路的快速傳輸）：

拓撲：

利息流向：

源IP：10.11.2.124

Dst IP：172.25.18.134

通訊協定：SFTP（透過SSH的FTP）

在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最大理論傳輸速度

案例 6.緩慢TCP傳輸（案例2）

問題描述：透過防火牆的FTP檔案傳輸（下載）速度很慢。

下圖顯示拓撲：

受影響的流程：

源IP：192.168.2.220

Dst 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資料封包，並依照FTD內部擷取(CAPI)上的FTP資料通道操作：

FTP-DATA流內容：

CAPO捕獲內容：

重點：

1. 存在TCP亂序(OOO)封包。
2. 存在TCP重新傳輸。
3. 存在資料包丟失（丟棄的資料包）的指示。

提示：在導航到檔案>導出指定資料包時儲存捕獲。然後僅儲存顯示的資料包範圍

建議的動作

本節列出的動作旨在進一步縮小問題範圍。

行動1.確定資料包丟失位置。

在這種情況下，您必須同時捕獲資料包，並使用分治法確定導致資料包丟失的網路段。從防火牆的角度來看，主要有3種情況：

1. 封包遺失是由防火牆本身造成的。
2. 封包遺失是發生在防火牆裝置的下游（從伺服器到使用者端的方向）。
3. 封包遺失是在防火牆裝置的上游（從使用者端到伺服器的方向）造成的。

防火牆導致的資料包丟失：為了確定資料包丟失是否由防火牆引起，需要將入口捕獲與出口捕獲進行比較。有很多方法可以比較2個不同的捕獲。本節將介紹執行此任務的一種方法。

比較2個擷取專案以辨識封包遺失的程式

步驟 1.確保2個捕獲包含來自同一時間窗口的資料包。這表示一個擷取中一定沒有封包是在另一個擷取之前或之後擷取。有幾種方法可以做到這一點：

• 檢查第一個和最後一個資料包IP標識(ID)值。
• 檢查第一個和最後一個資料包的時間戳值。

在本例中，您可以看到每個捕獲的第一個資料包具有相同的IP ID值：

萬一它們不同：

1. 比較每個捕獲的第一個資料包的時間戳。
2. 從具有最新Timestamp的捕獲得到過濾器，將Timestamp過濾器從=更改為>=（第一個資料包）和<=(最後一個資料包)更改，例如：

 (frame.time >= "Oct 16， 2019 16:13:43.244692000") &&(frame.time <= "Oct 16， 2019 16:20:21.785130000")

  3. 將指定的資料包導出到新捕獲，選擇檔案>導出指定的資料包，然後儲存顯示的資料包。此時，兩個捕獲必須包含覆蓋同一時間窗口的資料包。現在您可以開始比較2個擷取。

步驟 2.指定哪個資料包欄位用於比較2個捕獲。可以使用的欄位範例：

• IP辨識
• RTP序列號
• ICMP序列號

建立每個捕獲的文本版本，其中包含您在步驟1中指定的每個資料包的欄位。為此，請僅保留相關的列，例如，如果要根據IP標識比較資料包，請修改捕獲，如圖所示。

結果：

步驟 3.建立擷取的文字版本(「檔案>匯出封包分割>以純文字...」)，如下圖所示：

取消選中Include column headings和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重傳。具體而言，它是從客戶端傳送到伺服器的TCP SYN資料包，用於被動模式下的FTP資料。因為使用者端重新傳送封包，而且您可以看到初始的SYN (封包#1)，封包在上游遺失到防火牆。

在這種情況下，有可能是SYN資料包到達了伺服器，但SYN/ACK資料包在返回途中丟失：

2. 從伺服器發出資料包，Wireshark發現未看到/捕獲上一個資料段。由於未捕獲的資料包從伺服器傳送到客戶端，並且在防火牆捕獲中看不到，因此意味著資料包在伺服器和防火牆之間丟失。

這表示FTP伺服器和防火牆之間發生封包遺失。

行動2.取得其他擷取。

在終端處執行其他捕獲和捕獲。嘗試應用分治法，進一步隔離導致資料包丟失的問題分段。

重點：

1. 接收方（本例中為FTP客戶端）跟蹤傳入的TCP序列號。如果檢測到資料包被丟失（已跳過預期序列號），則生成ACK資料包，其中包含ACK='已跳過預期序列號'。在本示例中，Ack=2224386800。
2. Dup ACK會觸發TCP快速重新傳輸（收到重複的ACK後，在20毫秒內重新傳輸）。

重複確認(Duplicate ACK)是什麼意思？

• 有幾個ACK重複，但沒有實際重新傳輸，表明更有可能出現資料包到達順序混亂。
• 重複的ACK和實際的重新傳輸表明存在一定程度的資料包丟失。

行動3.計算傳輸資料包的防火牆處理時間。

在兩個不同的介面上應用相同的捕獲：

firepower# capture CAPI buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220 
firepower# capture CAPI interface OUTSIDE

導出捕獲檢查入口資料包與出口資料包之間的時間差異


案例 7.TCP連線問題（封包損毀）

問題描述：

無線使用者端(192.168.21.193)會嘗試連線到目的地伺服器(192.168.14.250 - HTTP)，且有兩種不同的情境：

• 當客戶端連線到存取點(AP) 'A'時，HTTP連線不起作用。
• 使用者端連線到存取點(AP) 'B'時，HTTP連線就會運作。

下圖顯示拓撲：

受影響的流程：

源IP：192.168.21.193

Dst 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外部介面的擷取。

重點：

1. 2個捕獲幾乎完全相同（考慮ISN隨機化）。
2. 沒有資料包丟失的跡象。
3. 無亂序(OOO)封包
4. 有3個HTTP GET請求。第一個獲得404「未找到」，第二個獲得200「確定」，第三個獲得304「未修改」重定向消息。

捕獲-已知故障情況：

輸入擷取(CAPI)內容。

重點：

1. 存在TCP三次握手。
2. 存在TCP重新傳輸和資料包丟失指示。
3. 有一個資料包(TCP ACK)被Wireshark辨識為格式錯誤。

此影像顯示出口擷取(CAPO)內容。

重點：

這2個擷取幾乎完全相同（請考慮ISN隨機化）：

1. 存在TCP三次握手。
2. 存在TCP重新傳輸和資料包丟失指示。
3. 有一個資料包(TCP ACK)被Wireshark辨識為格式錯誤。

檢查格式錯誤的資料包：

重點：

1. 資料包被辨識為Wireshark格式錯誤。
2. 其長度為2個位元組。
3. 有2個位元組的TCP負載。
4. 負載是額外的4個零(00 00)。
   
   

建議的動作

本節列出的動作旨在進一步縮小問題範圍。

行動1.獲取其他捕獲。在終端包括捕獲，如果可能，請嘗試應用分治法隔離資料包損壞的來源，例如：

在本例中，交換機「A」介面驅動程式增加了2個額外位元組，解決方案是更換導致損壞的交換機。

案例 8.UDP連線問題（缺少資料包）

問題描述：在目標Syslog伺服器上看不到系統日誌(UDP 514)消息。

下圖顯示拓撲：

受影響的流程：

源IP：192.168.1.81

Dst 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-turn)。
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.使用Packet Tracer。

由於封包沒有透過防火牆LINA引擎，因此您無法執行即時追蹤（擷取並追蹤），但可以使用packet Tracer追蹤模擬封包：

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分鐘時，系統日誌客戶端持續傳送資料包），因此需要手動清除連線：

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流量而言尤其如此。導航到裝置>平台設定>超時並設定值：

有關浮動連線超時的詳細資訊，請參閱命令參考：

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

案例 9.HTTPS連線問題（案例1）

問題描述：無法建立使用者端192.168.201.105和伺服器192.168.202.101之間的HTTPS通訊

下圖顯示拓撲：

受影響的流程：

源IP：192.168.201.111

Dst 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三次握手。
2. SSL協商開始。客戶端傳送客戶端Hello消息。
3. 向客戶端傳送了TCP ACK。
4. 有一個傳送給客戶端的TCP RST。

此影像顯示擷取自NGFW外部介面的擷取。

重點：

1. 存在TCP三次握手。
2. SSL協商開始。客戶端傳送客戶端Hello消息。
3. 存在從防火牆向伺服器傳送的TCP重新傳輸。
4. 有一條TCP RST傳送到伺服器。

建議的動作

本節列出的動作旨在進一步縮小問題範圍。

行動1.獲取其他捕獲。

在伺服器上進行的擷取顯示伺服器收到的TLS使用者端Hello含有損毀的TCP總和檢查碼，然後將其靜默捨棄（沒有傳送至使用者端的TCP RST或任何其他回覆封包）：

當你把所有東西放在一起時：

在這種情況下，為了瞭解情況，需要在Wireshark上啟用Validate the TCP checksum if possible選項。導航到Edit > Preferences > Protocols > TCP，如下圖所示。

在這種情況下，將擷取並排顯示以全面瞭解內容會很有幫助：

重點：

1. 存在TCP三次握手。IP ID相同。這表示流量並未受到防火牆的代理。
2. TLS客戶端Hello來自具有IP ID 12083的客戶端。資料包由防火牆代理（在本例中防火牆配置了TLS解密策略），並且IP ID更改為52534。此外，封包TCP總和檢查碼已損毀（因為軟體瑕疵稍後被修正）。
3. 防火牆處於TCP代理模式並向客戶端傳送ACK（這將欺騙伺服器）。
   
   
   
   
4. 防火牆沒有收到來自伺服器的任何TCP ACK資料包，而是重新傳輸TLS客戶端Hello消息。這也是由於防火牆啟動的TCP代理模式所致。
5. 在大約30秒後，防火牆會放棄並向客戶端傳送TCP RST。
6. 防火牆會向伺服器傳送TCP RST。

供參考：

Firepower TLS/SSL握手處理

案例 10.HTTPS連線問題（案例2）

問題說明：FMC智慧許可證註冊失敗。

下圖顯示拓撲：

受影響的流程：

源IP：192.168.0.100

Dst： 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客戶端Hello應用伺服器名稱欄位作為列。

提示：應用此顯示過濾器以僅檢視客戶端Hello消息ssl.handshake.type == 1

注意：撰寫本文時，智慧許可門戶(tools.cisco.com)使用以下IP：72.163.4.38、173.37.145.8

按照其中一個TCP流操作(Follow > TCP Stream)，如圖所示。

重點：

1. 存在TCP三次握手。
2. 使用者端(FMC)將SSL使用者端Hello訊息傳送至智慧授權入口網站。
3. SSL會話ID為0。這意味著它不是續會。
4. 目的伺服器會回覆伺服器Hello、證書和伺服器Hello Done消息。
5. 使用者端傳送與「不明CA」有關的SSL嚴重警示。
6. 使用者端傳送TCP RST以關閉作業階段。
7. 整個TCP會話持續時間（從建立到關閉）約為0.5秒。

選擇Server 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可以成功註冊到智慧許可雲。

案例 11.IPv6連線問題

問題描述：內部主機（位於防火牆的INSIDE介面之後）無法與外部主機（位於防火牆的OUTSIDE介面之後的主機）通訊。

下圖顯示拓撲：

受影響的流程：

源IP：fc00:1：1:1：：100

Dst 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鄰居通告做出響應。
3. 路由器傳送ICMP回應請求。
4. 防火牆傳送IPv6鄰居請求消息，並要求下游裝置的MAC地址(fc00:1：1:1：：100)。
5. 路由器以IPv6鄰居通告做出響應。
6. 路由器傳送其他IPv6 ICMP回應請求。

防火牆OUTSIDE介面上的捕獲包含：

重點：

1. 防火牆傳送IPv6鄰居請求消息，詢問上游裝置的MAC地址(IP fc00:1：1:2：：2)。
2. 路由器以IPv6鄰居通告做出響應。
3. 防火牆傳送IPv6 ICMP回應請求。
4. 上游裝置（路由器fc00:1：1:2：：2）傳送一條IPv6鄰居請求消息，請求獲取IPv6地址fc00:1：1:1：：100的MAC地址。
5. 防火牆會傳送額外的IPv6 ICMP回應請求。
6. 上游路由器傳送一條額外的IPv6鄰居請求消息，該消息要求IPv6地址fc00:1：1:1：：100的MAC地址。

第四點很有意思。通常，上游路由器請求防火牆外部介面的MAC (fc00:1：1:2：：2)，但實際上它請求的是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. 路由器傳送IPv6鄰居請求消息，詢問上游裝置的MAC地址(IP fc00:1：1:1：：1)。
2. 防火牆以IPv6鄰居通告做出響應。
3. 路由器傳送ICMP Echo請求並獲得應答。

CAPO內容：

重點：

1. 防火牆傳送IPv6鄰居請求消息，詢問上游裝置的MAC地址(IP fc00:1：1:2：：2)。
2. 防火牆以IPv6鄰居通告做出響應。
3. 防火牆傳送ICMP回應請求。
4. 路由器傳送IPv6鄰居請求消息，詢問下游裝置的MAC地址(IP fc00:1：1:1：：1)。
5. 防火牆以IPv6鄰居通告做出響應。
6. 防火牆傳送ICMP回應請求並獲得回應應答。

案例 12.間歇性連線問題（ARP中毒）

問題描述：內部主機(192.168.0.x/24)與同一子網中的主機之間出現間歇性連線問題

下圖顯示拓撲：

受影響的流程：

源IP：192.168.0.x/24

Dst IP：192.168.0.x/24

協定：任意

內部主機的ARP快取似乎已中毒：

擷取分析

在FTD LINA引擎上啟用擷取

此捕獲僅捕獲內部介面上的ARP資料包：

firepower# capture CAPI_ARP interface INSIDE ethernet-type arp

擷取-無法運作的案例：

防火牆INSIDE介面上的捕獲包含。

重點：

1. 防火牆接收192.168.0.x/24網路內IP的各種ARP請求
2. 防火牆會以自己的MAC位址回應所有封包（代理ARP）

建議的動作

本節列出的動作旨在進一步縮小問題範圍。

行動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

案例 13.辨識導致CPU佔用的SNMP物件辨識碼(OID)

此案例示範如何根據對SNMP版本3 (SNMPv3)封包擷取的分析，將某些用於記憶體輪詢的SNMP OID辨識為CPU存取（效能問題）的根本原因。

問題描述：資料介面上的超載持續增加。進一步的研究表明，也有CPU暫掛（由SNMP進程引起）是介面超負荷運行的根本原因。

故障排除過程中的下一步是確定由SNMP進程引起的CPU佔用問題的根本原因，特別是縮小問題的範圍以確定SNMP對象識別符號(OID)，在輪詢時，OID可能會導致CPU佔用問題。

目前，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 host配置的介面上配置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. 無法解碼SNMP協定PDU，因為privKey對Wireshark未知。
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資料包，然後導航到協定首選項>使用者表，如下圖所示：

在「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對象導航器顯示OID 1.3.6.1.4.1.9.9.221.1屬於名為CISCO-ENHANCED-MEMPOOL-MIB的管理資訊庫(MIB)，如下圖所示：

要在Wireshark中以可讀格式顯示OID，請執行以下操作：

1. 下載MIB CISCO-ENHANCED-MEMPOOL-MIB及其依賴項，如圖所示：

2. 在Wireshark的編輯>首選項>名稱解析窗口中，會選中啟用OID解析。在SMI（MIB和PIB路徑）窗口中，使用下載的MIB和SMI（MIB和PIB模組）指定資料夾。CISCO-ENHANCED-MEMPOOL-MIB會自動增加到模組清單中：

 3. 重新啟動Wireshark後，OID解析將啟用：

根據擷取檔案的解密輸出，SNMP監控工具會定期（10秒間隔）輪詢有關FTD上記憶體集區使用率的資料。如TechNote文章ASA SNMP輪詢記憶體相關統計資訊中所述，使用SNMP輪詢全局共用池(GSP)使用率會導致CPU使用率較高。在本例中，從捕獲資訊可以清楚地看到，作為SNMP getBulkRequest基元的一部分，定期輪詢全局共用池利用率。

為了將SNMP進程導致的CPU佔用減到最小，建議遵循本文中提到的SNMP CPU佔用緩解步驟，並避免輪詢與GSP相關的OID。如果沒有與GSP相關的OID的SNMP輪詢，則不會觀察到由SNMP進程引起的CPU掛載，並且會顯著降低超載率。

相關資訊

• Cisco Firepower管理中心配置指南
• 釐清 Firepower Threat Defense 存取控制原則規則動作
• 使用Firepower威脅防禦捕獲和Packet Tracer
• 瞭解Wireshark