ASA: El acceso entrante a direcciones NAT falla después de actualizar a 8.4(3)

Introducción

Este documento proporciona información sobre las direcciones NAT que fallan después de actualizar Adaptive Security Appliance (ASA) a la versión 8.4(3). Este documento también proporciona una solución a este problema.

Prerequisites

Requirements

Quienes lean este documento deben tener conocimiento de los siguientes temas.

• Comprensión básica del concepto de protocolo de resolución de direcciones (ARP) y ARP proxy

Componentes Utilizados

La información de este documento se basa en estas versiones de hardware y software.

• Cualquier dispositivo de seguridad adaptable Cisco ASA serie 5500

• Adaptive Security Appliance versión 8.4(3) o posterior

Convenciones

Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.

Síntomas

A partir de la versión 8.4(3) de ASA, el ASA no responde a las solicitudes ARP recibidas en una interfaz, para las direcciones IP que no forman parte de la subred IP de esa interfaz. Antes de la versión 8.4(3), el ASA respondía a las solicitudes ARP que no estaban en la subred IP de la interfaz de ASA.

Este cambio puede manifestarse inmediatamente después de actualizar el ASA a la versión 8.4(3). En algunos casos, los usuarios de Internet no pueden conectarse a la dirección global de un servidor traducido a través del ASA.

Este mensaje se muestra si se encuentra esta situación y 'debug arp' está habilitado en la CLI de 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 causa raíz de este problema no es un error. Consulte la siguiente información para obtener más información sobre las posibles causas y soluciones del problema.

Condiciones/Entorno

Para encontrar esta situación, el ASA debe recibir una solicitud ARP para una dirección IP que coincida con una dirección global en una traducción NAT configurada. La dirección IP global debe residir en una subred IP diferente de la subred IP configurada en la interfaz de ASA.

Descripción de la causa/problema

Para comprender todas las ramificaciones de esta cuestión, es importante comprender completamente cómo puede aparecer este problema y cuál es la mejor manera de mitigarlo.

Estos son algunos casos en los que se puede encontrar esta situación:

El dispositivo ascendente tiene rutas IP configuradas sin dirección IP de siguiente salto

Esta es probablemente la causa más común de esta situación. Se debe a una configuración no óptima de un dispositivo ascendente. Se prefiere configurar las rutas IP de modo que el salto siguiente de la ruta IP sea una dirección IP en la misma subred que la dirección de esa interfaz:

ip route 10.1.2.0 255.255.255.0 192.168.1.2

Sin embargo, a veces los administradores de red configuran una interfaz en lugar de una dirección IP como salto siguiente:

ip route 10.1.2.0 255.255.255.0 FastEthernet0/1

Esto hace que el router rutee el tráfico destinado a la red 10.1.2.0/24 a la interfaz FastEthernet0/1 y envíe una solicitud ARP para la dirección IP de destino en el paquete IP. Se supone que algún dispositivo responderá a la solicitud ARP y el router luego reenvía el paquete a la dirección MAC que se resolvió debido al proceso ARP. Las ventajas de este tipo de configuración es que es muy fácil de configurar y administrar. El administrador no tiene que configurar explícitamente una dirección IP de siguiente salto para la ruta, y asume que un dispositivo adyacente tendrá proxy-ARP habilitado y responderá a la solicitud ARP si es capaz de rutear los paquetes a la dirección IP de destino.

Sin embargo, hay serios problemas con este tipo de configuración de ruta IP:

• Al enviar una solicitud ARP para determinar el salto siguiente para el tráfico IP, el router está expuesto a problemas causados por otros dispositivos que podrían responder incorrectamente a esa solicitud ARP. El resultado es que el tráfico puede estar en espera negra cuando se envía a un dispositivo incorrecto.

• La ruta hará que el dispositivo envíe una solicitud ARP para cada dirección de destino única en los paquetes que coincidan con la ruta. Esto puede causar una gran cantidad de tráfico ARP en la subred y afectar negativamente el rendimiento, así como el espacio de memoria necesario para mantener una cantidad potencialmente grande de entradas ARP.

• Debido a que el espacio de la tabla ARP es un recurso enlazado a la memoria, un número excesivo de entradas puede afectar negativamente el rendimiento y la estabilidad del router.

Por lo tanto, la mejor práctica es configurar todas las rutas con direcciones IP next hop explícitas y no utilizar rutas que tengan un nombre de interfaz por sí mismas para identificar la interfaz saliente. Si la interfaz es necesaria para vincular la ruta a la interfaz de egreso para la conmutación por fallas, ingrese el nombre de la interfaz de egreso y el siguiente salto en la ruta estática.

Dadas las implicaciones administrativas para algunos clientes de Cisco, se ha abierto una solicitud de mejora para que el nuevo comportamiento seguro sea configurable: Id. de error de Cisco CSCty95468 (sólo clientes registrados) (ENH: Agregar comando para permitir entradas de caché ARP de subredes no conectadas).

Enmascaradas de subred IP no coincidentes en dispositivos adyacentes

Las máscaras de subred IP no coincidentes configuradas en la interfaz del ASA y la interfaz del dispositivo adyacente pueden causar una situación similar. Si el dispositivo adyacente tenía una máscara de subred que era una superred (255.255.240.0) de la máscara de subred IP de la interfaz de ASA (255.255.255.0), el dispositivo adyacente buscará ARP para las direcciones IP que no se encuentren en la subred IP de la interfaz de ASA. Asegúrese de que las máscaras de subred sean correctas.

Implicaciones del modo transparente

Otro efecto secundario de este cambio es la incapacidad de aprender las direcciones MAC de las subredes no conectadas directamente en el modo Transparente. Esto afecta a la comunicación en estos escenarios:

• El ASA transparente no tiene configurada una dirección IP de administración o la configuración es incorrecta.

• El ASA transparente está utilizando subredes secundarias en el mismo segmento.

No hay otra solución para este problema en el modo Transparente que no sea la actualización. Sin embargo, esta solicitud de mejora se ha abierto para hacer que ASA interopere con subredes secundarias en el modo Transparente: Id. de error de Cisco CSCty49855 (sólo clientes registrados) (ENH: Admita Hosts No Conectados Directamente en el Mecanismo de detección de MAC).

Resolución

La solución a este problema (en el caso de que la dirección IP en cuestión no se encuentre en la misma subred de capa 3 que la IP de interfaz de ASA) es realizar los cambios necesarios para garantizar que los dispositivos adyacentes al tráfico de ruta de ASA se dirijan directamente a la dirección IP de interfaz de ASA como dispositivo de salto siguiente, en lugar de confiar en un dispositivo para proxy-ARP en nombre de la dirección IP.

Información Relacionada

• Soporte Técnico y Documentación - Cisco Systems

Historial de revisiones