Seguridad : Dispositivos de seguridad adaptable Cisco ASA de la serie 5500

El Firewall ASA tiene CPU elevada debido a un loop del tráfico cuando desconexión de los clientes VPN

19 Octubre 2013 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (9 Agosto 2013) | Comentarios

Introducción

Este documento describe un problema frecuente que ocurra cuando la desconexión de los clientes VPN de un dispositivo de seguridad adaptante de Cisco (ASA) ese se ejecuta como headend del VPN de acceso remoto. Este documento también describe la situación donde un loop del tráfico ocurre cuando desconexión de los usuarios de VPN de un Firewall ASA. Este documento no cubre cómo configurar o configurar el Acceso Remoto al VPN, sólo la situación específica que se presenta de ciertas configuraciones de ruteo comunes.

Contribuido por Magnus Mortensen, ingeniero de Cisco TAC.

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

  • Configuración del VPN de acceso remoto en el dispositivo de seguridad adaptante
  • Conceptos de ruteo de la capa básica 3

Componentes Utilizados

La información en este documento se basa en un modelo adaptante 5520 del dispositivo de seguridad que funcione con la versión del código ASA 9.1(1).

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Productos Relacionados

Este documento se puede utilizar con estas versiones de software y hardware:

  • Cualquier modelo adaptante del dispositivo de seguridad
  • Cualquier versión del código ASA

Antecedentes

Cuando un usuario conecta con el ASA como concentrador del VPN de acceso remoto, el ASA instala una ruta basada en el host en la tabla de ruteo ASA que rutea el tráfico a ese cliente VPN hacia fuera la interfaz exterior (hacia Internet). Cuando las desconexiones de ese usuario, la ruta se quitan de la tabla, y los paquetes en la red interna (destinada a ese usuario de VPN disconnected) pudo ser colocado entre el ASA y un dispositivo de ruteo interno.

Otro problema es que los paquetes de broadcast dirigidos (de la red) (generados por el retiro de los clientes VPN) se pudieron remitir por el ASA como trama de unidifusión hacia la red interna. Esto pudo remitirlo de nuevo al ASA, que hace el paquete ser colocado hasta que expire el Time to Live (TTL).

Este documento explica estos problemas y muestra qué técnicas de configuración se pueden utilizar para prevenir el problema.

Problema: Paquetes destinados para un loop disconnected del cliente VPN dentro de la red interna

Cuando todavía las desconexiones de un usuario del VPN de acceso remoto de un Firewall ASA, los paquetes presentes en la red interna (destinada para esos usuarios disconnected) y IP asignada el direccionamiento VPN pudieron colocarse dentro de la red interna. Estos Packet Loop pudieron hacer el CPU en el ASA aumentar hasta las paradas de loop o debido al valor IP TTL en la encabezado de paquete IP decrementing a 0, o el usuario vuelve a conectar y el IP se reasigna a un cliente VPN.

Para entender este escenario mejor, considere esta topología:

En este ejemplo, han asignado el cliente de acceso remoto la dirección IP de 10.255.0.100. El ASA en este ejemplo está conectado con el mismo segmento de la red interna junto con un router. El router tiene dos capas adicionales tres segmentos de red conectados con ella. La interfaz pertinente (encaminamiento) y las configuraciones VPN del ASA y del router son:

Los resaltados de la configuración ASA se muestran en este ejemplo:

interface GigabitEthernet0/0
nameif outside
security-level 0
ip address 198.51.100.100 255.255.255.0
!
interface GigabitEthernet0/1
nameif inside
security-level 100
ip address 10.1.0.1 255.255.255.0
!
same-security-traffic permit intra-interface
!
ip local pool VPNpool 10.255.0.1-10.255.0.255
!
route outside 0.0.0.0 0.0.0.0 198.51.100.1
route inside 10.0.0.0 255.0.0.0 10.1.0.2

Los resaltados de la configuración del router se muestran en este ejemplo:

