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 :

• Échec de traceroute : Les commandes traceroute lancées directement à partir du périphérique Cisco Firewall Threat Defense (FTD) ne renvoient systématiquement que * * * pour tous les sauts lors du ciblage d'adresses IP externes.

• Connectivité réussie : Les tests ping ICMP vers la même destination aboutissent et le trafic 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

image_en_ligne_0.png

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 :

image_en_ligne_0.png

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 :

image_en_ligne_0.png

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

Comment ça fonctionne

Ping

1. Le pare-feu envoie un message de requête d’écho (ICMP Type 8 Code 0).

2. Une nouvelle connexion de pare-feu est créée pour ICMP.

3. Le pare-feu reçoit un message de réponse d’écho (ICMP Type 0 Code 0).

4. Le message correspond à la connexion créée à l'étape 2.

5. Le message de réponse d'écho est utilisé par le pare-feu.

Traceroute

1. Le pare-feu envoie trois paquets UDP à partir des ports 33434, 33435 et 33436 vers la destination avec TTL 1.

2. Une nouvelle connexion de pare-feu est créée pour UDP.

3. 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).

4. 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 :

image_en_ligne_0.png

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, l'UN-NAT 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. 

Motif

 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