Dépanner Traceroute à partir de FTD qui n'affiche pas les informations de saut malgré une requête ping ICMP réussie
Problème
Tous ces symptômes sont visibles :
Les commandes traceroute lancées directement à partir des périphériques Cisco Firewall Threat Defense (FTD) ne renvoient systématiquement que « * * * » pour tous les sauts lors du ciblage d'adresses IP externes
La requête ping ICMP vers les mêmes destinations a abouti et ICMP est explicitement autorisé dans la stratégie de contrôle d’accès.
Ce comportement empêche la visibilité des sauts de chemin pour le trafic provenant du périphérique FTD, ce qui a un impact sur les efforts de dépannage de chemin réseau.
Exemple
La commande ping vers la destination fonctionne :
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
Mais traceroute n'est pas :
firepower# traceroute 192.168.203.89 Type escape sequence to abort. Tracing the route to 192.168.203.89 1* * * 2* * * 3* * * ... 30* * * firepower#
Environnement
- Cisco Secure Firewall Threat Defense (FTD).
- Première fois observée à : 7.4, 7.4.2.3, 7.6.2. D'autres versions pourraient également être affectées.
- Cisco Secure Firewall Management Center (FMC / cdFMC / FDM) pour la gestion.
- Règles NAT statiques utilisées, y compris les configurations bidirectionnelles.
- Commandes traceroute exécutées à partir de l’interface de ligne de commande FTD (mode Lina).
- ICMP autorisé dans la stratégie de contrôle d’accès.
Topologie
Résolution
Les solutions possibles dépendent de l'objectif de la règle NAT configurée.
Solution 1
Si l'objectif était de traduire l'adresse IP du serveur interne uniquement pour l'accès sortant, vous pouvez configurer la règle NAT comme étant unidirectionnelle.
Sur FMC, ceci peut être fait à partir des options avancées de la règle NAT :
La configuration NAT déployée :
firepower# show run nat nat (INSIDE,OUTSIDE) source static server_host interface unidirectional firepower#
Vérification
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
Solution 2
Si l'objectif est que le serveur interne soit accessible de l'extérieur, vous pouvez rendre la règle NAT plus spécifique en configurant le transfert de port :
La configuration NAT déployée :
firepower# show run nat nat (INSIDE,OUTSIDE) source static server_host interface service SVC_25769850586 SVC_25769850587
Vérification
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
Comment ça fonctionne
Ping
- Le pare-feu envoie un message de requête d’écho (ICMP Type 8 Code 0).
- Une nouvelle connexion de pare-feu est créée pour ICMP.
- Le pare-feu reçoit un message de réponse d’écho (ICMP Type 0 Code 0).
- Le message correspond à la connexion créée à l'étape 2.
- Le message de réponse d'écho est utilisé par le pare-feu.
Traceroute
- Le pare-feu envoie trois paquets UDP à partir des ports 33434, 33435 et 33436 vers la destination avec TTL 1.
- Une nouvelle connexion de pare-feu est créée pour UDP.
- Le pare-feu reçoit soit une durée de vie ICMP dépassée en transit (code 0 de type 1), soit un port ICMP inaccessible (code 3 de type 3).
- Une fois que les paquets ICMP arrivent sur le pare-feu, ils sont traités comme des connexions différentes des paquets UDP de l'étape 2.
Ceci peut être vu dans Wireshark :
Dépannage
Étape 1
Activez les captures de paquets sur l'interface de sortie du pare-feu avec le suivi pour voir comment le pare-feu traite les paquets entrants :
firepower# capture CAPI trace interface OUTSIDE match ip host 192.168.203.89 host 192.168.201.100
Étape 2
Testez à l'aide de 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
Testez ensuite avec 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* * * …
Étape 3
Vérifiez le contenu de la capture :
- Les paquets 1 à 10 sont liés au test ping ICMP.
- Les paquets 11 à 16 sont liés à traceroute. Les réponses proviennent du premier saut.
- Les paquets 17 à 28 sont également liés à traceroute. Les réponses proviennent du point d’extrémité de destination.
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
Étape 4
Suivez les paquets ICMP entrants à partir du test ping.
Le paquet #2 est la réponse à la requête ping ICMP envoyée dans le paquet #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
Les points clés de la trace sont les suivants :
- Le paquet correspondait à un flux existant.
- L'interface de sortie est le pare-feu lui-même (interface d'identité).
Étape 5
Suivez les paquets ICMP entrants à partir du test traceroute.
Le paquet #12 est la réponse de l’hôte de transit :
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
- Le paquet fait partie d'une nouvelle connexion (il ne correspond pas à un flux existant).
- Le paquet est soumis à la traduction d’adresses réseau (plus précisément, la NAT-ONU signifie « NAT de destination »).
- Le paquet est traité comme un trafic de transit de pare-feu et est soumis à la politique de contrôle d'accès (ACP) et à l'inspection Snort.
- L'interface de sortie (sortie) est INSIDE. Cela est dû à la traduction NAT.
Dans ce cas, le problème est causé par cette règle NAT statique :
firepower# show run nat nat (INSIDE,OUTSIDE) source static server_host interface
Autres informations utiles
- Autoriser Traceroute via Firepower Threat Defense (FTD)
- Assistance technique de Cisco et téléchargements
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
09-Apr-2026
|
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)