Risoluzione dei problemi relativi al traceroute da FTD che non visualizza le informazioni sull'hop nonostante il ping ICMP sia riuscito

Opzioni per il download

PDF (954.9 KB)
Visualizza con Adobe Reader su diversi dispositivi
ePub (854.1 KB)
Visualizza in diverse app su iPhone, iPad, Android, Sony Reader o Windows Phone
Mobi (Kindle) (566.2 KB)
Visualizza su dispositivo Kindle o tramite app Kindle su più dispositivi

Aggiornato:22 aprile 2026

ID documento:225523

Linguaggio senza pregiudizi

La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.

Informazioni su questa traduzione

Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).

Problema

Si manifestano tutti i seguenti sintomi:

Errore di tracciamento routing: I comandi di tracciamento routing avviati direttamente dal dispositivo Cisco Firewall Threat Defense (FTD) restituiscono coerentemente solo * * * per tutti gli hop quando si indirizzano a indirizzi IP esterni.
Connettività riuscita: I test ping ICMP sulla stessa destinazione hanno esito positivo e il traffico ICMP è autorizzato esplicitamente nei criteri di controllo di accesso.

Questo comportamento impedisce la visibilità sugli hop di percorso per il traffico proveniente dal dispositivo FTD, influendo sulle attività di risoluzione dei problemi dei percorsi di rete.

Esempio

Ping sulla destinazione in corso:

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

Ma traceroute non è:

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

Ambiente

Cisco Secure Firewall Threat Defense (FTD).
Prima osservazione: 7.4, 7.4.2.3, 7.6.2. Potrebbero essere interessate anche altre versioni.
Cisco Secure Firewall Management Center (FMC / cdFMC / FDM) per la gestione.
Regole NAT statiche in uso, incluse le configurazioni bidirezionali.
Comandi traceroute eseguiti dalla CLI FTD (modalità Lina).
ICMP consentito nei criteri di controllo di accesso.

Topologia

inline_image_0.png

Risoluzione

Le possibili soluzioni dipendono dallo scopo della regola NAT configurata.

Soluzione 1

Se l'obiettivo era convertire l'IP del server interno solo per l'accesso in uscita, è possibile configurare la regola NAT come unidirezionale.

In FMC ciò può essere fatto dalla regola NAT Opzioni avanzate:

inline_image_0.png

La configurazione NAT distribuita:

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

Verifica

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

Soluzione 2

Se l'obiettivo è che il server interno sia raggiungibile dall'esterno, è possibile rendere la regola NAT più specifica configurando l'inoltro delle porte:

inline_image_0.png

La configurazione NAT distribuita:

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

Verifica

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

Come funziona

Ping

Il firewall invia un messaggio di richiesta echo (ICMP Tipo 8 Codice 0).
Viene creata una nuova connessione firewall per ICMP.
Il firewall riceve un messaggio di risposta echo (ICMP tipo 0 codice 0).
Il messaggio corrisponde alla connessione creata al passaggio 2.
Il messaggio di risposta echo viene utilizzato dal firewall.

Traceroute

Il firewall invia tre pacchetti UDP a partire dalle porte 33434, 33435 e 33436 alla destinazione con TTL 1.
Viene creata una nuova connessione firewall per UDP.
Il firewall riceve un valore TTL ICMP superato in transito (codice tipo 11 0) o una porta ICMP non raggiungibile (codice tipo 3 3).
Una volta che i pacchetti ICMP arrivano sul firewall, vengono trattati come connessioni diverse dai pacchetti UDP del passaggio 2.

Questa condizione può essere rilevata in Wireshark:

inline_image_0.png

Risoluzione dei problemi

Passaggio 1

Abilitare le acquisizioni dei pacchetti sull'interfaccia di uscita del firewall con il comando tracerestituisce il modo in cui il firewall tratta i pacchetti in entrata:

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

Passaggio 2

Test con 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

Provare quindi con traceroute:

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*  *  *
…

Passaggio 3

Controllare il contenuto dell'acquisizione:

I pacchetti da 1 a 10 sono correlati al test ping ICMP.
I pacchetti da 11 a 16 sono correlati a traceroute. Le risposte provengono dal primo hop.
I pacchetti da 17 a 28 sono anche correlati a traceroute. Le risposte provengono dall'endpoint di destinazione.

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

Passaggio 4

Tracciare i pacchetti ICMP in entrata dal test ping.

Il pacchetto 2 è la risposta alla richiesta ping ICMP inviata nel pacchetto 1.

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

I punti chiave della traccia sono:

Il pacchetto corrisponde a un flusso esistente.
L'interfaccia di output è il firewall stesso (interfaccia di identità).

Passaggio 5

Tracciare i pacchetti ICMP in entrata dal test traceroute.

Il pacchetto 12 è la risposta dell'host di transito:

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

Il pacchetto fa parte di una nuova connessione (non corrisponde a un flusso esistente).
Il pacchetto è soggetto a Network Address Translation (in particolare, UN-NAT indica la destinazione NAT).
Il pacchetto viene considerato come traffico di transito attraverso il firewall e viene sottoposto a policy di controllo dell'accesso (ACP, Access Control Policy) e a ispezione Snort.
L'interfaccia di output (uscita) è INSIDE. Ciò è dovuto alla conversione NAT.

Causa

In questo caso, il problema è causato da questa regola NAT statica:

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

Contenuto correlato

Cronologia delle revisioni

Revisione	Data di pubblicazione	Commenti
2.0	22-Apr-2026	Tutto il testo, formattazione.
1.0	09-Apr-2026	Versione iniziale

Contributo dei tecnici Cisco

Mikis Zafeiroudis
Cisco TAC Engineer
Ilkin Gasimov
Cisco TAC Engineer

Questo documento ti è stato utile?

Feedback

Contattaci

Apri una richiesta di assistenza
(Occorre un contratto di servizio Cisco)

Questo documento si applica a questi prodotti

Secure Firewall Threat Defense