ASA : Échec de l'accès entrant aux adresses NAT après la mise à niveau vers 8.4(3)

Introduction

Ce document fournit des informations sur les adresses NAT qui échouent après la mise à niveau de l'ASA (Adaptive Security Appliance) vers la version 8.4(3). Ce document fournit également une solution à ce problème.

Conditions préalables

Conditions requises

Les lecteurs de ce document devraient avoir connaissance des sujets suivants .

• Compréhension de base du concept ARP (Address Resolution Protocol) et ARP proxy

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes .

• Tout dispositif de sécurité adaptatif de la gamme Cisco ASA 5500

• Adaptive Security Appliance version 8.4(3) ou ultérieure

Conventions

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

Symptômes

À partir de la version 8.4(3) d'ASA, l'ASA ne répond pas aux requêtes ARP reçues sur une interface, pour les adresses IP qui ne font pas partie du sous-réseau IP de cette interface. Avant la version 8.4(3), l'ASA répondait aux requêtes ARP qui ne se trouvaient pas dans le sous-réseau IP de l'interface ASA.

Cette modification peut se manifester immédiatement après la mise à niveau de l'ASA vers la version 8.4(3). Dans certains cas, les utilisateurs d'Internet ne peuvent pas se connecter à l'adresse globale d'un serveur traduit via l'ASA.

Ce message s'affiche si cette situation est rencontrée et 'debug arp' est activé sur l'interface de ligne de commande de l'ASA :

arp-in: Arp packet received from 192.168.10.1 which is in different subnet 
than the connected interface 192.168.11.1/255.255.255.0

La cause première de ce problème n'est pas un bogue. Consultez les informations ci-dessous pour en savoir plus sur les causes potentielles et les solutions à ce problème.

Conditions / Environnement

Pour faire face à cette situation, l'ASA doit recevoir une requête ARP pour une adresse IP qui correspond à une adresse globale dans une traduction NAT configurée. L'adresse IP globale doit résider dans un sous-réseau IP différent du sous-réseau IP configuré sur l'interface ASA.

Description de la cause/du problème

Afin de comprendre toutes les ramifications de cette question, il est important de bien comprendre comment cette question peut apparaître et la meilleure façon d'atténuer le problème.

Voici quelques cas où cette situation peut se produire :

Le périphérique en amont a des routes IP configurées sans adresse IP de tronçon suivant

C'est probablement la cause la plus courante de cette situation. Cela est dû à une configuration non optimale d'un périphérique en amont. Il est préférable de configurer des routes IP de sorte que le prochain saut de la route IP soit une adresse IP dans le même sous-réseau que l'adresse de cette interface :

ip route 10.1.2.0 255.255.255.0 192.168.1.2

Cependant, parfois, les administrateurs réseau configurent une interface au lieu d’une adresse IP comme saut suivant :

ip route 10.1.2.0 255.255.255.0 FastEthernet0/1

Le routeur achemine ainsi le trafic destiné au réseau 10.1.2.0/24 vers l’interface FastEthernet0/1 et envoie une requête ARP pour l’adresse IP de destination dans le paquet IP. Il est supposé qu’un périphérique répond à la requête ARP et que le routeur transfère ensuite le paquet à l’adresse MAC qui a été résolue en raison du processus ARP. Les avantages de ce type de configuration sont qu'il est très facile à configurer et à administrer. L'administrateur n'a pas à configurer explicitement une adresse IP de tronçon suivant pour la route, et il suppose qu'un périphérique adjacent aura le proxy-ARP activé et répondra à la requête ARP s'il est capable de router les paquets vers l'adresse IP de destination.

Cependant, ce type de configuration de route IP présente de sérieux problèmes :

• En envoyant une requête ARP pour déterminer le prochain saut pour le trafic IP, le routeur est exposé à des problèmes causés par d’autres périphériques qui pourraient répondre incorrectement à cette requête ARP. Il en résulte que le trafic peut être verrouillé en noir lorsqu'il est envoyé à un périphérique incorrect.

• La route entraîne l’envoi par le périphérique d’une requête ARP pour chaque adresse de destination unique dans les paquets qui correspondent à la route. Cela peut provoquer une grande quantité de trafic ARP sur le sous-réseau et affecter les performances ainsi que l'espace mémoire nécessaire pour contenir une quantité potentiellement importante d'entrées ARP.

• Comme l'espace de table ARP est une ressource liée à la mémoire, un nombre excessif d'entrées peut avoir un impact négatif sur les performances et la stabilité du routeur.

Par conséquent, la meilleure pratique est de configurer toutes les routes avec des adresses de tronçon suivant IP explicites et de ne pas utiliser de routes qui ont un nom d'interface seul pour identifier l'interface sortante. Si l'interface est nécessaire pour lier la route à l'interface de sortie pour le basculement, entrez le nom de l'interface de sortie et le saut suivant dans la route statique.

Compte tenu des implications administratives pour certains clients Cisco, une demande d'amélioration a été ouverte afin de rendre le nouveau comportement sécurisé configurable : ID de bogue Cisco CSCty95468 (clients enregistrés uniquement) (ENH : Ajouter une commande pour autoriser les entrées du cache ARP à partir de sous-réseaux non connectés).

Masques de sous-réseau IP non concordants sur les périphériques adjacents

Des masques de sous-réseau IP non concordants configurés sur l'interface de l'ASA et l'interface du périphérique adjacent peuvent provoquer une situation similaire. Si le périphérique adjacent avait un masque de sous-réseau qui était un super-réseau (255.255.240.0) du masque de sous-réseau IP de l'interface ASA (255.255.255.0), le périphérique adjacent effectuera le protocole ARP pour les adresses IP qui ne figurent pas dans le sous-réseau IP de l'interface ASA. Vérifiez que les masques de sous-réseau sont corrects.

Implications du mode transparent

Un autre effet secondaire de cette modification est l'incapacité à apprendre les adresses MAC à partir de sous-réseaux non directement connectés en mode transparent. Cela affecte la communication dans ces scénarios :

• L'ASA transparent n'a pas d'adresse IP de gestion configurée ou la configuration est incorrecte.

• L'ASA transparent utilise des sous-réseaux secondaires sur le même segment.

Il n'existe aucune solution de contournement pour ce problème en mode transparent autre que la rétrogradation. Cependant, cette demande d'amélioration a été ouverte afin de rendre ASA interopérable avec les sous-réseaux secondaires en mode transparent : ID de bogue Cisco CSCty49855 (clients enregistrés uniquement) (ENH : Prendre en charge les hôtes non directement connectés dans le mécanisme de découverte MAC).

Résolution

La solution à ce problème (dans le cas où l'adresse IP en question ne se trouve pas dans le même sous-réseau de couche 3 que l'adresse IP de l'interface ASA) consiste à apporter les modifications nécessaires pour s'assurer que les périphériques adjacents à l'ASA acheminent le trafic directement vers l'adresse IP de l'interface ASA comme périphérique de tronçon suivant, au lieu de compter sur un périphérique pour proxy-ARP au nom de l'adresse IP.

Informations connexes

• Support et documentation techniques - Cisco Systems

Historique de révision