interface FastEthernet0
description connected to the inside interface of the ASA G0/1
ip address 10.1.0.2 255.255.255.0
!
interface FastEthernet1
 description connected to network segment
 ip address 10.2.0.1 255.255.255.0
!
interface FastEthernet2
 description connected to other network segment
 ip address 10.3.0.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 10.1.0.1

La tabla de ruteo del router conectado con el interior del ASA tiene simplemente una ruta predeterminado señalada a la interfaz interior ASA de 10.1.0.1.

Mientras que el usuario está conectado vía el VPN con el ASA la tabla de ruteo ASA muestra como sigue:

ASA# show route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is 198.51.100.1 to network 0.0.0.0
S 10.255.0.100 255.255.255.255 [1/0] via 198.51.100.1, outside
S 10.0.0.0 255.0.0.0 [1/0] via 10.1.0.2, inside
C 198.51.100.0 255.255.255.0 is directly connected, outside
C 10.1.0.0 255.255.255.0 is directly connected, inside
S* 0.0.0.0 0.0.0.0 [1/0] via 198.51.100.1, outside

El problema ocurre cuando las desconexiones del usuario del VPN de acceso remoto del VPN. En este momento la ruta basada en el host se quita de la tabla de ruteo ASA. Si un host dentro de la red intenta enviar el tráfico al cliente VPN, ese tráfico es ruteado a la interfaz interior ASA por el router. Esta serie de pasos ocurre:

  1. El paquete destinado a 10.255.0.100 llega en la interfaz interior del ASA.
  2. Se realizan los controles estándar ACL.
  3. La tabla de ruteo ASA se marca para determinar la interfaz de egreso para este tráfico.
  4. El destino del paquete hace juego la ruta amplia 10.0.0.0/8 que las puntas retiran la interfaz interior hacia el router.
  5. El ASA marca para ver si se permite el tráfico de la conexión mediante pines - busca la intra-interfaz del permiso de la mismo-Seguridad y encuentra que está permitido.
  6. Una conexión se construye a y desde la interfaz interior y el paquete se devuelve al router como salto siguiente.
  7. El router recibe un paquete destinado a 10.255.0.100 en la interfaz que hace frente al ASA. El router marca su tabla de ruteo para un salto siguiente conveniente. El router encuentra que el salto siguiente sería la interfaz interior ASA y el paquete está enviado al ASA.
  8. Regrese al paso 1

Un ejemplo se muestra aquí:

Este loop ocurre hasta TTL de los decrementos de este paquete a 0. Observe que el Firewall ASA no decrement el valor de TTL por abandono cuando procesa un paquete. El router decrements TTL mientras que rutea el paquete. Esto previene el acontecimiento de este loop indefinidamente, pero este loop aumenta la carga de tráfico en el ASA y hace el CPU clavar.

Problema: Los paquetes de broadcast dirigidos (de la red) generados por los clientes VPN se colocan en una red interna

Este problema es similar al primer problema. Si un cliente VPN genera un paquete del broadcast dirigido a su IP asignada subred (10.255.0.255 en el ejemplo anterior) entonces ese paquete se pudo remitir como trama de unidifusión por el ASA al router interno. El router interno pudo entonces remitirlo de nuevo al ASA, que hace el paquete colocar hasta que expire TTL.

Esta serie de eventos ocurre:

  1. La máquina de cliente VPN genera un paquete destinado al direccionamiento 10.255.0.255 del broadcast de red y el paquete llega el ASA.
  2. El ASA trata este paquete como trama de unidifusión (debido a la tabla de ruteo) y adelante la al router interno.
  3. El router interno, que también trata el paquete como trama de unidifusión, decrements TTL del paquete y adelante del él de nuevo al ASA.
  4. Las repeticiones del proceso hasta TTL del paquete se reducen a 0.

Soluciones al problema

Hay varias soluciones potenciales a este problema. Dependiendo de la topología de red y de la situación específica, una solución pudo ser más fácil de implementar que otra.

Solución 1 - Utilice una diversa agrupación IP para los clientes VPN 

