Fehlerbehebung bei Traceroute von FTD, die trotz erfolgreichem ICMP-Ping keine Hop-Informationen anzeigt

Aktualisiert:9. April 2026
Dokument-ID:225523

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.

Problem

Alle diese Symptome treten auf:

  • Direkt von Cisco Firewall Threat Defense (FTD)-Geräten initiierte Traceroute-Befehle geben bei externen IP-Adressen durchgängig nur "* *" für alle Hops zurück.

  • ICMP-Ping an dieselben Ziele ist erfolgreich, und ICMP ist in der Zugriffskontrollrichtlinie explizit zulässig. 

Dieses Verhalten verhindert die Transparenz von Pfad-Hops für Datenverkehr, der vom FTD-Gerät ausgeht, und beeinträchtigt die Fehlerbehebung für Netzwerkpfade.

Beispiel

Ping an das Ziel funktioniert:

firepower# ping 192.168.203.89
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.203.89, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms

Aber Traceroute ist nicht:

firepower# traceroute 192.168.203.89
Type escape sequence to abort.
Tracing the route to 192.168.203.89
 1*  *  * 
 2*  *  * 
 3*  *  * 
...
 30*  *  * 
firepower#

Umwelt

  • Cisco Secure Firewall Threat Defense (FTD)
  • Erstmals beobachtet bei: 7.4, 7.4.2.3, 7.6.2. Andere Versionen könnten ebenfalls betroffen sein.
  • Cisco Secure Firewall Management Center (FMC/cdFMC/FDM) für die Verwaltung.
  • Statische NAT-Regeln im Einsatz, einschließlich bidirektionaler Konfigurationen
  • Von FTD CLI (Lina-Modus) ausgeführte Traceroute-Befehle.
  • ICMP in der Zugriffskontrollrichtlinie zugelassen.

Topologie

Auflösung

Die möglichen Lösungen hängen vom Zweck der konfigurierten NAT-Regel ab.

Lösung 1

Wenn das Ziel darin besteht, die interne Server-IP nur für den ausgehenden Zugriff zu übersetzen, können Sie die NAT-Regel als unidirektional konfigurieren.

Auf FMC kann dies über die NAT-Regel "Erweiterte Optionen" erfolgen:

Die bereitgestellte NAT-Konfiguration:

firepower# show run nat
nat (INSIDE,OUTSIDE) source static server_host interface unidirectional
firepower#

Verifizierung

firepower# traceroute 192.168.203.89
Type escape sequence to abort.
Tracing the route to 192.168.203.89
 1  192.168.201.88 2 msec 2 msec 2 msec
 2  192.168.203.89 1 msec *  1 msec

Lösung 2

Wenn der interne Server von außen erreichbar sein soll, können Sie die NAT-Regel genauer definieren, indem Sie die Port-Weiterleitung konfigurieren:

Die bereitgestellte NAT-Konfiguration:

firepower# show run nat
nat (INSIDE,OUTSIDE) source static server_host interface service SVC_25769850586 SVC_25769850587

Verifizierung

firepower# traceroute 192.168.203.89
Type escape sequence to abort.
Tracing the route to 192.168.203.89
 1  192.168.201.88 2 msec 2 msec 2 msec
 2  192.168.203.89 1 msec *  1 msec

So funktioniert es

Ping

  1. Die Firewall sendet eine Echo-Anfrage (ICMP Typ 8 Code 0).
  2. Für ICMP wird eine neue Firewall-Verbindung erstellt.
  3. Die Firewall erhält eine Echo-Antwort (ICMP-Code 0 0).
  4. Die Nachricht entspricht der in Schritt 2 erstellten Verbindung.
  5. Die Echo-Antwort-Nachricht wird von der Firewall verbraucht.

Routenverfolgung

  1. Die Firewall sendet drei UDP-Pakete von den Ports 33434, 33435 und 33436 mit TTL 1 an das Ziel.
  2. Für UDP wird eine neue Firewall-Verbindung erstellt.
  3. Die Firewall empfängt entweder eine übertragene ICMP-TTL (Typ 11 Code 0) oder einen nicht erreichbaren ICMP-Port (Typ 3 Code 3).
  4. Sobald ICMP-Pakete an der Firewall ankommen, werden sie als andere Verbindungen behandelt als die UDP-Pakete aus Schritt 2.

Dies ist in Wireshark zu sehen:

Fehlerbehebung

Schritt 1

Aktivieren Sie die Paketerfassung an der Firewall-Ausgangsschnittstelle mit Trace, um festzustellen, wie die Firewall die eingehenden Pakete verarbeitet:

firepower# capture CAPI trace interface OUTSIDE match ip host 192.168.203.89 host 192.168.201.100

Schritt 2

Test mit Ping: 

firepower# ping 192.168.203.89                                         
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.203.89, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

 Anschließend mit Traceroute testen:

firepower# traceroute 192.168.203.89
Type escape sequence to abort.
Tracing the route to 192.168.203.89
 1*  *  * 
 2*  *  * 
 3*  *  * 
 4*  *  * 
 5*  *  * 
 6*  *  * 
 7*  *  *
…

Schritt 3

Überprüfen Sie den Inhalt der Aufzeichnung:

  • Die Pakete 1-10 beziehen sich auf den ICMP-Ping-Test.
  • Die Pakete 11-16 beziehen sich auf Traceroute. Die Antworten stammen vom ersten Hop.
  • Die Pakete 17-28 beziehen sich ebenfalls auf Traceroute. Die Antworten stammen vom Zielendpunkt.
firepower# show capture CAPI
190 packets captured
1: 13:50:27.345471       802.1Q vlan#201 P0 192.168.201.200 > 192.168.203.89 icmp: echo request 
2: 13:50:27.345975       802.1Q vlan#201 P0 192.168.203.89 > 192.168.201.200 icmp: echo reply 
3: 13:50:27.346219       802.1Q vlan#201 P0 192.168.201.200 > 192.168.203.89 icmp: echo request 
4: 13:50:27.346600       802.1Q vlan#201 P0 192.168.203.89 > 192.168.201.200 icmp: echo reply 
5: 13:50:27.346814       802.1Q vlan#201 P0 192.168.201.200 > 192.168.203.89 icmp: echo request 
6: 13:50:27.347165       802.1Q vlan#201 P0 192.168.203.89 > 192.168.201.200 icmp: echo reply 
7: 13:50:27.347378       802.1Q vlan#201 P0 192.168.201.200 > 192.168.203.89 icmp: echo request 
8: 13:50:27.347714       802.1Q vlan#201 P0 192.168.203.89 > 192.168.201.200 icmp: echo reply 
9: 13:50:27.347928       802.1Q vlan#201 P0 192.168.201.200 > 192.168.203.89 icmp: echo request 
10: 13:50:27.348279       802.1Q vlan#201 P0 192.168.203.89 > 192.168.201.200 icmp: echo reply 
11: 13:50:33.229724       802.1Q vlan#201 P0 192.168.201.200.49168 > 192.168.203.89.33434:  udp 0 
12: 13:50:33.232562       802.1Q vlan#201 P0 192.168.201.88 > 192.168.201.200 icmp: time exceeded in-transit 
13: 13:50:36.220279       802.1Q vlan#201 P0 192.168.201.200.49168 > 192.168.203.89.33435:  udp 0 
14: 13:50:36.222827       802.1Q vlan#201 P0 192.168.201.88 > 192.168.201.200 icmp: time exceeded in-transit 
15: 13:50:39.220172       802.1Q vlan#201 P0 192.168.201.200.49168 > 192.168.203.89.33436:  udp 0 
16: 13:50:39.222675       802.1Q vlan#201 P0 192.168.201.88 > 192.168.201.200 icmp: time exceeded in-transit 
17: 13:50:42.220157       802.1Q vlan#201 P0 192.168.201.200.49168 > 192.168.203.89.33437:  udp 0 
18: 13:50:42.220737       802.1Q vlan#201 P0 192.168.203.89 > 192.168.201.200 icmp: 192.168.203.89 udp port 33437 unreachable 
19: 13:50:45.220264       802.1Q vlan#201 P0 192.168.201.200.49168 > 192.168.203.89.33438:  udp 0 
20: 13:50:45.220752       802.1Q vlan#201 P0 192.168.203.89 > 192.168.201.200 icmp: 192.168.203.89 udp port 33438 unreachable 
21: 13:50:48.220157       802.1Q vlan#201 P0 192.168.201.200.49168 > 192.168.203.89.33439:  udp 0 
22: 13:50:48.220645       802.1Q vlan#201 P0 192.168.203.89 > 192.168.201.200 icmp: 192.168.203.89 udp port 33439 unreachable 
23: 13:50:51.220157       802.1Q vlan#201 P0 192.168.201.200.49168 > 192.168.203.89.33440:  udp 0 
24: 13:50:51.220645       802.1Q vlan#201 P0 192.168.203.89 > 192.168.201.200 icmp: 192.168.203.89 udp port 33440 unreachable 
25: 13:50:54.220264       802.1Q vlan#201 P0 192.168.201.200.49168 > 192.168.203.89.33441:  udp 0 
26: 13:50:54.220752       802.1Q vlan#201 P0 192.168.203.89 > 192.168.201.200 icmp: 192.168.203.89 udp port 33441 unreachable 
27: 13:50:57.220157       802.1Q vlan#201 P0 192.168.201.200.49168 > 192.168.203.89.33442:  udp 0 
28: 13:50:57.220645       802.1Q vlan#201 P0 192.168.203.89 > 192.168.201.200 icmp: 192.168.203.89 udp port 33442 unreachable

