Dépannage de la configuration de la traduction d'adresses réseau ASA

Introduction

Ce document décrit comment dépanner la configuration NAT (Network Address Translation) sur la plate-forme Cisco Adaptive Security Appliance (ASA). Ce document est valide pour ASA version 8.3 et ultérieures.

Note: Pour obtenir quelques exemples de configuration NAT de base, qui incluent une vidéo qui montre une configuration NAT de base, reportez-vous à la section Informations connexes au bas de ce document.

Dépannage de la configuration NAT sur l'ASA

Lorsque vous dépannez des configurations NAT, il est important de comprendre comment la configuration NAT sur l'ASA est utilisée pour créer la table de stratégies NAT.

Ces erreurs de configuration expliquent la majorité des problèmes NAT rencontrés par les administrateurs ASA :

• Les règles de configuration NAT ne sont pas en ordre. Par exemple, une règle NAT manuelle est placée en haut de la table NAT, ce qui fait que des règles plus spécifiques placées plus loin dans la table NAT ne seront jamais touchées.
• Les objets réseau utilisés dans la configuration NAT sont trop étendus, ce qui fait que le trafic correspond par inadvertance à ces règles NAT et qu'il manque des règles NAT plus spécifiques.

L'utilitaire packet tracer peut être utilisé pour diagnostiquer la plupart des problèmes liés à la NAT sur l'ASA. Reportez-vous à la section suivante pour plus d'informations sur l'utilisation de la configuration NAT pour créer la table de stratégies NAT, ainsi que sur la façon de dépanner et résoudre des problèmes NAT spécifiques.

En outre, la commande show nat detail peut être utilisée afin de comprendre quelles règles NAT sont touchées par de nouvelles connexions.

Utilisation de la configuration ASA pour créer la table de stratégie NAT

Tous les paquets traités par l'ASA sont évalués par rapport à la table NAT. Cette évaluation commence en haut (Section 1) et s'arrête jusqu'à ce qu'une règle NAT soit mise en correspondance. Une fois qu'une règle NAT est mise en correspondance, cette règle NAT est appliquée à la connexion et aucune autre stratégie NAT n'est vérifiée par rapport au paquet.

La stratégie NAT sur l'ASA est créée à partir de la configuration NAT.

Les trois sections de la table NAT ASA sont les suivantes :

Section 1	Stratégies NAT manuelles Ils sont traités dans l'ordre dans lequel ils apparaissent dans la configuration.
Section 2	Stratégies NAT automatiques Elles sont traitées en fonction du type NAT (statique ou dynamique) et de la longueur du préfixe (masque de sous-réseau) dans l'objet.
Section 3	Stratégies NAT manuelles après auto Ils sont traités dans l'ordre dans lequel ils apparaissent dans la configuration.

Ce schéma montre les différentes sections NAT et leur ordre :

Cet exemple montre comment la configuration NAT d'ASA avec deux règles (une instruction NAT manuelle et une configuration NAT automatique) sont représentées dans la table NAT :

Comment dépanner les problèmes NAT

Utilisation de l’utilitaire Packet Tracer

Afin de résoudre les problèmes de configuration NAT, utilisez l'utilitaire packet tracer afin de vérifier qu'un paquet atteint la stratégie NAT. Packet Tracer vous permet de spécifier un exemple de paquet qui entre dans l'ASA, et l'ASA indique quelle configuration s'applique au paquet et si elle est autorisée ou non.

Dans l’exemple ci-dessous, un exemple de paquet TCP qui entre dans l’interface interne et est destiné à un hôte sur Internet est fourni. L'utilitaire packet tracer indique que le paquet correspond à une règle NAT dynamique et est traduit en adresse IP externe 172.16.123.4 :

ASA# packet-tracer input inside tcp 10.10.10.123 12345 209.165.200.123 80

...(output omitted)...

Phase: 2
Type: NAT
Subtype: 
Result: ALLOW
Config:
object network 10.10.10.0-net
 nat (inside,outside) dynamic interface
Additional Information:
Dynamic translate 10.10.10.123/12345 to 172.16.123.4/12345

...(output omitted)...

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

ASA# 

Choisissez la règle NAT et cliquez sur Packet Trace afin d'activer Packet Trace à partir de Cisco Adaptive Security Device Manager (ASDM). Cette opération utilise les adresses IP spécifiées dans la règle NAT comme entrées pour l’outil Packet Tracer :