Esta solución es asignar a los usuarios de VPN remotos una dirección IP que no solape con ninguna subred de la red interna. Esto prevendría el ASA de los paquetes de la expedición destinados a esa subred VPN de nuevo al router interno si el usuario de VPN no fue conectado.

Solución 2 - Haga la tabla de ruteo ASA más específica para las rutas interno

Esta solución es asegurarse que la tabla de ruteo del ASA no tiene ninguna rutas muy amplia que solapen con la agrupación IP VPN. Para este ejemplo de red específico, quite la ruta 10.0.0.0/8 del ASA y configure Static rutas más específicas para las subredes que residen de la interfaz interior. El dependiente sobre el número de subredes y de la topología de red, esto pudo ser un gran número de Static rutas y puede ser que no sea posible. 

Solución 3 - Agregue una ruta más específica para la subred VPN se retiran la interfaz exterior

Esta solución es un poco más complicada que las otras enumeradas aquí y no se recomienda sobre las otras debido a la situación descrita en la nota en la parte inferior de esta sección. Esta solución es evitar que el ASA remita los paquetes originados IP de la subred IP VPN de nuevo al router interno agregando una ruta más específica para la subred VPN hacia fuera la interfaz exterior. Puesto que esta subred IP es reservada para los usuarios de VPN exteriores, los paquetes con una dirección IP de origen de esta subred IP VPN deben nunca llegar entrante en la interfaz interior ASA. La manera más fácil de alcanzar esto es agregar una ruta para la agrupación IP del VPN de acceso remoto hacia fuera la interfaz exterior con un IP Address de Next Hop del router del ISP por aguas arriba.

En este ejemplo de la topología de red, esa ruta parecería:

route outside 10.255.0.0 255.255.255.0 198.51.100.1

Además de esta ruta, agregue el IP verifican el trayecto inverso dentro del comando para de hacer el ASA caer cualquier paquete recibió entrante en la interfaz interior originada de la subred IP VPN, debido a la más ruta preferida que existe en la interfaz exterior:

ip verify reverse-path inside

Después de que estos comandos implemeted, la tabla de ruteo ASA parece similar al siguiente cuando el usuario está conectado:

ASA# show route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 198.51.100.1 to network 0.0.0.0

S 10.255.0.100 255.255.255.255 [1/0] via 198.51.100.1, outside
S 10.0.0.0 255.0.0.0 [1/0] via 10.1.0.2, inside
S 10.255.0.0 255.255.255.0 [1/0] via 198.51.100.1, outside
C 198.51.100.0 255.255.255.0 is directly connected, outside
C 10.1.0.0 255.255.255.0 is directly connected, inside
S* 0.0.0.0 0.0.0.0 [1/0] via 198.51.100.1, outside

Cuando el cliente VPN está conectado, la ruta basada en el host a esa dirección IP VPN está presente en la tabla y se prefiere. Cuando las desconexiones del cliente VPN, trafican originado de ese dirección IP del cliente que llegue en la interfaz interior se marca contra la tabla de ruteo, y caída debido al IP verifican el trayecto inverso dentro del comando.

Si el cliente VPN genera un broadcast de red dirigido a la subred IP VPN, ese paquete se remite al router interno, y remitido por el router de nuevo al ASA, donde estará caído debido al IP verifique el trayecto inverso dentro del comando.

Nota: Después de que se implemente esta solución, si el comando intra-interface del permiso de la mismo-Seguridad está presente en la configuración y las políticas de acceso la permiten, trafique originado de un usuario de VPN destinado a un IP Address en la agrupación IP VPN para un usuario que no esté conectado pudo ser ruteado se retire la interfaz exterior en el texto claro. Esto es una situación poco común y se puede atenuar con el uso de los VPN-filtros dentro de la política del VPN. Esta situación ocurre solamente si el comando intra-interface del permiso de la mismo-Seguridad está presente en la configuración del ASA.
Asimismo, si los host internos generan el tráfico destinados a una dirección IP en el pool VPN, y esa dirección IP no se asigna a un usuario de VPN remoto, que pudo el tráfico salida el exterior del ASA en el texto claro.


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 116170