Schritt 4

Verfolgen Sie die eingehenden ICMP-Pakete aus dem Ping-Test.

Paket #2 ist die Antwort auf die ICMP-Ping-Anforderung, die in Paket #1 gesendet wurde. 

firepower# show capture CAPI packet-number 2 trace 
190 packets captured
2: 13:50:27.345975       802.1Q vlan#201 P0 192.168.203.89 > 192.168.201.200 icmp: echo reply 
…
Phase: 4
Type: FLOW-LOOKUP
Subtype: 
Result: ALLOW
Elapsed time: 488 ns
Config:
Additional Information:
Found flow with id 143799, using existing flow
…
Phase: 6
Type: ADJACENCY-LOOKUP
Subtype: Resolve Nexthop IP address to MAC
Result: ALLOW
Elapsed time: 1952 ns
Config:
Additional Information:
Found adjacency entry for Next-hop 0.0.0.0 on interface  identity
Adjacency :Active
MAC address 0000.0000.0000 hits 483359 reference 2
Result:
input-interface: OUTSIDE(vrfid:0)
input-status: up
input-line-status: up
output-interface: NP Identity Ifc
Action: allow
Time Taken: 18056 ns
1 packet shown

 Die wichtigsten Punkte der Ablaufverfolgung sind:

  • Das Paket stimmt mit einem vorhandenen Datenfluss überein.
  • Die Ausgabeschnittstelle ist die Firewall selbst (Identitätsschnittstelle).

Schritt 5

Verfolgen Sie die eingehenden ICMP-Pakete aus dem Traceroute-Test.

Paket #12 ist die Antwort des Transit-Hosts:

firepower#  show capture CAPI packet-number 12 trace
190 packets captured
12: 13:50:33.232562       802.1Q vlan#201 P0 192.168.201.88 > 192.168.201.200 icmp: time exceeded in-transit 
Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Elapsed time: 6344 ns
Config:
nat (INSIDE,OUTSIDE) source static server_host interface
Additional Information:
NAT divert to egress interface INSIDE(vrfid:0)
Untranslate 192.168.201.200/49168 to 192.168.200.50/49168
Phase: 7
Type: ACCESS-LIST
Subtype:      
Result: ALLOW
Elapsed time: 97 ns
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268436480 
access-list CSM_FW_ACL_ remark rule-id 268436480: ACCESS POLICY: mzafeiro_empty - Default
access-list CSM_FW_ACL_ remark rule-id 268436480: L4 RULE: DEFAULT ACTION RULE
Additional Information:
 This packet will be sent to snort for additional processing where a verdict will be reached
Phase: 18
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Elapsed time: 16104 ns
Config:
Additional Information:
New flow created with id 143805, packet dispatched to next module
              
Phase: 20
Type: SNORT
Subtype: identity
Result: ALLOW
Elapsed time: 39496 ns
Config:
Additional Information:
user id: no auth, realm id: 0, device type: 0, auth type: invalid, auth proto: basic, username: none, AD domain: none,
src sgt: 0, src sgt type: unknown, dst sgt: 0, dst sgt type: unknown, abp src: none, abp dst: none, location: none
Result:
input-interface: OUTSIDE(vrfid:0)
input-status: up
input-line-status: up
output-interface: INSIDE(vrfid:0)
output-status: up
output-line-status: up
Action: allow
Time Taken: 158341 ns
  • Das Paket ist Teil einer neuen Verbindung (entspricht nicht einem vorhandenen Datenfluss).
  • Das Paket unterliegt der Network Address Translation (Netzwerkadressenumwandlung) (im Besonderen bedeutet UN-NAT "Ziel-NAT").
  • Das Paket wird als Firewall-Datenverkehr behandelt und unterliegt den Zugriffskontrollrichtlinien (ACP, Access Control Policy) und der Snort-Überprüfung.
  • Die Ausgabe-Schnittstelle (Ausgang) ist INSIDE. Dies ist auf die NAT-Übersetzung zurückzuführen. 

In diesem Fall wird das Problem durch die statische NAT-Regel verursacht:

firepower# show run nat
nat (INSIDE,OUTSIDE) source static server_host interface

Verwandte Inhalte

Revisionsverlauf

Überarbeitung Veröffentlichungsdatum Kommentare
1.0
09-Apr-2026
Erstveröffentlichung
TAC Authored

Beiträge von Cisco Ingenieuren

  • Mikis Zafeiroudis
    Cisco TAC-Techniker
  • Ilkin Gasimov
    Cisco TAC-Techniker

War dieses Dokument hilfreich?

FeedbackFeedback

Cisco kontaktieren

Dieses Dokument gilt für folgende Produkte.