Afficher le résultat de la commande Show Nat

La sortie de la commande show nat detail peut être utilisée afin d'afficher la table de stratégie NAT. Plus précisément, les compteurs translation_hits et untranslation_hits peuvent être utilisés afin de déterminer quelles entrées NAT sont utilisées sur l'ASA. Si vous voyez que votre nouvelle règle NAT n'a pas translation_hits ou untranslation_hits, cela signifie que le trafic n'arrive pas à l'ASA, ou peut-être qu'une autre règle qui a une priorité plus élevée dans la table NAT correspond au trafic.

Voici la configuration NAT et la table de stratégies NAT d'une configuration ASA différente :

Dans l'exemple précédent, six règles NAT sont configurées sur cet ASA. La sortie show nat montre comment ces règles sont utilisées pour construire la table de stratégie NAT, ainsi que le nombre de translate_hits et untranslation_hits pour chaque règle. Ces compteurs de succès ne s'incrémentent qu'une seule fois par connexion. Une fois la connexion établie via l'ASA, les paquets suivants qui correspondent à cette connexion actuelle n'incrémentent pas les lignes NAT (tout comme le nombre d'occurrences de liste d'accès fonctionne sur l'ASA).

Translate_hits : Nombre de nouvelles connexions qui correspondent à la règle NAT dans la direction de transfert.

« Direction de transfert » signifie que la connexion a été créée par l'ASA dans la direction des interfaces spécifiées dans la règle NAT. Si une règle NAT spécifie que le serveur interne est traduit vers l'interface externe, l'ordre des interfaces dans la règle NAT est « nat (interne, externe)... »; si ce serveur initie une nouvelle connexion à un hôte externe, le compteur translation_hit s'incrémente.

Untranslation_hits : Nombre de nouvelles connexions qui correspondent à la règle NAT dans la direction inverse.

Si une règle NAT spécifie que le serveur interne est traduit vers l'interface externe, l'ordre des interfaces dans la règle NAT est « nat (interne, externe)... »; si un client situé à l'extérieur de l'ASA initie une nouvelle connexion au serveur situé à l'intérieur, le compteur untranslation_hit s'incrémente.

Encore une fois, si vous voyez que votre nouvelle règle NAT n'a ni translation_hits ni untranslation_hits, cela signifie que le trafic n'arrive pas à l'ASA, ou peut-être qu'une autre règle qui a une priorité plus élevée dans la table NAT correspond au trafic.

Méthodologie de dépannage des problèmes NAT

Utilisez packet tracer afin de confirmer qu'un exemple de paquet correspond à la règle de configuration NAT appropriée sur l'ASA. Utilisez la commande show nat detail afin de comprendre quelles règles de stratégie NAT sont entrées. Si une connexion correspond à une configuration NAT différente de celle prévue, procédez aux opérations suivantes :

• Existe-t-il une règle NAT différente qui a priorité sur la règle NAT que vous aviez l'intention d'atteindre pour le trafic ?
• Existe-t-il une règle NAT différente avec des définitions d'objet trop larges (le masque de sous-réseau est trop court, par exemple 255.0.0.0), ce qui fait que ce trafic correspond à la mauvaise règle ?
• Les politiques NAT manuelles sont-elles en panne, ce qui fait que le paquet ne correspond pas à la bonne règle ?
• Votre règle NAT est-elle mal configurée, ce qui fait que la règle ne correspond pas à votre trafic ?

Reportez-vous à la section suivante pour obtenir des exemples de problèmes et de solutions.

Problèmes courants avec les configurations NAT

Voici quelques problèmes courants rencontrés lors de la configuration de NAT sur l'ASA.

Problème : Le trafic échoue en raison d'une erreur RPF (NAT Reverse Path Failure) : Règles NAT asymétriques correspondant aux flux de transfert et de retour

Le contrôle NAT RPF garantit qu'une connexion qui est traduite par l'ASA dans la direction de transfert, telle que la synchronisation TCP (SYN), est traduite par la même règle NAT dans la direction inverse, telle que TCP SYN/Acknowledgement (ACK).

Le plus souvent, ce problème est causé par des connexions entrantes destinées à l'adresse locale (non traduite) dans une instruction NAT. À un niveau de base, le NAT RPF vérifie que la connexion inverse du serveur au client correspond à la même règle NAT ; dans le cas contraire, le contrôle NAT RPF échoue. 

