1. Display real time log on FMC or FTD:
pigtail
for example: pigtail | grep 192.168.2.20
pigtail | grep sftunnel
pigtail --help
pigtail deploy
pigtail gui
2. Restart communication channel
manage_procs.pl
run it from the sensor only, run it from FMC will reset all sensors' channel.
This scripts are nice to be used when the FMC and FTD have communication problems like heartbeats are not received, policy deployment is failing or events are not received
> expert
**************************************************************
NOTICE - Shell access will be deprecated in future releases
and will be replaced with a separate expert mode CLI.
**************************************************************
admin@FTD:~$ sudo su
Password:
root@FTD:/home/admin# manage_procs.pl
**************** Configuration Utility **************
1 Reconfigure Correlator
2 Reconfigure and flush Correlator
3 Restart Comm. channel
4 Update routes
5 Reset all routes
6 Validate Network
0 Exit
**************************************************************
Enter choice:
3. Check communication channel status
sftunnel_status.pl
SFTUNNEL Start Time: Fri Aug 9 17:54:50 2024
Both IPv4 and IPv6 connectivity is supported
Broadcast count = 32
Reserved SSL connections: 0
Management Interfaces: 2
eth0 (control events) 192.168.5.5,
tap_nlp (control events) 169.254.1.2,fd00:0:0:1::2
***********************
**RUN STATUS****manager-1722814317.06331*************
Key File = /var/sf/peers/498692d8-51e6-11ef-808a-719980436d87/sftunnel-key.pem
Cert File = /var/sf/peers/498692d8-51e6-11ef-808a-719980436d87/sftunnel-cert.pem
CA Cert = /var/sf/peers/498692d8-51e6-11ef-808a-719980436d87/cacert.pem
Cipher used = TLS_AES_256_GCM_SHA384 (strength:256 bits)
ChannelA Connected: Yes, Interface tap_nlp
Cipher used = TLS_AES_256_GCM_SHA384 (strength:256 bits)
ChannelB Connected: Yes, Interface tap_nlp
Registration: Completed.
IPv4 Connection to peer 'manager-1722814317.06331' Start Time: Fri Aug 9 18:04:03 2024 UTC
PEER INFO:
sw_version 7.4.1
sw_build 172
Using light registration
Management Interfaces: 1
eth0 (control events) 192.168.1.50,
Peer channel Channel-A is valid type (CONTROL), using 'tap_nlp', connected to '198.51.100.2' via '169.254.1.2'
Peer channel Channel-B is valid type (EVENT), using 'tap_nlp', connected to '198.51.100.2' via '169.254.1.2'
Clish command:
PEER:198.18.133.120
Peer channel Channel-A is valid type (CONTROL), using 'br1', connected to '198.18.133.120' via '198.18.133.42'
Peer channel Channel-B is valid type (EVENT), using 'br1', connected to '198.18.133.120' via '198.18.133.42'
Registration: Completed.
IPv4 Connection to peer '198.18.133.120' Start Time: Wed Sep 18 13:45:39 2024 UTC
Heartbeat Send Time: Wed Sep 18 14:21:32 2024 UTC
Heartbeat Received Time: Wed Sep 18 14:22:43 2024 UTC
Last disconnect time : Wed Nov 15 16:01:27 2023 UTC
Last disconnect reason : Peer was removed
>
4 Verify communication channel session, each FTD has two tunnels: Control and Event.
expert mode:
netstat | grep 8305
5. check flow offload to hardware
show flow-offload flow
6. Packet capture and packet-tracer with trace detail
Gives info for both Lina and Snort engine inspection
7. show data-path inspection
FTD# show service-policy flow tcp host 172.16.1.10 host 8.8.8.8 eq 21
Global policy:
Service-policy: global_policy
Class-map: inspection_default
Match: default-inspection-traffic
Action:
Input flow: inspect ftp
Class-map: class-default
Match: any
Action:
Output flow: Input flow: set connection advanced-options UM_STATIC_TCP_MAP
FTD#
8. Process Management tool:
root@FTD:/home/admin#
pmtool status | grep "-" | head
pmtool disablebyid sftunnel
pmtool enablebyid sftunnel
9. Capture on Snort engine
> capture CP [trace] interface inside match ip any host 203.0.113.1
> show capture CP
> show capture packet-number 4 trace
or
> capture-traffic -s 0 -w capture.pcap icmp and host 172.16.1.10
-s 0 means means no limit on packet size, in post cases, use -s 1500
filename.pcap locates at /ngfw/var/commom/ folder
file secure-copy <ip> <username><location> capture.pcap
===========
FTD deployment troubleshooting.
https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw-virtual/215258-troubleshooting-firepower-threat-defense.html
Configure, Verify and Troubleshoot Firepower Device Registration
https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/215540-configure-verify-and-troubleshoot-firep.html#anc28
=============
Error:
active peer already exists
Reason:
A device can be un-cleanly de-registered and still exists in the database
Fix:
/usr/local/sf/bin/remove_peer.pl "IP or NAME or UUID" FORCE
Comments
Post a Comment