NAT de identidad en ASA frente a la exclusión de NAT en IOS para el tráfico VPN

Una sucursal mantiene PAT de internet y una VPN de sitio a sitio en la misma pasarela Cisco, y la VPN deja de funcionar en el momento en que se añade NAT. Las direcciones dentro del túnel ya no coinciden con lo que protege la crypto ACL, o el par ve direcciones traducidas para las que no tiene ruta. Cisco lo resuelve en dos lugares: el ASA selecciona una regla NAT que asigna una dirección a sí misma, mientras que IOS mantiene el flujo fuera de una regla de traducción mediante un deny en la ACL. Ambos conservan las direcciones originales y ninguno es una elusión del procesamiento de NAT.

Registre el flujo antes de elegir una regla

Empiece escribiendo el flujo que espera proteger: el origen de la LAN, el destino remoto y el par exacto de direcciones que protege la política IPsec. Hágalo antes de editar una regla, porque la tupla indica qué clasificador o regla NAT debería haber coincidido.

Después busque la regla que realmente coincidió, no la que pretendía. En ambas plataformas el NAT se evalúa en un orden, y una regla anterior puede ganar antes de que se consulte su excepción. Una excepción que parece correcta pero pierde frente a otra regla nunca entrega el paquete esperado a la política de protección. El síntoma es idéntico al de una excepción ausente, por eso hay que leer el orden de las reglas antes de cambiar la configuración.

El NAT de identidad en ASA es una regla, no una elusión

En el ASA, el NAT de identidad es una regla NAT cuya dirección traducida es igual a la original. Se selecciona como cualquier otra regla y sigue instalando una entrada de traducción, así que el paquete no se salta el procesamiento de NAT. Lo que cambia es que las direcciones en el cable siguen siendo las mismas, y eso es lo que necesita la política IPsec.

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

Las interfaces de la regla y su ajuste route-lookup deben coincidir con el diseño de reenvío. Una regla que asigna la dirección correctamente pero se aplica al par de interfaces equivocado no se seleccionará para su flujo. Route-lookup decide si el paquete traducido se enruta o se usa el destino original, y eso determina si el tráfico de retorno vuelve por el túnel.

El acceso de gestión al propio ASA es un caso aparte. Si usa NAT de identidad para el tráfico de gestión, se aplica el requisito de route-lookup específico de la versión, y una excepción amplia copiada de un ejemplo de VPN no arreglará SSH.

Un deny en la ACL NAT de IOS significa no seleccionado aquí

En IOS, el NAT de internet se rige por una lista de origen, y esa ACL es un clasificador, no un filtro. Una línea permit selecciona tráfico para la traducción; una línea deny significa que el paquete no se selecciona aquí. Ese deny no es una orden de descartar el paquete como lo es un deny en una ACL de interfaz.

No seleccionado aquí también es más estrecho que nunca traducido en ningún sitio. Otra regla NAT, otra interfaz o un route-map aún pueden traducir el flujo, así que hay que leer toda la tabla NAT. El paquete también necesita una ruta, una crypto ACL que coincida y permiso en los límites reales de control de acceso.

Una disposición mínima en IOS coloca el deny por encima del permit en la misma lista y apunta la regla overload a esa lista. Entonces la crypto ACL protege el mismo par que el deny excluye de la traducción.

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

Una pregunta comprobable para ambos modelos

Ambos modelos responden a la misma pregunta: qué regla coincidió con este flujo y qué direcciones salieron de la interfaz. Capture en la interfaz externa y compare la dirección de origen antes y después de la pasarela. Luego revise la visión del par sobre el túnel, porque la SA puede estar levantada mientras el flujo protegido se traduce en otro lugar.

En el ASA muestre nat detail y la tabla de traducción; en IOS muestre ip nat translations y los contadores de la ACL correspondiente. Una regla que nunca incrementa nunca fue seleccionada, y eso apunta al orden, la interfaz o la dirección más que a la configuración de crypto.

Dónde suele fallar la configuración

Los fallos habituales son mecánicos. El deny está debajo del permit y nunca coincide. El clasificador se aplica en la dirección equivocada, así que se traduce el flujo de retorno. La regla de identidad cubre las direcciones correctas pero el par de interfaces equivocado. La crypto ACL protege una subred que ya no coincide con lo que presenta la regla NAT.

Registre el par de direcciones original y presentado junto al propietario de la regla, para que el siguiente ingeniero vea por qué un clasificador deniega la traducción mientras el firewall permite la aplicación. Guárdelo en el ticket de cambio, no en una nota personal. Después vuelva a ejecutar el flujo tras cualquier cambio de NAT, porque el orden de las reglas forma parte de la configuración aunque el texto de la regla no cambie. Un túnel que sube no demuestra que las direcciones sobrevivieran; solo lo hacen el paquete capturado y la visión desencapsulada del par.