Resolución de Problemas de Traceroute desde FTD que No Muestra Información de Salto a Pesar del Ping ICMP Exitoso

Problema

Se observan todos estos síntomas:

• Falla de traceroute: Los comandos de traceroute iniciados directamente desde el dispositivo Cisco Firewall Threat Defence (FTD) devuelven de forma uniforme sólo * * * para todos los saltos cuando tienen como objetivo direcciones IP externas.

• Conectividad satisfactoria: Las pruebas de ping ICMP al mismo destino se realizan correctamente y el tráfico ICMP está permitido explícitamente en la política de control de acceso.

Este comportamiento impide la visibilidad de los saltos de ruta para el tráfico que se origina en el dispositivo FTD, lo que afecta a los esfuerzos de resolución de problemas de la ruta de red.

Ejemplo:

El ping al destino funciona:

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

Pero traceroute no funciona:

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

Entorno

• Cisco Secure Firewall Threat Defence (FTD).

• Primera vez observado a las: 7.4, 7.4.2.3, 7.6.2. Otras versiones también podrían verse afectadas.

• Cisco Secure Firewall Management Center (FMC / cdFMC / FDM) para la gestión.

• Reglas NAT estáticas en uso, incluidas las configuraciones bidireccionales.

• Comandos de traceroute ejecutados desde la CLI de FTD (modo de línea).

• ICMP permitido en la política de control de acceso.

Topología

Resolución

Las posibles soluciones dependen del propósito de la regla NAT configurada.

Solución 1

Si el objetivo era traducir la IP del servidor interno sólo para el acceso saliente, puede configurar la regla NAT como unidireccional.

En FMC esto se puede hacer desde las opciones avanzadas de la regla NAT:

La configuración de NAT implementada:

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

Verificación

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

Solución 2

Si el objetivo es que el servidor interno sea accesible desde el exterior, puede hacer que la regla NAT sea más específica mediante la configuración del reenvío de puertos:

La configuración de NAT implementada:

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

Verificación

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

Cómo funciona

Ping

1.- El firewall envía un mensaje de solicitud de eco (ICMP tipo 8 código 0).

2.- Se crea una nueva conexión de firewall para ICMP.

3.- El firewall recibe un mensaje de respuesta de eco (ICMP tipo 0 código 0).

4.- El mensaje coincide con la conexión creada en el paso 2.

5.- El mensaje de respuesta de eco es consumido por el firewall.

Traceroute

1.- El firewall envía tres paquetes UDP desde los puertos, 33434, 33435 y 33436 hacia el destino con TTL 1.

2.- Se crea una nueva conexión de firewall para UDP.

3.- El firewall recibe un ICMP TTL excedido en tránsito (Tipo 1 Código 0) o un ICMP Puerto inalcanzable (Tipo 3 Código 3).

4.- Una vez que los paquetes ICMP llegan al firewall, se tratan como conexiones diferentes a los paquetes UDP del paso 2.

Esto se puede ver en Wireshark:

Troubleshoot

Paso 1

Habilite las capturas de paquetes en la interfaz de salida del firewall con seguimiento para ver cómo el firewall trata los paquetes de entrada:

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

Paso 2

Prueba 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

A continuación, pruebe 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*  *  *
…

Paso 3

Verifique el contenido de la captura:

• Los paquetes 1-10 están relacionados con la prueba ICMP ping.

• Los paquetes 11-16 están relacionados con traceroute. Las respuestas son del primer salto.

• Los paquetes 17-28 también están relacionados con traceroute. Las respuestas proceden del punto final de destino.

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

Paso 4

Rastree los paquetes ICMP de ingreso de la prueba de ping.

El paquete #2 es la respuesta a la solicitud de ping ICMP enviada en el paquete #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

Los puntos clave del seguimiento son:

• El paquete coincidió con un flujo existente.

• La interfaz de salida es el propio firewall (interfaz de identidad).

Paso 5

Rastree los paquetes ICMP de ingreso desde la prueba de traceroute.

El paquete #12 es la respuesta del host de tránsito:

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

• El paquete forma parte de una nueva conexión (no coincide con un flujo existente).

• El paquete está sujeto a la Traducción de direcciones de red (específicamente, la NAT-UN significa NAT de destino).

• El paquete se trata como tráfico de tránsito de firewall y está sujeto a la política de control de acceso (ACP) y a la inspección de Snort.

• La interfaz de salida (salida) es INSIDE. Esto se debe a la traducción NAT.

Causa

En este caso, el problema es causado por esta regla de NAT estática:

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

Contenido relacionado

• Permitir Traceroute mediante Firepower Threat Defence (FTD)

• Soporte técnico y descargas de Cisco

Historial de revisiones

Revisión	Fecha de publicación	Comentarios
4.0	09-Jul-2026	Recargó las imágenes y arregló algunos textos.
2.0	22-Apr-2026	Todo el texto, formato.
1.0	09-Apr-2026	Versión inicial