Exemple :

Lorsque l'hôte externe 209.165.200.225 envoie un paquet destiné directement à l'adresse IP locale (non traduite) 10.2.3.2, l'ASA abandonne le paquet et consigne ce syslog :

%ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows;
Connection for icmp src outside:209.165.200.225 dst inside:10.2.3.2 (type 8, code 0)
denied due to NAT reverse path failure

Solution :

Tout d’abord, assurez-vous que l’hôte envoie les données à l’adresse NAT globale correcte. Si l’hôte envoie des paquets destinés à la bonne adresse, vérifiez les règles NAT qui sont touchées par la connexion. Vérifiez que les règles NAT sont correctement définies et que les objets référencés dans les règles NAT sont corrects. Vérifiez également que l'ordre des règles NAT est approprié.

Utilisez l'utilitaire packet tracer afin de spécifier les détails du paquet refusé. Packet Tracer doit afficher le paquet abandonné en raison de l’échec du contrôle RPF. Ensuite, regardez la sortie de packet tracer afin de voir quelles règles NAT sont atteintes dans la phase NAT et la phase NAT-RPF.

Si un paquet correspond à une règle NAT dans la phase NAT RPF-check, qui indique que le flux inverse atteindrait une traduction NAT, mais ne correspond pas à une règle dans la phase NAT, qui indique que le flux de transfert n'atteindrait PAS une règle NAT, le paquet est abandonné.

Ce résultat correspond au scénario présenté dans le schéma précédent, où l'hôte externe envoie incorrectement le trafic à l'adresse IP locale du serveur et non à l'adresse IP globale (traduite) :

ASA# packet-tracer input outside tcp 209.165.200.225 1234 10.2.3.2 80

    .....

Phase: 8
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
object network inside-server
 nat (inside,outside) static 172.18.22.1
Additional Information:
...
ASA(config)# 

Lorsque le paquet est destiné à l'adresse IP mappée correcte de 172.18.22.1, le paquet correspond à la règle NAT correcte dans la phase UN-NAT dans la direction de transfert, et à la même règle dans la phase NAT RPF-check :

ASA(config)# packet-tracer input outside tcp 209.165.200.225 1234 172.18.22.1 80
...
Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
object network inside-server
 nat (inside,outside) static 172.18.22.1
Additional Information:
NAT divert to egress interface inside
Untranslate 172.18.22.1/80 to 10.2.3.2/80
...
Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
object network inside-server
 nat (inside,outside) static 172.18.22.1
Additional Information:
...

ASA(config)# 

Problème : Les règles NAT manuelles sont en panne, ce qui entraîne des correspondances de paquets incorrectes

Les règles NAT manuelles sont traitées en fonction de leur apparence dans la configuration. Si une règle NAT très large est répertoriée en premier dans la configuration, elle peut remplacer une autre règle plus spécifique dans la table NAT. Utiliser Packet Tracer afin de vérifier quelle règle NAT touche votre trafic ; il peut être nécessaire de réorganiser les entrées NAT manuelles dans un ordre différent. 

Solution :

Réorganiser les règles NAT avec ASDM.

Solution :

Les règles NAT peuvent être réordonnées avec l'interface de ligne de commande si vous supprimez la règle et la réinsérez à un numéro de ligne spécifique. Afin d'insérer une nouvelle règle sur une ligne spécifique, entrez le numéro de ligne juste après que les interfaces ont été spécifiées.

Exemple :

ASA(config)# nat (inside,outside) 1 source static 10.10.10.0-net
10.10.10.0-net destination static 192.168.1.0-net 192.168.1.0-net

Problème : Une règle NAT est trop large et correspond à un certain trafic par inadvertance

Parfois, des règles NAT sont créées qui utilisent des objets trop larges. Si ces règles sont placées près du haut de la table NAT (en haut de la section 1, par exemple), elles peuvent correspondre à plus de trafic que prévu et faire en sorte que les règles NAT plus loin dans la table ne soient jamais touchées.

Solution :

Utilisez packet tracer afin de déterminer si votre trafic correspond à une règle avec des définitions d'objet trop larges. Si c'est le cas, vous devez réduire la portée de ces objets, ou déplacer les règles plus loin dans la table NAT, ou dans la section post-auto (Section 3) de la table NAT.

Problème : Une règle NAT dévie le trafic vers une interface incorrecte

Les règles NAT peuvent avoir préséance sur la table de routage lorsqu’elles déterminent l’interface à laquelle un paquet quittera l’ASA. Si un paquet entrant correspond à une adresse IP traduite dans une instruction NAT, la règle NAT est utilisée afin de déterminer l'interface de sortie.

Le contrôle de déroutement NAT (qui peut remplacer la table de routage) vérifie s'il existe une règle NAT qui spécifie la traduction d'adresse de destination pour un paquet entrant qui arrive sur une interface. Si aucune règle ne spécifie explicitement comment traduire l'adresse IP de destination de ce paquet, la table de routage globale est consultée pour déterminer l'interface de sortie. S'il existe une règle qui spécifie explicitement comment traduire l'adresse IP de destination des paquets, alors la règle NAT « extrait » le paquet vers l'autre interface de la traduction et la table de routage globale est effectivement contournée.

Ce problème est le plus souvent observé pour le trafic entrant, qui arrive sur l'interface externe, et est généralement dû à des règles NAT en panne qui détournent le trafic vers des interfaces non intentionnelles.

Exemple :

Solutions :

Ce problème peut être résolu par l'une des actions suivantes :

• Réorganisez la table NAT de sorte que l'entrée plus spécifique soit listée en premier.
• Utilisez des plages d'adresses IP globales qui ne se chevauchent pas pour les instructions NAT.

Notez que si la règle NAT est une règle d'identité (ce qui signifie que les adresses IP ne sont pas modifiées par la règle), le mot clé route-lookup peut être utilisé (ce mot clé ne s'applique pas à l'exemple ci-dessus puisque la règle NAT n'est pas une règle d'identité). Le mot clé route-lookup entraîne l'exécution d'une vérification supplémentaire par l'ASA lorsqu'il correspond à une règle NAT. Il vérifie que la table de routage de l'ASA transfère le paquet à la même interface de sortie à laquelle cette configuration NAT dévie le paquet. Si l'interface de sortie de la table de routage ne correspond pas à l'interface de déroutement NAT, la règle NAT n'est pas mise en correspondance (la règle est ignorée) et le paquet continue à descendre la table NAT pour être traité par une règle NAT ultérieure.

L'option de recherche de route n'est disponible que si la règle NAT est une règle NAT 'identity', ce qui signifie que les adresses IP ne sont pas modifiées par la règle. L'option route-lookup peut être activée par règle NAT si vous ajoutez route-lookup à la fin de la ligne NAT, ou si vous activez la case à cocher Lookup route table pour localiser l'interface de sortie dans la configuration de règle NAT dans ASDM :

Problème : Une règle NAT entraîne le protocole ARP (ASA to Proxy Address Resolution Protocol) pour le trafic sur l'interface mappée

Les ARP proxy ASA pour la plage d'adresses IP globales dans une instruction NAT sur l'interface globale. Cette fonctionnalité ARP proxy peut être désactivée sur la base d'une règle NAT si vous ajoutez le mot clé no-proxy-arp à l'instruction NAT.

Ce problème est également observé lorsque le sous-réseau d’adresses globales est créé par inadvertance pour être beaucoup plus grand qu’il n’était prévu.

Solution :

Ajoutez le mot clé no-proxy-arp à la ligne NAT si possible.

Exemple :

ASA(config)# object network inside-server
ASA(config-network-object)# nat (inside,outside) static 172.18.22.1 no-proxy-arp
ASA(config-network-object)# end
ASA#
  ASA# show run nat
object network inside-server
 nat (inside,outside) static 172.18.22.1 no-proxy-arp
ASA#

Cela peut également être réalisé avec ASDM. Dans la règle NAT, cochez la case Désactiver le proxy ARP sur l'interface de sortie.

Informations connexes

• VIDÉO : Transfert de port ASA pour l'accès au serveur DMZ (versions 8.3 et 8.4)
• Configuration NAT de base pour ASA : Webserver dans la DMZ dans ASA version 8.3 et ultérieure
• Livre 2 : Guide de configuration de l'interface de ligne de commande du pare-feu de la gamme Cisco ASA, 9.1 
• Support et documentation techniques - Cisco Systems

Historique de révision