此产品的文档集力求使用非歧视性语言。在本文档集中,非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言,文档中可能无法确保完全使用非歧视性语言。 深入了解思科如何使用包容性语言。
思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言,希望全球的用户都能通过各自的语言得到支持性的内容。 请注意:即使是最好的机器翻译,其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任,并建议您总是参考英文原始文档(已提供链接)。
本文档介绍各种旨在有效排除网络故障的数据包捕获分析技术。 本文档中介绍的所有场景均基于思科技术支持中心(TAC)中看到的真实用户案例。 本文档涵盖从思科下一代防火墙(NGFW)角度捕获的数据包,但相同的概念也适用于其他设备类型。
Cisco 建议您了解以下主题:
此外,在开始分析数据包捕获之前,最好满足以下要求:
本文档中的信息基于以下软件和硬件版本:
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您的网络处于活动状态,请确保您了解所有命令的潜在影响。
数据包捕获是目前最被忽略的故障排除工具之一。每天,Cisco TAC通过分析捕获的数据来解决许多客户问题。本文档的目标是帮助网络和安全工程师主要基于数据包捕获分析来识别和排除常见网络问题。
对于Firepower设备(1xxx、21xx、41xx、93xx)和Firepower威胁防御(FTD)应用,可以如图所示直观地显示数据包处理。
根据图中的架构,FTD捕获可在3个不同位置进行:
此过程在本文档中介绍:
FXOS捕获只能从内部交换机的入口方向捕获,如图所示。
如图所示,每个方向有两个捕获点(由于内部交换机架构)。
第2、3和4点中捕获的数据包具有虚拟网络标记(VNTag)。
注意:FXOS机箱级捕获仅在FP41xx和FP93xx平台上可用。FP1xxx和FP21xx不提供此功能。
主要捕获点:
您可以使用Firepower管理中心用户界面(FMC UI)或FTD CLI启用和收集FTD Lina捕获。
在INSIDE接口上启用从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
导航至专家模式,找到保存的捕获,并将其复制到/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设备并选择“Troubleshoot(故障排除)”图标:
步骤 4
选择高级故障排除:
指定捕获文件名并选择 下载:
有关如何从FMC UI启用/收集捕获的更多示例,请检查本文档:
此处的图中显示了捕获点。
启用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级捕获示例,请检查本文档:
拓扑如下图所示:
问题说明: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接口上捕获的数据:
关键点
在NGFW OUTSIDE接口上拍摄的捕获信息如下图所示:
关键点
捕获 — 非功能方案
在设备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捕获的映像:
关键点
根据2个捕获结果,可以得出以下结论:
本节中列出的操作旨在进一步缩小问题范围。
操作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上配置系统日志,请检查本文档:
强烈建议为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一样,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捕获中未提及丢弃原因。请记住,数据包只能在一个位置跟踪(入口接口或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”传出。 防火墙出口接口的确定基于以下操作顺序:
要检查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
关键点
这可以在以下图像中显示:
注意:由于所有FTD接口的安全级别都为0,因此show conn输出中的接口顺序取决于接口编号。具体而言,具有较高vpif-num(虚拟平台接口编号)的接口被选为内部接口,而具有较低vpif-num的接口被选为外部接口。使用show interface detail命令可以看到interface vpif值。相关增强,CSCvi15290 增强: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在网络地址转换时,在括号中显示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
如输出所示,跟踪显示操作: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数据包有以下可能原因:
可能的原因 |
推荐的操作 |
防火墙访问策略会丢弃数据包。 |
|
捕获过滤器错误。 |
|
数据包被发送到不同的出口接口。 |
如果数据包由于与现有连接匹配而发送到错误接口,请使用命令clear conn address 并指定要清除的连接的5元组。 |
没有通往目的地的路由。 |
|
出口接口上没有ARP条目。 |
|
出口接口关闭。 |
检查防火墙上show interface ip brief命令的输出并验证接口状态。 |
下图显示拓扑:
问题说明: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。
关键点
下图显示了在Wireshark中捕获CAPO的过程:
关键点
根据2个捕获结果,可以得出以下结论:
本节中列出的操作旨在进一步缩小问题范围。
操作1.检查发送TCP RST的源MAC地址。
验证TCP SYN数据包中看到的目的MAC地址与TCP RST数据包中看到的源MAC地址相同。
此检查旨在确认以下两项:
操作2.比较入口和出口数据包。
目视比较Wireshark上的2个数据包,以验证防火墙是否未修改/损坏数据包。突出显示了一些预期差异。
关键点
操作3.在目的地捕获。
如果可能,在目标本身捕获。如果这不可能,请捕获尽可能靠近目的地。此处的目标是验证谁发送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和CAPO包含相同的数据包。
关键点
本节中列出的操作旨在进一步缩小问题范围。
操作1.尽可能靠近两个终端捕获。
防火墙捕获表明服务器未处理客户端ACK。这基于以下事实:
服务器上的捕获显示了问题。来自TCP三次握手的客户端ACK从未到达:
如图所示,防火墙捕获CAPI和CAPO包含相同的数据包。
关键点
根据此捕获,可以得出结论,虽然有TCP三次握手通过防火墙,但它似乎从未在一个终端上实际完成(重新传输表明这一点)。
与案例3.1相同
如图所示,防火墙捕获CAPI和CAPO包含相同的数据包。
关键点
根据这些捕获,可以得出以下结论:
与案例3.1相同
如图所示,两个防火墙都捕获CAPI和CAPO包含这些数据包。
关键点
操作:尽可能靠近服务器捕获。
来自服务器的即时TCP RST可能表示路径中的故障服务器或发送TCP RST的设备。捕获服务器本身并确定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
这些日志表明有TCP RST到达防火墙INSIDE接口
Wireshark中的CAPI捕获:
按照图中所示的第一个TCP数据流。
在Wireshark下,导航到Edit > Preferences > Protocols > TCP,并取消选择Relative sequence numbers选项,如图所示。
下图显示CAPI捕获中第一个流的内容:
关键点
CAPO捕获中的相同流包含:
关键点
根据这两个捕获,可以得出以下结论:
本节中列出的操作旨在进一步缩小问题范围。
操作1.捕获客户端。
根据在防火墙上收集的捕获信息,有强烈的非对称流指示。这基于以下事实:客户端发送值为1386249853的TCP RST(随机ISN):
关键点
这可视化为:
操作2.检查客户端和防火墙之间的路由。
确认:
在某些情况下,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) ...
问题说明:
主机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的更多详细信息,请点击此处查看资源:
下图显示拓扑:
受影响的流:
源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 Tap设备。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显示防火墙与发送SYN/ACK数据包(服务器)的设备之间的RTT。 数据包#3显示防火墙与发送ACK数据包的设备(客户端)之间的RTT。 添加2个数字可以很好地估计端到端RTT:
RTT ≈ 80毫秒
TCP窗口大小计算
展开TCP数据包,展开TCP报头,选择“计算的窗口大小”并选择“应用为列”:
检查Calculated window size value列,查看TCP会话期间的最大窗口大小值。您还可以选择列名并对值进行排序。
如果测试文件下载(服务器>客户端),则必须检查服务器通告的值。服务器通告的最大窗口大小值确定实现的最大传输速度。
在本例中,TCP窗口大小为≈ 50000字节
根据这些值,并使用带宽延迟积公式,您可以获得在以下条件下可以获得的最大理论带宽:50000*8/0.08 = 5 Mbps最大理论带宽。
这与客户端在此情况下的体验相符。
仔细检查TCP三次握手。两端(更重要的是服务器)通告窗口缩放值0,这表示2^0 = 1(无窗口缩放)。 这会对传输速率产生负面影响:
此时,需要在服务器上捕获,确认是通告窗口缩放= 0并重新配置它的人(您可能需要检查服务器文档如何执行此操作)。
现在,我们来了解一下好的场景(通过同一网络快速传输):
拓扑:
兴趣流:
源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最大理论传输速度
问题说明:通过防火墙的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捕获内容:
关键点
提示:在导航到File > Export Specified Packets时保存捕获。然后仅保存显示的数据包范围
本节中列出的操作旨在进一步缩小问题范围。
操作1.确定丢包位置。
在这种情况下,您必须同时捕获并使用分治法确定导致数据包丢失的网段。从防火墙的角度来看,主要有3种场景:
防火墙导致的数据包丢失:为了确定数据包丢失是否由防火墙引起,需要将入口捕获与出口捕获进行比较。比较2个不同捕获的方法有很多种。本节演示了执行此任务的一种方法。
比较2个捕获以识别丢包的过程
步骤1.确保2个捕获包含来自同一时间窗口的数据包。这意味着一个捕获中在另一个捕获之前或之后捕获的数据包必须不存在。有几种方法可以做到这一点:
在本示例中,您可以看到每个捕获的第一个数据包具有相同的IP ID值:
以防它们不同:
(frame.time >= "2019年10月16日16:13:43.244692000")&(frame.time <= "2019年10月16日16:20:21.785130000")
3.将指定的数据包导出到新捕获,选择“文件”>“导出指定的数据包”,然后保存“显示的数据包”。此时,两个捕获都必须包含覆盖同一时间窗口的数据包。现在可以开始比较2个捕获。
步骤2.指定哪个数据包字段用于比较2个捕获。可用字段示例:
创建每个捕获的文本版本,其中包含您在步骤1中指定的每个数据包的字段。为此,请仅保留感兴趣的列,例如,如果要根据IP标识比较数据包,请修改捕获,如图所示。
结果:
步骤3.创建捕获的文本版本(文件>导出数据包断开>为纯文本……),如图所示:
取消选中“包括”列标题和“数据包详细信息”选项,以仅导出显示字段的值,如图所示:
步骤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.执行其他捕获。
在终端上执行其他捕获和捕获。尝试应用分治法进一步隔离导致数据包丢失的有问题数据段。
关键点
重复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
导出捕获检查入口数据包与出口数据包之间的时间差
问题说明:
无线客户端(192.168.21.193)尝试连接到目的服务器(192.168.14.250 - 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接口上捕获的数据。
关键点
捕获 — 非工作场景:
入口捕获(CAPI)内容。
关键点
此图显示出口捕获(CAPO)内容。
关键点
2个捕获几乎相同(考虑ISN随机化):
检查格式错误的数据包:
关键点
本节中列出的操作旨在进一步缩小问题范围。
操作1.执行其他捕获,包括终端捕获,如果可能,尝试应用分治法来隔离数据包损坏的源,例如
在这种情况下,交换机“A”接口驱动程序添加了额外的2个字节,解决方案是更换导致损坏的交换机。
问题说明:目标系统日志服务器上未显示系统日志(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
关键点
操作2.执行机箱级捕获。
连接到Firepower机箱管理器,并在入口接口(本例中为E1/2)和背板接口(E1/9和E1/10)上启用捕获,如图所示:
几秒钟后:
提示:在Wireshark中,排除VN标记的数据包,以消除物理接口级别的数据包重复
之前:
在:
关键点
操作3.使用Packet Tracer。
由于数据包不会通过防火墙LINA引擎,因此您无法执行实时跟踪(捕获w/trace),但您可以使用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
关键点
操作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
要点:
操作6.清除现有连接。
在这种情况下,数据包与已建立的连接匹配,并路由到错误的出口接口,导致环路。这是由于防火墙的操作顺序:
由于连接从不超时(Syslog客户端在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流)的正确解决方案。导航至设备>平台设置>超时并设置值:
您可以在命令参考中找到有关浮动连接超时的更多详细信息:
问题说明:客户端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接口上捕获的数据:
关键点
此图显示了在NGFW OUTSIDE接口上捕获的数据。
关键点
本节中列出的操作旨在进一步缩小问题范围。
操作1.执行其他捕获。
在服务器上捕获的数据显示,服务器收到TLS客户端Hello,其TCP校验和已损坏,并以静默方式丢弃它们(没有TCP RST或任何其他发往客户端的应答数据包):
当您将一切放在一起时:
在这种情况下,要了解发生的情况,需要在Wireshark上启用Validate the TCP checksum ef posible(如果可能)选项。导航至Edit > Preferences > Protocols > TCP,如图所示。
在这种情况下,将捕获信息并排放置以获得完整图景很有帮助:
关键点
参考:
问题说明:FMC智能许可证注册失败。
下图显示拓扑:
受影响的流:
源IP:192.168.0.100
目标:tools.cisco.com
协议:TCP 443(HTTPS)
在FMC管理接口上启用捕获:
尝试重新注册。出现“Error(错误)”消息后,按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中的Server Name字段应用为列。
提示:应用此显示过滤器,仅查看客户端Hello消息ssl.handshake.type == 1
注意:在撰写本文时,智能许可门户(tools.cisco.com)使用以下IP:72.163.4.38,173.37.145.8
按照其中一个TCP流(Follow > TCP Stream),如图所示。
关键点
选择服务器证书并展开颁发者字段以查看commonName。在本例中,公用名称显示执行中间人(MITM)的设备。
此图显示如下:
本节中列出的操作旨在进一步缩小问题范围。
操作1.执行其他捕获。
在传输防火墙设备上捕获:
CAPI显示:
CAPO显示:
这些捕获证明传输防火墙修改了服务器证书(MITM)
操作2.检查设备日志。
您可以收集FMC TS捆绑包,如本文档所述:
在本例中,/dir-archives/var-log/process_stdout.log文件显示如下消息:
SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-ERROR: ch_pf_curl_send_msg[494],
failed to perform, err code 60, err string "SSL peer certificate or SSH remote key was not OK" ...
SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-TRACE: ch_pf_curl_is_cert_issue[514],
cert issue checking, ret 60, url "https://tools.cisco.com/its/
推荐方案
禁用特定流的MITM,以便FMC能够成功注册到智能许可云。
问题说明:内部主机(位于防火墙的INSIDE接口后)无法与外部主机(位于防火墙的OUTSIDE接口后的主机)通信。
下图显示拓扑:
受影响的流:
源IP:fc00:1:1:1::100
目的IP:fc00:1:1:2::2
协议:any
在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接口上的捕获包含:
关键点
防火墙OUTSIDE接口上的捕获包含:
关键点
第4点非常有趣。通常,上游路由器会请求防火墙外部接口(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捕获。
要点:
CAPO内容:
关键点
问题说明:内部主机(192.168.0.x/24)与同一子网中的主机存在间歇性连接问题
下图显示拓扑:
受影响的流:
源IP:192.168.0.x/24
目的IP:192.168.0.x/24
协议:any
内部主机的ARP缓存似乎被毒化:
在FTD LINA引擎上启用捕获
此捕获仅捕获INSIDE接口上的ARP数据包:
firepower# capture CAPI_ARP interface INSIDE ethernet-type arp
捕获 — 非功能场景:
防火墙INSIDE接口上的捕获包含。
关键点
本节中列出的操作旨在进一步缩小问题范围。
操作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.禁用防火墙接口上的代理ARP功能。
如果“no-proxy-arp”关键字无法解决问题,请考虑禁用接口本身的代理ARP。如果是FTD,在撰写本文时,您必须使用FlexConfig并部署以下命令(指定适当的接口名称)。
sysopt noproxyarp INSIDE
本例演示了如何根据对SNMP第3版(SNMPv3)数据包捕获的分析,将内存轮询的某些SNMP OID确定为CPU主机(性能问题)的根本原因。
问题说明:数据接口的超限量持续增加。进一步的故障排除表明,也有CPU主机(由SNMP进程引起)是导致接口超限的根本原因。
故障排除过程的下一步是确定SNMP进程导致的CPU主机的根本原因,特别是缩小问题范围,以识别轮询可能导致CPU主机的SNMP对象标识符(OID)。
目前,FTD LINA引擎不为实时轮询的SNMP OID提供“show”命令。轮询的SNMP OID列表可从SNMP监控工具中检索,但在本例中,存在以下限制因素:
由于FTD管理员拥有SNMP第3版身份验证和数据加密的凭证,因此提出了以下行动计划:
在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捕获。
保存捕获并编辑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 Users)表中,指定了SNMP第3版用户名、身份验证模型、身份验证密码、隐私协议和隐私密码(实际凭据如下所示):
应用SNMP用户设置后,Wireshark显示已解密的SNMP PDU:
关键点
操作2.识别SNMP OID。
SNMP对象导航器显示OID 1.3.6.1.4.1.9.9.221.1属于名为CISCO-ENHANCED-MEMPOOL-MIB的管理信息库(MIB),如图所示:
要在Wireshark中以人可读格式显示OID,请执行以下步骤:
2.在Wireshark的“编辑”>“首选项”>“名称解析”窗口中,选中了“启用OID解析”。在“SMI(MIB和PIB路径)”窗口中,指定包含下载的MIB的文件夹和在SMI(MIB和PIB模块)中。 CISCO-ENHANCED-MEMPOOL-MIB会自动添加到模块列表:
3.重新启动Wireshark后,OID解析即被激活:
根据捕获文件的解密输出,SNMP监控工具定期(10秒间隔)轮询有关FTD上内存池利用率的数据。如TechNote文章ASA SNMP Polling for Memory-Related Statistics中所述,使用SNMP轮询全局共享池(GSP)利用率会导致CPU挂起。在本例中,从捕获中可以清楚地看到,全局共享池利用率是作为SNMP getBulkRequest基元的一部分定期轮询的。
为了将SNMP进程导致的CPU主机数降至最低,建议遵循文章中提到的SNMP的CPU主机数的缓解步骤,并避免轮询与GSP相关的OID。如果没有SNMP轮询OID,则不会观察到SNMP进程导致的CPU挂起,并且溢出率显着降低。