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

Actualizado:9 de abril de 2026

ID del documento:225523

Lenguaje no discriminatorio

El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.

Acerca de esta traducción

Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).

Problema

Se observan todos estos síntomas:

Los comandos de traceroute iniciados directamente desde los dispositivos Cisco Firewall Threat Defence (FTD) devuelven de forma coherente solo "* *" para todos los saltos cuando se dirigen a direcciones IP externas
El ping ICMP a los mismos destinos es exitoso y se permite explícitamente el ICMP 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 es:

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 observada en: 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

El firewall envía un mensaje de solicitud de eco (ICMP tipo 8 código 0).
Se crea una nueva conexión de firewall para ICMP.
El firewall recibe un mensaje de respuesta de eco (ICMP tipo 0 código 0).
El mensaje coincide con la conexión creada en el paso 2.
El firewall consume el mensaje de respuesta de eco.

Traceroute

El firewall envía tres paquetes UDP que parten de los puertos 33434, 33435 y 33436 hacia el destino con TTL 1.
Se crea una nueva conexión de firewall para UDP.
El firewall recibe un ICMP TTL superado en tránsito (tipo 11 código 0) o un puerto ICMP inalcanzable (tipo 3 código 3).
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: