Konfiguration, Überprüfung und Fehlerbehebung bei der Registrierung von FirePOWER-Geräten

Download-Optionen

  • PDF     (1.6 MB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
  • ePub     (1.5 MB)
    In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
  • Mobi (Kindle)     (1.1 MB)
    Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen
Aktualisiert:14. August 2023
Dokument-ID:215540

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

    Einleitung

    In diesem Dokument werden die Verfahren zur Fehlerbehebung bei der Verbindung zwischen Firepower Threat Defense (FTD) und Firepower Management Center (FMC) beschrieben.

    Voraussetzungen

    Anforderungen

    Es gibt keine spezifischen Anforderungen für dieses Dokument.

    Verwendete Komponenten

    Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

    • FTD-Software 6.6.x und 6.5.x
    • FMC-Software 6.6.x

    Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.



    Hintergrundinformationen

    In diesem Dokument werden der Betrieb, die Verifizierung und die Fehlerbehebung für die Verbindung (Sftunnel) zwischen einem verwalteten FTD und dem verwalteten FMC beschrieben.

    Die Informationen und Beispiele basieren auf FTD, die meisten Konzepte sind jedoch auch vollständig auf NGIPS (Appliances der Serien 7000/8000) oder ein FirePOWER-Modul auf ASA55xx anwendbar.

    Ein FTD unterstützt zwei Hauptverwaltungsmodi:

    • Offbox über FMC - auch bekannt als Remote-Management
    • On-Box über FirePOWER Device Manager (FDM) und/oder Cisco Defense Orchestrator (CDO) - auch bekannt als lokales Management

    Im Fall der Remote-Verwaltung muss sich die FTD zunächst beim FMC registrieren, das einen Prozess verwendet, der als Geräteregistrierung bezeichnet wird.

    Nach Abschluss der Registrierung stellen die FTD und das FMC einen sicheren Tunnel mit der Bezeichnung sftunnel her (der Name leitet sich vom Sourcefire-Tunnel ab).



    Designoptionen

    Aus Designsicht kann sich das FTD-FMC im gleichen L3-Subnetz befinden:

    Abbildung 1

    oder durch verschiedene Netzwerke getrennt werden:

    Abbildung 2


    192.0.2.0

    Hinweis: Der Sftunnel kann auch die FTD selbst durchlaufen. Dieses Design wird nicht empfohlen. Der Grund dafür ist, dass ein FTD-Datenebenenproblem die Kommunikation zwischen FTD und FMC stören kann.

    Abbildung 3



    Welche Informationen werden über den sftunnel ausgetauscht?

    Diese Liste enthält die meisten Informationen, die über den sftunnel übertragen werden:

    • Appliance-Heartbeat (Keepalive)
    • Zeitsynchronisierung (NTP)
    • Ereignisse (Verbindung, Intrusion/IPS, Datei, SSL usw.)
    • Malware-Suchen
    • Ereignisse/Warnmeldungen
    • Benutzer- und Gruppeninformationen (für Identitätsrichtlinien)
    • FTD HA-Statusinformationen
    • FTD-Cluster-Statusinformationen
    • Security Intelligent (SI)-Informationen/-Ereignisse
    • Threat Intelligence Director (TID) - Informationen/Ereignisse
    • Erfasste Dateien
    • Netzwerkerkennungsereignisse
    • Richtlinienpaket (Richtlinienbereitstellung)
    • Software-Upgrade-Pakete
    • Software-Patchpakete
    • VDBs
    • SRUs



    Welches Protokoll/welchen Port verwendet der Sftunnel?

    Der Sftunnel verwendet den TCP-Port 8305. Im Backend ist es ein TLS-Tunnel:

    Abbildung 3b

    Wie ändere ich den Sftunnel TCP Port auf FTD?

    > configure network management-port 8306
Management port changed to 8306.

    Hinweis: In diesem Fall müssen Sie auch den Port des FMC ändern (Konfiguration > Verwaltungsschnittstellen > Gemeinsam genutzte Einstellungen). Dies betrifft alle anderen Geräte, die bereits beim selben FMC registriert sind. Cisco empfiehlt nachdrücklich, die Standardeinstellungen für den Remote-Management-Port beizubehalten. Wenn der Management-Port jedoch mit anderen Kommunikationsverbindungen in Ihrem Netzwerk in Konflikt gerät, können Sie einen anderen Port auswählen. Wenn Sie den Management-Port ändern, müssen Sie ihn für alle Geräte in Ihrer Bereitstellung ändern, die miteinander kommunizieren müssen.



    Wie viele Verbindungen werden durch den Sftunnel hergestellt?

    Der Sftunnel stellt 2 Verbindungen (Kanäle) her:

    • Steuerkanal
    • Ereigniskanal

    Abbildung 3c


    Welches Gerät initiiert die einzelnen Kanäle?

    Das hängt vom Szenario ab. Überprüfen Sie die Szenarien, die im Rest des Dokuments beschrieben werden.

    Konfigurieren

    Grundlagen der Registrierung

    FTD-CLI

    Auf FTD lautet die grundlegende Syntax für die Geräteregistrierung:

    > configure manager add <FMC Host> <Registrierungsschlüssel> <NAT-ID>

    Wert

    Beschreibung
    FMC-Host

    Dies kann entweder:

    • Hostname
    • IPv4-Adresse
    • IPv6-Adresse
    • DONTRESOLVE
    Registrierungsschlüssel

    Hierbei handelt es sich um eine alphanumerische Zeichenfolge mit gemeinsamem geheimen Schlüssel (zwischen 2 und 36 Zeichen), die für die Geräteregistrierung verwendet wird. Nur alphanumerische Zeichen, Bindestrich (-), Unterstrich (_) und Punkt (.) sind zulässig.
    NAT-ID Eine alphanumerische Zeichenfolge, die bei der Registrierung zwischen dem FMC und dem Gerät verwendet wird, wenn auf einer Seite keine IP-Adresse angegeben ist. Geben Sie dieselbe NAT-ID auf dem FMC an.

    Weitere Informationen finden Sie in der Cisco Firepower Threat Defense Command Reference.



    FMC-Benutzeroberfläche

    Navigieren Sie auf FMC zu Devices (Geräte) > Device Management (Geräteverwaltung). Wählen Sie Hinzufügen > Gerät aus

    Abbildung 4

    Abbildung 5

    • Geben Sie auf dem Host die FTD-IP-Adresse an.
    • Geben Sie im Feld Anzeigename den gewünschten Namen an.
    • Der Registrierungsschlüssel muss mit dem in der FTD-CLI angegebenen Schlüssel übereinstimmen.
    • Wenn Sie mehrere Domänen verwenden, geben Sie die Domäne an, unter der Sie das FTD hinzufügen möchten.
    • Geben Sie in Group (Gruppe) die Gerätegruppe an, der Sie den FTD hinzufügen möchten.
    • Geben Sie in der Zugriffskontrollrichtlinie die Sicherheitsrichtlinie an, die Sie auf FTD bereitstellen möchten.
    • Smart Licensing: Geben Sie die erforderlichen Lizenzen für die konfigurierten Funktionen an.
    • NAT-ID: Wird in den weiter unten in diesem Dokument beschriebenen Szenarien benötigt.

    Weitere Informationen finden Sie im Firepower Management Center Configuration Guide, Add Devices to the Firepower Management Center.




    Szenario 1. Statische FMC- und FTD-IP-Adresse

    Abbildung 7

    FTD-CLI

    > configure manager add <FMC Static IP> <Registrierungsschlüssel>

    Beispiele:

    > configure manager add 10.62.148.75 Cisco-123
Manager successfully configured.
Please make note of reg_key as this will be required while adding Device in FMC.

    Hintergrundinformationen


    Sobald Sie den FTD-Befehl eingeben, versucht die FTD, alle 20 Sekunden eine Verbindung zum FMC herzustellen. Da das FMC jedoch noch nicht konfiguriert ist, antwortet es mit TCP RST:

    > capture-traffic

Please choose domain to capture traffic from:
  0 - eth0
  1 - Global

Selection? 0

Please specify tcpdump options desired.
(or enter '?' for a list of supported options)
Options: -n host 10.62.148.75
HS_PACKET_BUFFER_SIZE is set to 4.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:53:33.365513 IP 10.62.148.42.46946 > 10.62.148.75.8305: Flags [S], seq 2274592861, win 29200, options [mss 1460,sackOK,TS val 55808298 ecr 0,nop,wscale 7], length 0
18:53:33.365698 IP 10.62.148.75.8305 > 10.62.148.42.46946: Flags [R.], seq 0, ack 2274592862, win 0, length 0
18:53:53.365973 IP 10.62.148.42.57607 > 10.62.148.75.8305: Flags [S], seq 1267517632, win 29200, options [mss 1460,sackOK,TS val 55810298 ecr 0,nop,wscale 7], length 0
18:53:53.366193 IP 10.62.148.75.8305 > 10.62.148.42.57607: Flags [R.], seq 0, ack 1267517633, win 0, length 0
18:54:13.366383 IP 10.62.148.42.55484 > 10.62.148.75.8305: Flags [S], seq 4285875151, win 29200, options [mss 1460,sackOK,TS val 55812298 ecr 0,nop,wscale 7], length 0
18:54:13.368805 IP 10.62.148.75.8305 > 10.62.148.42.55484: Flags [R.], seq 0, ack 4285875152, win 0, length 0

    Der Registrierungsstatus des Geräts:

    > show managers
Host                      : 10.62.148.75
Registration Key          : ****
Registration              : pending
RPC Status                :
Type                      : Manager
Host                      : 10.62.148.75
Registration              : Pending



    Der FTD hört den Port TCP 8305 ab:

    admin@vFTD66:~$ netstat -na | grep 8305
tcp        0      0 10.62.148.42:8305       0.0.0.0:*               LISTEN



    FMC-Benutzeroberfläche

    Geben Sie in diesem Fall Folgendes an:

    • Host (IP-Adresse des FTD)
    • Anzeigename
    • Registrierungsschlüssel (dieser muss mit dem auf FTD konfigurierten Schlüssel übereinstimmen)
    • Zugriffskontrollrichtlinie
    • Domäne
    • Smart Licensing-Informationen

    Abbildung 8

    Registrieren auswählen

    Der Registrierungsvorgang wird gestartet:

    Abbildung 9


    Das FMC beginnt, den Port TCP 8305 abzuhören:

    admin@FMC2000-2:~$ netstat -na | grep 8305
tcp        0      0 10.62.148.75:8305       0.0.0.0:*               LISTEN

    Im Hintergrund initiiert das FMC eine TCP-Verbindung:

    20:15:55.437434 IP 10.62.148.42.49396 > 10.62.148.75.8305: Flags [S], seq 655146775, win 29200, options [mss 1460,sackOK,TS val 56302505 ecr 0,nop,wscale 7], length 0
20:15:55.437685 IP 10.62.148.75.8305 > 10.62.148.42.49396: Flags [R.], seq 0, ack 655146776, win 0, length 0
20:16:00.463637 ARP, Request who-has 10.62.148.42 tell 10.62.148.75, length 46
20:16:00.463655 ARP, Reply 10.62.148.42 is-at 00:50:56:85:7b:1f, length 28
20:16:08.342057 IP 10.62.148.75.50693 > 10.62.148.42.8305: Flags [S], seq 2704366385, win 29200, options [mss 1460,sackOK,TS val 1181294721 ecr 0,nop,wscale 7], length 0
20:16:08.342144 IP 10.62.148.42.8305 > 10.62.148.75.50693: Flags [S.], seq 1829769842, ack 2704366386, win 28960, options [mss 1460,sackOK,TS val 56303795 ecr 1181294721,nop,wscale 7], length 0
20:16:08.342322 IP 10.62.148.75.50693 > 10.62.148.42.8305: Flags [.], ack 1, win 229, options [nop,nop,TS val 1181294722 ecr 56303795], length 0
20:16:08.342919 IP 10.62.148.75.50693 > 10.62.148.42.8305: Flags [P.], seq 1:164, ack 1, win 229, options [nop,nop,TS val 1181294722 ecr 56303795], length 163
20:16:08.342953 IP 10.62.148.42.8305 > 10.62.148.75.50693: Flags [.], ack 164, win 235, options [nop,nop,TS val 56303795 ecr 1181294722], length 0

    Der sftunnel-Steuerungskanal wird eingerichtet:

    admin@FMC2000-2:~$ netstat -na | grep 8305
tcp        0      0 10.62.148.75:8305       0.0.0.0:*               LISTEN
tcp        0      0 10.62.148.75:50693      10.62.148.42:8305       ESTABLISHED

    > sftunnel-status

SFTUNNEL Start Time: Sat Apr 18 20:14:20 2020

        Both IPv4 and IPv6 connectivity is supported
        Broadcast count = 4
        Reserved SSL connections: 0
        Management Interfaces: 1
        eth0 (control events) 10.62.148.42,

***********************

**RUN STATUS****ksec-fs2k-2-mgmt.cisco.com*************
        Cipher used = AES256-GCM-SHA384 (strength:256 bits)
        ChannelA Connected: Yes, Interface eth0
        ChannelB Connected: No
        Registration: Completed.
        IPv4 Connection to peer '10.62.148.75' Start Time: Sat Apr 18 20:16:08 2020


PEER INFO:
        sw_version 6.6.0
        sw_build 90
        Management Interfaces: 1
        eth0 (control events) 10.62.148.75,
        Peer channel Channel-A is valid  type (CONTROL), using 'eth0', connected to '10.62.148.75' via '10.62.148.42'
        Peer channel Channel-B is not valid

    Nach wenigen Minuten ist der Event-Kanal eingerichtet. Der Initiator des Event-Kanals kann auf beiden Seiten vorhanden sein. In diesem Beispiel war es das FMC:

    20:21:15.347587 IP 10.62.148.75.43957 > 10.62.148.42.8305: Flags [S], seq 3414498581, win 29200, options [mss 1460,sackOK,TS val 1181601702 ecr 0,nop,wscale 7], length 0
20:21:15.347660 IP 10.62.148.42.8305 > 10.62.148.75.43957: Flags [S.], seq 2735864611, ack 3414498582, win 28960, options [mss 1460,sackOK,TS val 56334496 ecr 1181601702,nop,wscale 7], length 0
20:21:15.347825 IP 10.62.148.75.43957 > 10.62.148.42.8305: Flags [.], ack 1, win 229, options [nop,nop,TS val 1181601703 ecr 56334496], length 0
20:21:15.348415 IP 10.62.148.75.43957 > 10.62.148.42.8305: Flags [P.], seq 1:164, ack 1, win 229, options [nop,nop,TS val 1181601703 ecr 56334496], length 163

    Der Port der zufälligen Quelle gibt den Verbindungsinitiator an:

    admin@FMC2000-2:~$ netstat -na | grep 10.62.148.42
tcp        0      0 10.62.148.75:50693      10.62.148.42:8305       ESTABLISHED
tcp        0      0 10.62.148.75:43957      10.62.148.42:8305       ESTABLISHED

    Falls der Ereigniskanal von der FTD initiiert wurde, lautet die Ausgabe wie folgt:

    admin@FMC2000-2:~$ netstat -na | grep 10.62.148.42
tcp        0      0 10.62.148.75:58409      10.62.148.42:8305       ESTABLISHED
tcp        0      0 10.62.148.75:8305       10.62.148.42:46167      ESTABLISHED

    FTD-Seite:

    > sftunnel-status

SFTUNNEL Start Time: Sat Apr 18 20:14:20 2020

        Both IPv4 and IPv6 connectivity is supported
        Broadcast count = 6
        Reserved SSL connections: 0
        Management Interfaces: 1
        eth0 (control events) 10.62.148.42,

***********************

**RUN STATUS****ksec-fs2k-2-mgmt.cisco.com*************
        Cipher used = AES256-GCM-SHA384 (strength:256 bits)
        ChannelA Connected: Yes, Interface eth0
        Cipher used = AES256-GCM-SHA384 (strength:256 bits)
        ChannelB Connected: Yes, Interface eth0
        Registration: Completed.
        IPv4 Connection to peer '10.62.148.75' Start Time: Sat Apr 18 20:16:08 2020


PEER INFO:
        sw_version 6.6.0
        sw_build 90
        Management Interfaces: 1
        eth0 (control events) 10.62.148.75,
        Peer channel Channel-A is valid  type (CONTROL), using 'eth0', connected to '10.62.148.75' via '10.62.148.42'
        Peer channel Channel-B is valid  type (EVENT), using 'eth0', connected to '10.62.148.75' via '10.62.148.42'

    > show managers
Type                      : Manager
Host                      : 10.62.148.75
Registration              : Completed

>




    Szenario 2. FTD DHCP-IP-Adresse - Statische FMC-IP-Adresse

    In diesem Szenario hat die FTD-Verwaltungsschnittstelle seine IP-Adresse von einem DHCP-Server erhalten:

    Abbildung 10

    FTD-CLI

    Sie müssen die NAT-ID angeben:

    > configure manager add <FMC Static IP> <Registrierungsschlüssel> <NAT-ID>

    Beispiele:

    > configure manager add 10.62.148.75 Cisco-123 nat123
Manager successfully configured.
Please make note of reg_key as this will be required while adding Device in FMC.

>

    FTD-Registrierungsstatus:

    > show managers
Host                      : 10.62.148.75
Registration Key          : ****
Registration              : pending
RPC Status                :
Type                      : Manager
Host                      : 10.62.148.75
Registration              : Pending

    FMC-Benutzeroberfläche

    Geben Sie in diesem Fall Folgendes an:

    • Anzeigename
    • Registrierungsschlüssel (dieser muss mit dem auf FTD konfigurierten Schlüssel übereinstimmen)
    • Zugriffskontrollrichtlinie
    • Domäne
    • Smart Licensing-Informationen
    • NAT-ID (dies ist erforderlich, wenn Host nicht angegeben ist. Es muss mit dem auf FTD konfigurierten übereinstimmen.)

    Abbildung 11


    Wer initiiert in diesem Fall den sftunnel?

    Die FTD initiiert beide Kanalverbindungen:

    ftd1:/home/admin# netstat -an | grep 148.75
tcp        0      0 10.62.148.45:40273      10.62.148.75:8305       ESTABLISHED
tcp        0      0 10.62.148.45:39673      10.62.148.75:8305       ESTABLISHED



    Szenario 3. Statische FTD-IP-Adresse - FMC DHCP-IP-Adresse


    Abbildung 12

    > configure manager add DONTRESOLVE Cisco-123 nat123
Manager successfully configured.
Please make note of reg_key as this will be required while adding Device in FMC.

>



    Hinweis: Bei DONTRESOLVE ist die NAT-ID erforderlich.

    FMC-Benutzeroberfläche

    Geben Sie in diesem Fall Folgendes an:

    • FTD-IP-Adresse
    • Anzeigename
    • Registrierungsschlüssel (dieser muss mit dem auf FTD konfigurierten Schlüssel übereinstimmen)
    • Zugriffskontrollrichtlinie
    • Domäne
    • Smart Licensing-Informationen
    • NAT-ID (muss mit der auf FTD konfigurierten ID übereinstimmen)

    Abbildung 13

    Die FTD nach Abschluss der Registrierung ist:

    > show managers
Type                      : Manager
Host                      : 5a8454ea-8273-11ea-a7d3-d07d71db8f19DONTRESOLVE
Registration              : Completed

    Wer initiiert in diesem Fall den sftunnel?

    • Das FMC initiiert den Steuerungskanal.
    • Der Event-Kanal kann von beiden Seiten initiiert werden.
    root@FMC2000-2:/Volume/home/admin# netstat -an | grep 148.42
tcp        0      0 10.62.148.75:50465      10.62.148.42:8305       ESTABLISHED
tcp        0      0 10.62.148.75:48445      10.62.148.42:8305       ESTABLISHED




    Szenario 4. FTD-Registrierung bei FMC HA

    Konfigurieren Sie auf FTD nur das aktive FMC:

    > configure manager add 10.62.184.22 cisco123
Manager successfully configured.
Please make note of reg_key as this will be required while adding Device in FMC.


    Abbildung 15

    Hinweis: Stellen Sie sicher, dass der Datenverkehr vom TCP-Port 8305 vom FTD zu beiden FMCs zugelassen wird.

    Zunächst wird der Sftunnel zum aktiven FMC eingerichtet:

    > show managers
Type                      : Manager
Host                      : 10.62.184.22
Registration              : Completed

    Nach wenigen Minuten beginnt die FTD-Registrierung beim Standby-FMC:

    Abbildung16

    > show managers
Type                      : Manager
Host                      : 10.62.184.22
Registration              : Completed

Type                      : Manager
Host                      : 10.62.148.249
Registration              : Completed

    Im FTD-Backend werden 2 Steuerungskanäle (einer zu jedem FMC) und 2 Ereigniskanäle (einer zu jedem FMC) eingerichtet:

    ftd1:/home/admin# netstat -an | grep 8305
tcp        0      0 10.62.148.42:8305       10.62.184.22:36975      ESTABLISHED
tcp        0      0 10.62.148.42:42197      10.62.184.22:8305       ESTABLISHED
tcp        0      0 10.62.148.42:8305       10.62.148.249:45373     ESTABLISHED
tcp        0      0 10.62.148.42:8305       10.62.148.249:51893     ESTABLISHED



    Szenario 5. FTD HA

    Bei FTD HA verfügt jede Einheit über einen separaten Tunnel zum FMC:

    Abbildung 17

    Sie registrieren beide FTDs unabhängig voneinander und bilden dann von FMC aus das FTD HA. Weitere Informationen finden Sie unter:



    Szenario 6. FTD-Cluster

    Bei einem FTD-Cluster verfügt jede Einheit über einen separaten Tunnel zum FMC. Ab 6.3 FMC Release müssen Sie nur noch die FTD Control Unit bei FMC registrieren. Dann kümmert sich das FMC um die restlichen Einheiten und erfasst sie automatisch.

    Abbildung 18

    Hinweis: Es wird empfohlen, die Steuereinheit für die beste Leistung hinzuzufügen. Sie können jedoch jede Einheit des Clusters hinzufügen. Weitere Informationen finden Sie unter Erstellen eines Firepower Threat Defense-Clusters




    Fehlerbehebung bei gängigen Problemen

    1. Ungültige Syntax in FTD CLI

    Bei einer ungültigen Syntax auf FTD und einem fehlgeschlagenen Registrierungsversuch zeigt die FMC-Benutzeroberfläche eine ziemlich allgemeine Fehlermeldung an:

    Abbildung 14

    In diesem Befehl ist das Schlüsselwort key der Registrierungsschlüssel, während cisco123 die NAT-ID ist. Es ist durchaus üblich, das Schlüsselwort hinzuzufügen, obwohl es technisch gesehen kein solches Schlüsselwort gibt:

    > configure manager add 10.62.148.75 key cisco123
Manager successfully configured.
Please make note of reg_key as this will be required while adding Device in FMC.

    Empfohlene Aktion

    Verwenden Sie die richtige Syntax und keine nicht vorhandenen Schlüsselwörter.

    > configure manager add 10.62.148.75 cisco123
Manager successfully configured.
Please make note of reg_key as this will be required while adding Device in FMC.



    2. Nichtübereinstimmung des Registrierungsschlüssels zwischen FTD und FMC

    Die Benutzeroberfläche des FMC zeigt Folgendes an:

    Abbildung 14



    Empfohlene Aktion

    Überprüfen Sie auf FTD die Datei /ngfw/var/log/messages auf Authentifizierungsprobleme.

    Weg 1 - Überprüfen der vergangenen Protokolle

    > system support view-files
Type a sub-dir name to list its contents: s

Type the name of the file to view ([b] to go back, [Ctrl+C] to exit)
> messages
Apr 19 04:02:05 vFTD66 syslog-ng[1440]: Configuration reload request received, reloading configuration;
Apr 19 04:02:07 vFTD66 SF-IMS[3116]: [3116] pm:control [INFO] ControlHandler auditing message->type 0x9017, from '', cmd '/ngf
w/usr/bin/perl /ngfw/usr/local/sf/bin/run_hm.pl --persistent', pid 19455 (uid 0, gid 0)
/authenticate

Apr 19 20:17:14 vFTD66 SF-IMS[18974]: [19131] sftunneld:sf_ssl [WARN] Accept: Failed to authenticate peer '10.62.148.75' <- The problem

    Weg 2 - Überprüfung der Live-Protokolle

    > expert
ftd1:~$ sudo su
Password:
ftd1::/home/admin# tail -f /ngfw/var/log/messages

    Überprüfen Sie auf FTD den Inhalt der Datei /etc/sf/sftunnel.conf, um sicherzustellen, dass der Registrierungsschlüssel korrekt ist:

    ftd1:~$ cat /etc/sf/sftunnel.conf | grep reg_key
        reg_key cisco-123;



    3. Verbindungsprobleme zwischen FTD - FMC

    Die Benutzeroberfläche des FMC zeigt Folgendes an:

    Abbildung 14

    Empfohlene Maßnahmen

    • Stellen Sie sicher, dass sich kein Gerät im Pfad (z. B. eine Firewall) befindet, das den Datenverkehr blockiert (TCP 8305). Bei FMC HA stellen Sie sicher, dass der Datenverkehr zu TCP-Port 8305 zu beiden FMCs zugelassen wird.
    • Aufnahmen zur Verifizierung der bidirektionalen Kommunikation Verwenden Sie auf FTD den Befehl capture-traffic. Stellen Sie sicher, dass ein TCP 3-Wege-Handshake stattfindet und keine TCP FIN- oder RST-Pakete.
    > capture-traffic

Please choose domain to capture traffic from:
  0 - eth0
  1 - Global

Selection? 0

Please specify tcpdump options desired.
(or enter '?' for a list of supported options)
Options: -n host 10.62.148.75
HS_PACKET_BUFFER_SIZE is set to 4.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:56:09.393655 IP 10.62.148.42.53198 > 10.62.148.75.8305: Flags [S], seq 3349394953, win 29200, options [mss 1460,sackOK,TS val 1033596 ecr 0,nop,wscale 7], length 0
20:56:09.393877 IP 10.62.148.75.8305 > 10.62.148.42.53198: Flags [R.], seq 0, ack 3349394954, win 0, length 0
20:56:14.397412 ARP, Request who-has 10.62.148.75 tell 10.62.148.42, length 28
20:56:14.397602 ARP, Reply 10.62.148.75 is-at a4:6c:2a:9e:ea:10, length 46

    Auf ähnliche Weise sollten Sie eine Erfassung auf dem FMC durchführen, um eine bidirektionale Kommunikation sicherzustellen:

    root@FMC2000-2:/var/common# tcpdump -i eth0 host 10.62.148.42 -n -w sftunnel.pcap

    Es wird außerdem empfohlen, die Erfassung im pcap-Format zu exportieren und den Paketinhalt zu überprüfen:

    ftd1:/home/admin# tcpdump -i eth0 host 10.62.148.75 -n -w tunnel.pcap
HS_PACKET_BUFFER_SIZE is set to 4.
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

    Mögliche Ursachen:

    • Dem FMC wurde das FTD-Gerät nicht hinzugefügt.
    • Ein Gerät im Pfad (z. B. die Firewall) blockiert oder ändert den Datenverkehr.
    • Die Pakete werden im Pfad nicht richtig geroutet.
    • Der Sftunnel-Prozess auf FTD oder FMC ist ausgefallen (Szenario 6 prüfen)
    • Es liegt ein MTU-Problem im Pfad vor (Überprüfungsszenario).

    Für die Erfassungsanalyse lesen Sie dieses Dokument:

    Analysieren von Firepower-Firewall-Erfassungen zur effektiven Behebung von Netzwerkproblemen



    4. Inkompatible SW zwischen FTD - FMC

    Die Benutzeroberfläche des FMC zeigt Folgendes an:

    Abbildung 14

    Empfohlene Aktion

    Überprüfen Sie die Datei FTD /ngfw/var/log/messages:

    Apr 19 22:08:09 mzafeiro_vFTD66 SF-IMS[12730]: [12830] sftunneld:sf_connections [INFO] Need to send SW version and Published Services to 10.62.148.247
Apr 19 22:08:09 mzafeiro_vFTD66 SF-IMS[12730]: [12830] sftunneld:sf_channel [INFO] >> ChannelState do_dataio_for_heartbeat peer 10.62.148.247 / channelA / CONTROL [ msgSock & ssl_context ] <<
Apr 19 22:08:09 mzafeiro_vFTD66 SF-IMS[12730]: [12830] sftunneld:sf_heartbeat [INFO] Saved SW VERSION from peer 10.62.148.247 (10.10.0.4)
Apr 19 22:08:09 mzafeiro_vFTD66 SF-IMS[12730]: [12830] sftunneld:ssl_mac [WARN] FMC(manager) 10.62.148.247 send unsupported version 10.10.0.4
Apr 19 22:08:09 mzafeiro_vFTD66 SF-IMS[12730]: [12830] sftunneld:sf_connections [INFO] <<<<<<<<<<<<<<<<<<<<<< ShutDownPeer 10.62.148.247 >>>>>>>>>>>>>>>>>>>>>>>>
Apr 19 22:08:09 mzafeiro_vFTD66 SF-IMS[12730]: [12830] sftunneld:stream_file [INFO] Stream CTX destroyed for 10.62.148.247
Apr 19 22:08:09 mzafeiro_vFTD66 SF-IMS[12730]: [12830] sftunneld:sf_channel [INFO] >> ChannelState ShutDownPeer peer 10.62.148.247 / channelA / CONTROL [ msgSock & ssl_context ] <<

    Überprüfen Sie die Firepower-Kompatibilitätsmatrix:

    Cisco FirePOWER-Kompatibilitätsleitfaden



    5. Zeitdifferenz zwischen FTD und FMC

    Bei der FTD-FMC-Kommunikation werden Zeitunterschiede zwischen den beiden Geräten berücksichtigt. Es ist eine Designanforderung, dass FTD und FMC vom gleichen NTP-Server synchronisiert werden.

    Wenn der FTD auf einer Plattform wie 41xx oder 93xx installiert wird, werden die Zeiteinstellungen vom übergeordneten Chassis (FXOS) übernommen.



    Empfohlene Aktion

    Stellen Sie sicher, dass der Gehäusemanager (FCM) und das FMC dieselbe Zeitquelle (NTP-Server) verwenden.



    6. sftunnel-Prozess heruntergefahren oder deaktiviert

    Auf FTD übernimmt der sftunnel-Prozess den Registrierungsprozess. Dies ist der Status des Prozesses vor der Manager-Konfiguration:

    > pmtool status
…
sftunnel (system) - Waiting
Command: /ngfw/usr/local/sf/bin/sftunnel -d -f /etc/sf/sftunnel.conf
PID File: /ngfw/var/sf/run/sftunnel.pid
Enable File: /ngfw/etc/sf/sftunnel.conf
CPU Affinity:
Priority: 0
Next start: Mon Apr 20 06:12:06 2020
Required by: sfmgr,sfmbservice,sfipproxy
CGroups: memory=System/ProcessHigh


    Registrierungsstatus:

    > show managers
No managers configured.



    Konfigurieren Sie den Manager:

    > configure manager add 10.62.148.75 cisco123
Manager successfully configured.
Please make note of reg_key as this will be required while adding Device in FMC.

    Der Prozess ist jetzt aktiv:

    > pmtool status
…
sftunnel (system) - Running 24386
Command: /ngfw/usr/local/sf/bin/sftunnel -d -f /etc/sf/sftunnel.conf
PID File: /ngfw/var/sf/run/sftunnel.pid
Enable File: /ngfw/etc/sf/sftunnel.conf
CPU Affinity:
Priority: 0
Next start: Mon Apr 20 07:12:35 2020
Required by: sfmgr,sfmbservice,sfipproxy
CGroups: memory=System/ProcessHigh(enrolled)

    In einigen seltenen Fällen kann der Prozess heruntergefahren oder deaktiviert werden:

    > pmtool status
…
sftunnel (system) - User Disabled
Command: /ngfw/usr/local/sf/bin/sftunnel -d -f /etc/sf/sftunnel.conf
PID File: /ngfw/var/sf/run/sftunnel.pid
Enable File: /ngfw/etc/sf/sftunnel.conf
CPU Affinity:
Priority: 0
Next start: Mon Apr 20 07:09:46 2020
Required by: sfmgr,sfmbservice,sfipproxy
CGroups: memory=System/ProcessHigh

    Der Manager-Status sieht normal aus:

    > show managers
Host                      : 10.62.148.75
Registration Key          : ****
Registration              : pending
RPC Status                :

    Andererseits schlägt die Geräteregistrierung fehl:

    Abbildung 14

    Auf FTD werden keine verwandten Meldungen in /ngfw/var/log/messages angezeigt.

    Empfohlene Aktion

    Sammeln Sie die FTD-Problembehebungsdatei, und wenden Sie sich an das Cisco TAC.



    7. FTD Ausstehende Registrierung auf sekundärem FMC

    Es gibt Szenarien, in denen das FTD-Gerät nach der erstmaligen FTD-Registrierung beim FMC HA-Setup nicht zum sekundären FMC hinzugefügt wird.

    Empfohlene Aktion

    Gehen Sie wie in diesem Dokument beschrieben vor:

    Auflösen der Geräteregistrierung in FirePOWER Management Center High Availability über CLI

    Warnung: Dieses Verfahren wirkt aufdringlich, da es die Aufhebung der Registrierung eines Geräts beinhaltet. Dies wirkt sich auf die FTD-Gerätekonfiguration aus (sie wird gelöscht). Es wird empfohlen, dieses Verfahren nur bei der FTD-Registrierung und -Einrichtung anzuwenden. Sammeln Sie in anderen Fällen FTD- und FMC-Problembehebungsdateien, und wenden Sie sich an das Cisco TAC.

    8. Registrierung schlägt aufgrund von Pfad-MTU fehl

    Im Cisco TAC gibt es Szenarien, bei denen der Sftunnel-Datenverkehr eine Verbindung mit einer kleinen MTU durchqueren muss. Die Sftunnel-Pakete haben den Don’t fragment bit Set, daher ist eine Fragmentierung nicht zulässig:

    Abbildung19

    Zusätzlich können Sie in den Dateien /ngfw/var/log/messages eine Meldung wie diese sehen:

    MSGS: 10-09 14:41:11 ftd1 SF-IMS[7428]: [6612] sftunneld:sf_ssl [ERROR] Connect:SSL-Handshake fehlgeschlagen



    Empfohlene Aktion

    Um zu überprüfen, ob ein Paketverlust aufgrund einer Fragmentierung vorliegt, führen Sie Erfassungen auf FTD, FMC und idealerweise auf Geräten im Pfad durch. Überprüfen Sie, ob Pakete auf beiden Seiten eintreffen.

    Reduzieren Sie auf FTD die MTU auf der FTD-Management-Schnittstelle. Der Standardwert ist 1500 Byte. MAX ist 1500 für die Management-Schnittstelle und 9000 für die Eventing-Schnittstelle. Der Befehl wurde in FTD 6.6 hinzugefügt.

    Cisco FirePOWER Threat Defense-Befehlsreferenz

    Beispiel

    > configure network mtu 1300
MTU set successfully to 1300 from 1500 for eth0
Refreshing Network Config...
Interface eth0 speed is set to '10000baseT/Full'

    Verifizierung

    > show network
===============[ System Information ]===============
Hostname                  : ksec-sfvm-kali-3.cisco.com
DNS Servers               : 192.168.200.100
Management port           : 8305
IPv4 Default route
  Gateway                 : 10.62.148.1
  Netmask                 : 0.0.0.0


======================[ eth0 ]======================
State                     : Enabled
Link                      : Up
Channels                  : Management & Events
Mode                      : Non-Autonegotiation
MDI/MDIX                  : Auto/MDIX
MTU                       : 1300
MAC Address               : 00:50:56:85:7B:1F
----------------------[ IPv4 ]----------------------
Configuration             : Manual
Address                   : 10.62.148.42
Netmask                   : 255.255.255.128
Gateway                   : 10.62.148.1
----------------------[ IPv6 ]----------------------


    Um die Pfad-MTU vom FTD zu überprüfen, können Sie folgenden Befehl verwenden:

    root@firepower:/home/admin# ping -M do -s 1472 10.62.148.75

    Mit der do-Option wird das Bit nicht fragmentieren in den ICMP-Paketen festgelegt. Wenn Sie 1472 angeben, sendet das Gerät zusätzlich 1500 Byte: (IP-Header = 20 Byte) + (ICMP-Header = 8 Byte) + (1472 Byte ICMP-Daten)

    Verringern Sie bei FMC den MTU-Wert auf der FMC-Management-Schnittstelle, wie in diesem Dokument beschrieben:

    Konfigurieren der Management-Schnittstellen von FirePOWER Management Center



    9. FTD wird nach einem Bootstrap-Wechsel von der Chassis-Manager-Benutzeroberfläche abgemeldet

    Dies gilt für die Plattformen FP41xx und FP93xx und ist in Cisco Bug-ID CSCvn45138 dokumentiert .

    Im Allgemeinen dürfen Sie keine Bootstrap-Änderungen über den Chassis-Manager (FCM) vornehmen, es sei denn, Sie führen eine Notfallwiederherstellung durch.



    Empfohlene Aktion

    Falls Sie einen Bootstrap-Wechsel durchgeführt haben und die Bedingung erfüllt haben (die FTD-FMC-Kommunikation ist unterbrochen, während der FTD nach dem Bootstrap-Wechsel hochgefahren wird), müssen Sie den FTD-FMC löschen und erneut registrieren.




    10. FTD verliert Zugriff auf FMC aufgrund von ICMP-Umleitungsnachrichten

    Dieses Problem kann sich auf den Registrierungsprozess auswirken oder die FTD-FMC-Kommunikation nach der Registrierung unterbrechen.

    Problematisch ist in diesem Fall ein Netzwerkgerät, das ICMP Redirect Meldungen an die FTD-Management-Schnittstelle und Black-Holes FTD-FMC Kommunikation sendet.

    So erkennen Sie dieses Problem

    In diesem Fall ist 10.100.1.1 die IP-Adresse des FMC. Auf FTD gibt es eine zwischengespeicherte Route aufgrund einer ICMP-Umleitungsnachricht, die von der FTD an der Verwaltungsschnittstelle empfangen wurde:

    ftd1:/ngfw/var/common# ip route get 10.100.1.1
10.100.1.1 via 10.10.1.1 dev br1  src 10.10.1.23
    cache <redirected>


    Empfohlene Aktion

    Schritt 1

    Deaktivieren Sie die ICMP-Umleitung auf dem Gerät, das sie sendet (z. B. Upstream-L3-Switch, Router usw.).

    Schritt 2

    Löschen Sie den FTD-Routen-Cache aus der FTD-CLI:

    ftd1:/ngfw/var/common# ip route flush 10.100.1.1

    Wenn er nicht umgeleitet wird, sieht er wie folgt aus:

    ftd1:/ngfw/var/common# ip route get 10.100.1.1
10.100.1.1 via 10.62.148.1 dev eth0  src 10.10.1.23
    cache  mtu 1500 advmss 1460 hoplimit 64


    Referenzen



    Zugehörige Informationen



    Revisionsverlauf

    Überarbeitung Veröffentlichungsdatum Kommentare
    3.0
    14-Aug-2023
    Teilnehmerliste aktualisiert.
    2.0
    19-Jul-2022
    Artikel aktualisiert für Formatierung, maschinelle Übersetzung, Gerunds, SEO, Stilanforderungen usw., um aktuelle Cisco Richtlinien zu erfüllen.
    1.0
    20-May-2020
    Erstveröffentlichung
    TAC Authored

    Beiträge von Cisco Ingenieuren

    • Mikis Zafeiroudis
      Cisco TAC Engineer
    • Ilkin Gasimov
      Cisco TAC Engineer

    War dieses Dokument hilfreich?

    FeedbackFeedback

    Cisco kontaktieren

    Dieses Dokument gilt für folgende Produkte.