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

Resolución de los problemas más comunes con VPN IPSec L2L y de acceso remoto

23 Marzo 2008 - Traducción manual
Otras Versiones: PDFpdf | Traducción Automática (31 Julio 2013) | Inglés (28 Abril 2009) | Comentarios

Contenido

Introducción
Requisitos previos
      Requerimientos
      Componentes utilizados
      Convenciones
Problema: una configuración de VPN IPSec no funciona
Soluciones
      Activación de NAT-Traversal (problema VPN RA nº 1)
      Prueba de conectividad correcta
      Activación de ISAKMP
      Borrado de las asociaciones de seguridad (túneles) antiguas o existentes
      Activación de señales de mantenimiento de ISAKMP
      Reintroducción de claves previamente compartidas
      Eliminación y reemplazo de mapas de cifrados
      Verificación de la presencia de comandos sysopt (sólo PIX/ASA)
      Verificación de que las ACL son correctas
      Verificación de que el enrutamiento es correcto
      Verificación de números de secuencia del mapa de cifrado
      Desactivación de XAUTH para pares L2L
Problema: los usuarios de acceso remoto se conectan a la VPN y no tienen acceso a otros recursos
Soluciones
      Túnel dividido
      Devolución de llamadas
      Acceso LAN local
Discusiones relacionadas de la comunidad de soporte de Cisco

Introducción

Este documento contiene las soluciones más comunes para los problemas de VPN IPSec. Estas soluciones provienen directamente de las solicitudes de servicio que el Sitio de Soporte de Cisco ha resuelto. Muchas de estas soluciones pueden implementarse antes de profundizar en la resolución de problemas relacionados con una conexión VPN IPSec. Por tanto, este documento se ha diseñado como una lista de control de los procedimientos más comunes que se deben llevar a cabo antes de intentar resolver el problema o ponerse en contacto con el Sitio de Soporte de Cisco.

Nota: A pesar de que los ejemplos de configuración de este documento se han diseñado para routers y dispositivos de seguridad, casi todos los conceptos aquí contenidos pueden aplicarse a un concentrador VPN 3000.

Nota: Puede buscar cualquier comando que contenga este documento mediante la herramienta Command Lookup Tool (sólo para clientes registrados).

Advertencia Advertencia: Muchas de las soluciones contenidas en este documento pueden causar una pérdida temporal de conectividad VPN IPSec en un dispositivo. Se recomienda implementar estas soluciones con sumo cuidado y siguiendo las políticas de control de cambios pertinentes.

Requisitos previos

Requerimientos

Cisco recomienda poseer ciertos conocimientos acerca de estos temas:

  • Configuración de VPN IPSec en dispositivos de Cisco:

    • Dispositivo de seguridad de la serie PIX 500 de Cisco

    • Dispositivo de seguridad de la serie ASA 5500 de Cisco

    • Routers de Cisco IOS®

    • Concentradores de la serie VPN 3000 de Cisco (opcional)

Componentes utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware:

  • Dispositivo de seguridad de la serie ASA 5500 de Cisco

  • Dispositivo de seguridad de la serie PIX 500 de Cisco

  • Cisco IOS

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

Convenciones

Consulte Convenciones sobre consejos técnicos de Cisco para obtener más información sobre las convenciones del documento.

Problema: una configuración de VPN IPSec no funciona

Una solución de VPN IPSec recientemente configurada o modificada no funciona.

Una configuración actual de VPN IPSec no funciona.

Soluciones

Esta sección contiene soluciones a los problemas de VPN IPSec más comunes. Aunque no están enumeradas siguiendo un orden en particular, estas soluciones pueden servir como una lista de control de elementos que se deben verificar o probar antes de pasar a una resolución de problemas más exhaustiva o ponerse en contacto con el Sitio de Soporte de Cisco. Todas estas soluciones provienen directamente de solicitudes de servicio del Sitio de Soporte de Cisco y han resuelto numerosos problemas de los clientes.

Nota: Algunos de los comandos de estas secciones se han separado en dos líneas debido a problemas de espacio.

Activación de NAT-Traversal (problema VPN RA nº 1)

NAT-Traversal o NAT-T permite que el tráfico VPN pase a través de los dispositivos NAT o PAT, como un router Linksys SOHO. Si NAT-T no está activada, a menudo parece que los usuarios del cliente VPN pueden conectarse a PIX o ASA sin problemas, pero no pueden acceder a la red interna detrás del dispositivo de seguridad.

Nota: Con IOS 12.2(13)T y versiones posteriores, NAT-T está activada de forma predeterminada en IOS.

Éste es el comando para activar NAT-T en un dispositivo de seguridad de Cisco. En este ejemplo, 20 es el tiempo de señal de mantenimiento (predeterminado).

  • PIX/ASA 7.1 y versiones anteriores

    pix(config)# isakmp nat-traversal 20
    
  • PIX/ASA 7.2(1) y versiones posteriores

    securityappliance(config)# crypto isakmp nat-traversal 20
    

Nota: Este comando es el mismo para PIX 6.x y PIX/ASA 7.x.

Prueba de conectividad correcta

Lo adecuado es que la conectividad VPN se pruebe desde dispositivos ubicados detrás de los dispositivos de puntos finales que realizan el cifrado. A pesar de ello, muchos usuarios prueban de conectividad VPN mediante el comando ping en los dispositivos que realizan el cifrado. Aunque el comando ping normalmente funciona para este propósito, es importante que se origine desde la interfaz correcta. Si el ping no se origina correctamente, puede parecer que la conexión VPN falla cuando en realidad funciona. Tome este escenario como ejemplo:

common_ipsec_trouble-1.gif

ACL de cifrado en router A

access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255

ACL de cifrado en router B

access-list 110 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255

En esta situación, se debe originar un ping desde la red "interna" detrás de cualquiera de los routers. Esto se debe a que las ACL de cifrado sólo están configuradas para cifrar tráfico con esas direcciones de origen. Un ping originado desde las interfaces orientadas a Internet de cualquiera de los routers no se cifrará. Utilice las opciones extendidas del comando ping del modo EXEC con privilegios para originar un ping desde la interfaz "interna" de un router:

routerA# ping
Protocol [ip]:
Target IP address: 192.168.200.10
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.100.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.200.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.100.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Imagine que los routers de este diagrama se han reemplazado con dispositivos de seguridad PIX o ASA. El ping que se utiliza para probar la conectividad también se puede originar desde la interfaz interna con la palabra clave inside:

securityappliance# ping inside 192.168.200.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.200.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Nota: No se recomienda dirigir la interfaz interna de un dispositivo de seguridad mediante ping. Si debe dirigir una interfaz interna mediante ping, deberá activar management-access en dicha interfaz o el dispositivo no responderá.

securityappliance(config)# management-access inside

Activación de ISAKMP

Si no existen indicaciones de ninguna activación en un túnel de VPN IPSec, puede deberse a que ISAKMP no está activado. Asegúrese de activar ISAKMP en los dispositivos. Utilice uno de estos comandos para activar ISAKMP en los dispositivos:

  • Cisco IOS

    router(config)#crypto isakmp enable
    
  • Cisco PIX 7.1 y versiones anteriores (reemplace outside con la interfaz deseada)

    pix(config)# isakmp enable outside
    
  • Cisco PIX/ASA 7.2(1) y versiones posteriores (reemplace outside con la interfaz deseada)

    securityappliance(config)# crypto isakmp enable outside
    

Borrado de las asociaciones de seguridad (túneles) antiguas o existentes

Borrar las asociaciones de seguridad (SA) ISKAMP (fase I) y IPSec (fase II) es la forma más simple, y a menudo la mejor, de resolver problemas de VPN IPSec. Si borra las SA, puede resolver una gran variedad de mensajes de error y comportamientos extraños sin necesidad de acudir a la resolución de problemas. A pesar de que esta técnica se puede emplear fácilmente en cualquier situación, casi siempre es necesario borrar las SA una vez modificadas o agregadas a una configuración VPN IPSec actual. Además, aunque es posible borrar sólo determinadas asociaciones de seguridad, lo más recomendable es borrar todas las AS del dispositivo.

Nota: Una vez que se han borrado las asociaciones de seguridad, puede que sea necesario enviar tráfico a través del túnel para poder reestablecerlas.

Advertencia Advertencia: A menos que especifique qué asociaciones de seguridad desea borrar, los comandos a continuación pueden borrar todas las asociaciones de seguridad del dispositivo. Actúe con precaución si hay algún otro túnel de VPN IPSec en uso.

  1. Revise las asociaciones de seguridad antes de borrarlas.

    1. Cisco IOS

      router#show crypto isakmp sa
      router#show crypto ipsec sa
      
    2. Dispositivos de seguridad Cisco PIX/ASA

      securityappliance# show crypto isakmp sa
      securityappliance# show crypto ipsec sa
      

      Nota: Estos comandos son los mismos para Cisco PIX 6.x y PIX/ASA 7.x

  2. Borre las asociaciones de seguridad. Cada uno de los comandos se puede introducir como se indica en negrita o con las opciones que se muestran con ellos.

    1. Cisco IOS

      1. ISAKMP (fase I)

        router#clear crypto isakmp ?
          <0 - 32766>  connection id of SA
          <cr>
      2. IPSec (fase II)

        router#clear crypto sa ?
          counters  Reset the SA counters
          map       Clear all SAs for a given crypto map
          peer      Clear all SAs for a given crypto peer
          spi       Clear SA by SPI
          <cr>
        
    2. Dispositivos de seguridad Cisco PIX/ASA

      1. ISAKMP (fase I)

        securityappliance# clear crypto isakmp sa
        
      2. IPSec (fase II)

        security appliance# clear crypto ipsec sa ?
        
          counters  Clear IPsec SA counters
          entry     Clear IPsec SAs by entry
          map       Clear IPsec SAs by map
          peer      Clear IPsec SA by peer
          <cr>
        

Activación de señales de mantenimiento de ISAKMP

La configuración de señales de mantenimiento de ISAKMP contribuye a evitar interrupciones esporádicas de túneles de VPN LAN a LAN, así como la interrupción de túneles LAN a LAN tras un período de inactividad. Esta característica permite que el punto extremo del túnel supervise la presencia continua de un par remoto e informe de su propia presencia a dicho par. Si el par deja de responder, el punto extremo elimina la conexión. Ambos puntos extremos de VPN deben admitir las señales de mantenimiento de ISAKMP para que éstas funcionen.

  • Configure las señales de mantenimiento de ISAKMP en ISO mediante el siguiente comando:

    router(config)# crypto isakmp keepalive 15
    
  • Utilice estos comandos para configurar las señales de mantenimiento de ISAKMP en los dispositivos de seguridad de PIX/ASA:

    • Cisco PIX 6.x

      pix(config)# isakmp keepalive 15
      
    • Cisco PIX/ASA 7.x, para el grupo de túneles designado 10.165.205.222

      securityappliance(config)# tunnel-group 10.165.205.222
         ipsec-attributes
      
      securityappliance(config-tunnel-ipsec)# isakmp keepalive
         threshold 15 retry 10
      
      

Reintroducción de claves previamente compartidas

En muchos casos, un simple error tipográfico puede ser la causa de que un túnel de VPN IPSec no se active. Por ejemplo, en el dispositivo de seguridad, las claves previamente compartidas se ocultan una vez que se han introducido. Esta confusión hace imposible comprobar si la clave es incorrecta. Asegúrese de que ha introducido correctamente todas las claves previamente compartidas en cada punto extremo de VPN. Vuelva a introducir una clave para asegurarse de que es correcta; ésta es una solución sencilla que puede evitar pasar a una resolución de problemas más exhaustiva.

Advertencia Advertencia: Si elimina comandos relacionados con el cifrado, es probable que desactive uno o todos los túneles de VPN. Utilice estos comandos con precaución y consulte la política de control de cambios de su organización antes de seguir con estos pasos.

  • Utilice estos comandos para eliminar e introducir de nuevo la clave previamente compartida secretkey para el par 10.0.0.1 o el grupo vpngroup en IOS:

    • VPN LAN a LAN de Cisco

      router(config)# no crypto isakmp key secretkey
         address 10.0.0.1
      router(config)# crypto isakmp key secretkey
         address 10.0.0.1
      
    • VPN de acceso remoto de Cisco

      router(config)# crypto isakmp client configuration
         group vpngroup
      router(config-isakmp-group)# no key secretkey
      router(config-isakmp-group)# key secretkey
      
  • Utilice estos comandos para eliminar e introducir de nuevo la clave previamente compartida secretkey para el par 10.0.0.1 en los dispositivos de seguridad PIX/ASA:

    • Cisco PIX 6.x

      pix(config)# no isakmp key secretkey address 10.0.0.1
      pix(config)# isakmp key secretkey address 10.0.0.1
      
    • Cisco PIX/ASA 7.x

      securityappliance(config)# tunnel-group 10.0.0.1
         ipsec-attributes
      securityappliance(config-tunnel-ipsec)# no pre-shared-key
      securityappliance(config-tunnel-ipsec)# pre-shared-key
         secretkey
      

Eliminación y reemplazo de mapas de cifrados

Si borra asociaciones de seguridad, pero no se resuelve un problema de VPN IPSec, elimine y reemplace el mapa de cifrado pertinente para resolver una amplia variedad de problemas.

Advertencia Advertencia: Si elimina un mapa de cifrado de una interfaz, se desactivan de manera definitiva todos los túneles IPSec asociados a dicho mapa de cifrado. Siga estos pasos con precaución y tenga en cuenta la política de control de cambios de su organización antes de proceder.

  • Utilice estos comandos para eliminar y reemplazar un mapa de cifrado en IOS:

    Comience con la eliminación del mapa de cifrado de la interfaz. Utilice la forma no del comando crypto map.

    router(config-if)# no crypto map mymap
    

    Continúe utilizando la forma no para eliminar un mapa de cifrado completo.

    router(config)# no crypto map mymap 10
    
    

    Reemplace el mapa de cifrado en la interfaz Ethernet0/0 para el par 10.0.0.1. Este ejemplo muestra la configuración mínima necesaria para un mapa de cifrado:

    router(config)# crypto map mymap 10 ipsec-isakmp
    router(config-crypto-map)# match address 101
    router(config-crypto-map)# set transform-set mySET
    router(config-crypto-map)# set peer 10.0.0.1
    router(config-crypto-map)# exit
    router(config)# interface ethernet0/0
    router(config-if)# crypto map mymap
    
  • Utilice estos comandos para eliminar y reemplazar un mapa de cifrado en PIX o ASA:

    Comience con la eliminación del mapa de cifrado de la interfaz. Utilice la forma no del comando crypto map.

    securityappliance(config)# no crypto map mymap interface outside
    

    Continúe utilizando la forma no para eliminar los comandos del otro mapa de cifrado.

    securityappliance(config)# no crypto map mymap 10 match
       address 101
    securityappliance(config)# no crypto map mymap set
       transform-set mySET
    securityappliance(config)# no crypto map mymap set
       peer 10.0.0.1
    
    

    Reemplace el mapa de cifrado para el par 10.0.0.1. Este ejemplo muestra la configuración mínima necesaria para un mapa de cifrado:

    securityappliance(config)# crypto map mymap 10 ipsec-isakmp
    securityappliance(config)# crypto map mymap 10
       match address 101
    securityappliance(config)# crypto map mymap 10 set
       transform-set mySET
    securityappliance(config)# crypto map mymap 10 set
       peer 10.0.0.1
    securityappliance(config)# crypto map mymap interface outside
    

Verificación de la presencia de comandos sysopt (sólo PIX/ASA)

Los comandos sysopt connection permit-ipsec y sysopt connection permit-vpn permiten que los paquetes del túnel IPSec y sus cargas útiles eludan las ACL de la interfaz del dispositivo de seguridad. Los túneles IPSec que finalizan en el dispositivo de seguridad pueden fallar si uno de estos comandos no está activado.

En las versiones 7.0 y anteriores del software del dispositivo de seguridad, el comando sysopt pertinente para esta situación es sysopt connection permit-ipsec.

En las versiones 7.1(1) y posteriores del software del dispositivo de seguridad, el comando sysopt pertinente para esta situación es sysopt connection permit-vpn.

En PIX 6.x, esta funcionalidad está desactivada de manera predeterminada. En PIX/ASA 7.0(1) y versiones posteriores, esta funcionalidad está activada de manera predeterminada. Utilice estos comandos show para determinar si el comando sysopt pertinente está activado en el dispositivo:

  1. Cisco PIX 6.x

    pix# show sysopt
    no sysopt connection timewait
    sysopt connection tcpmss 1380
    sysopt connection tcpmss minimum 0
    no sysopt nodnsalias inbound
    no sysopt nodnsalias outbound
    no sysopt radius ignore-secret
    no sysopt uauth allow-http-cache
    no sysopt connection permit-ipsec
    
    
    !--- sysopt connection permit-ipsec is disabled
    
    no sysopt connection permit-pptp
    no sysopt connection permit-l2tp
    no sysopt ipsec pl-compatible
    
  2. Cisco PIX/ASA 7.x

    securityappliance# show running-config sysopt
    no sysopt connection timewait
    sysopt connection tcpmss 1380
    sysopt connection tcpmss minimum 0
    no sysopt nodnsalias inbound
    no sysopt nodnsalias outbound
    no sysopt radius ignore-secret
    sysopt connection permit-vpn
    
    
    !--- sysopt connection permit-vpn is enabled
    !--- This device is running 7.2(2)
    
    

Utilice estos comandos para activar el comando sysopt correcto para el dispositivo:

  • Cisco PIX 6.x y PIX/ASA 7.0

    pix(config)# sysopt connection permit-ipsec
    
  • Cisco PIX/ASA 7.1(1) y posteriores

    securityappliance(config)# sysopt connection permit-vpn
    

Verificación de que las ACL son correctas

En una configuración VPN IPSec típica se utilizan dos listas de acceso. Una de las listas de acceso sirve para liberar tráfico destinado al túnel de VPN desde el proceso NAT. La otra lista de acceso define qué tráfico se debe cifrar; esto incluye una ACL de cifrado en una configuración LAN a LAN o una ACL de tunelización dividida (split-tunneling) en una configuración de acceso remoto. Cuando estas ACL no están o se encuentran configuradas incorrectamente, el tráfico no se enviará al túnel de VPN o fluirá sólo en una única dirección a través de éste.

Asegúrese de que ha configurado todas las listas de acceso necesarias para completar la configuración de VPN IPSec y que dichas listas de acceso definen el tráfico correcto. Esta lista contiene elementos simples que debe comprobar si sospecha que una ACL es la causa de los problemas que está experimentando con VPN IPSec.

  • Asegúrese de que la exención de NAT y las ACL de cifrado especifican el tráfico correcto.

  • Si tiene varios túneles de VPN y varias ACL de cifrado, asegúrese de que dichas ACL no se superponen.

  • No reutilice las ACL. Aunque la ACL de exención de NAT y la ACL de cifrado especifiquen el mismo tráfico, utilice dos listas de acceso diferentes.

  • Asegúrese de que el dispositivo está configurado para utilizar la ACL de exención de NAT. En un router, esto significa que debe utilizar el comando route-map. En PIX o ASA, esto significa que debe utilizar el comando nat (0). Se necesita una ACL de exención de NAT para configuraciones LAN a LAN y de acceso remoto.

    • En el siguiente ejemplo, se configura un router IOS para liberar tráfico que se envía entre 192.168.100.0 /24 y 192.168.200.0 /24 o 192.168.1.0 /24 desde NAT. El tráfico destinado a cualquier otro sitio depende de la sobrecarga de NAT:

      access-list 110 deny ip 192.168.100.0 0.0.0.255
         192.168.200.0 0.0.0.255
      access-list 110 deny ip 192.168.100.0 0.0.0.255
         192.168.1.0 0.0.0.255
      access-list 110 permit ip 192.168.100.0 0.0.0.255 any
      
      route-map nonat permit 10
        match ip address 110
      
      ip nat inside source route-map nonat interface FastEthernet0/0 overload
    • En este ejemplo, se configura un PIX para liberar tráfico que se envía entre 192.168.100.0 /24 y 192.168.200.0 /24 o 192.168.1.0 /24 desde NAT. El resto de tráfico depende de la sobrecarga de NAT:

      access-list noNAT extended permit ip 192.168.100.0
         255.255.255.0 192.168.200.0 255.255.255.0
      access-list noNAT extended permit ip 192.168.100.0
         255.255.255.0 192.168.1.0 255.255.255.0
      
      nat (inside) 0 access-list noNAT
      nat (inside) 1 0.0.0.0 0.0.0.0
      
      global (outside) 1 interface
  • Asegúrese de que las ACL no están configuradas en sentido inverso y que son el tipo correcto.

    • Las ACL de exención NAT y de cifrado para configuraciones LAN a LAN se deben escribir desde la perspectiva del dispositivo en el que se configura la ACL. Esto significa que las ACL deben reflejarse unas a otras. En este ejemplo, se configura un túnel LAN a LAN entre 192.168.100.0 /24 y 192.168.200.0 /24.

      common_ipsec_trouble-1.gif

      ACL de cifrado en router A

      access-list 110 permit ip 192.168.100.0 0.0.0.255
         192.168.200.0 0.0.0.255

      ACL de cifrado en router B

      access-list 110 permit ip 192.168.200.0 0.0.0.255
         192.168.100.0 0.0.0.255

      Nota: Aunque no se ilustra en el presente documento, también se puede aplicar el mismo concepto a los dispositivos de seguridad PIX y ASA.

    • Las ACL de túnel divido para configuraciones de acceso remoto deben ser listas de acceso estándar que permitan tráfico hacia la red a la que los clientes VPN necesitan acceso.

      common_ipsec_trouble-2.gif

      • Cisco IOS

        router(config)# access-list 10 permit ip 192.168.100.0
        router(config)#crypto isakmp client configuration group MYGROUP
        router(config-isakmp-group)#acl 10
        
      • Cisco PIX 6.x

        pix(config)# access-list 10 permit 192.168.100.0
           255.255.255.0
        pix(config)# vpngroup MYGROUP split-tunnel 10
      • Cisco PIX/ASA 7.x

        securityappliance(config)# access-list 10 standard
           permit 192.168.100.0 255.255.255.0
        securityappliance(config)# group-policy MYPOLICY internal
        securityappliance(config)# group-policy MYPOLICY attributes
        securityappliance(config-group-policy)# split-tunnel-policy
           tunnelspecified
        securityappliance(config-group-policy)# split-tunnel-network-list
           value 10
        

Verificación de que el enrutamiento es correcto

El enrutamiento es una parte crítica de casi todas las implementaciones de VPN IPSec. Asegúrese de que todos los dispositivos de cifrado, como routers y dispositivos de seguridad PIX o ASA, cuentan con la información de enrutamiento necesaria para enviar tráfico a través del túnel de VPN. Asimismo, si existen otros routers detrás del dispositivo de puerta de enlace, asegúrese de que dichos routers saben cómo llegar al túnel y qué redes se encuentran en el otro lado.

En una implementación VPN, uno de los componentes clave del enrutamiento es la inyección de ruta inversa (RRI). La RRI coloca entradas dinámicas para redes remotas o clientes VPN en la tabla de enrutamiento de una puerta de enlace VPN. Estos routers son útiles para el dispositivo en los que se encuentran instalados, así como para otros dispositivos en la red, porque las rutas instaladas por RRI se pueden redistribuir a través de un protocolo de enrutamiento como EIGRP u OSPF.

  • En una configuración LAN a LAN es importante que cada punto extremo tenga una ruta o rutas hacia las redes para las que se supone que se cifra el tráfico. En este ejemplo, el router A debe tener rutas hacia las redes detrás del router B a través de 10.89.129.2. El router B debe tener una ruta similar a 192.168.100.0 /24:

    common_ipsec_trouble-3.gif

    • La primera manera de comprobar que cada router conoce las rutas apropiadas consiste en configurar rutas estáticas para cada red de destino. Por ejemplo, el router A puede tener configuradas las siguientes declaraciones de ruta:

      ip route 0.0.0.0 0.0.0.0 172.22.1.1
      ip route 192.168.200.0 255.255.255.0 10.89.129.2
      ip route 192.168.210.0 255.255.255.0 10.89.129.2
      ip route 192.168.220.0 255.255.255.0 10.89.129.2
      ip route 192.168.230.0 255.255.255.0 10.89.129.2

      Si el router A se ha reemplazado con un PIX o ASA, la configuración puede ser así:

      route outside 0.0.0.0 0.0.0.0 172.22.1.1
      route outside 192.168.200.0 255.255.255.0 10.89.129.2
      route outside 192.168.200.0 255.255.255.0 10.89.129.2
      route outside 192.168.200.0 255.255.255.0 10.89.129.2
      route outside 192.168.200.0 255.255.255.0 10.89.129.2
    • Si existe un mayor número de redes detrás de cada punto extremo, la configuración de rutas estáticas puede llegar a ser difícil de mantener. Como alternativa, se recomienda utilizar la inyección de ruta inversa, como se indica. La RRI coloca en la tabla de enrutamiento rutas para todas las redes remotas incluidas en la ACL de cifrado. Por ejemplo, la ACL de cifrado y el mapa de cifrado del router A pueden ser así:

      access-list 110 permit ip 192.168.100.0 0.0.0.255
         192.168.200.0 0.0.0.255
      access-list 110 permit ip 192.168.100.0 0.0.0.255
         192.168.210.0 0.0.0.255
      access-list 110 permit ip 192.168.100.0 0.0.0.255
         192.168.220.0 0.0.0.255
      access-list 110 permit ip 192.168.100.0 0.0.0.255
         192.168.230.0 0.0.0.255
      
      crypto map myMAP 10 ipsec-isakmp
       set peer 10.89.129.2
       reverse-route
       set transform-set mySET
       match address 110
      

      Si el router A se ha reemplazado con un PIX o ASA, la configuración puede ser así:

      access-list cryptoACL extended permit ip 192.168.100.0
         255.255.255.0 192.168.200.0 255.255.255.0
      access-list cryptoACL extended permit ip 192.168.100.0
         255.255.255.0 192.168.210.0 255.255.255.0
      access-list cryptoACL extended permit ip 192.168.100.0
         255.255.255.0 192.168.220.0 255.255.255.0
      access-list cryptoACL extended permit ip 192.168.100.0
         255.255.255.0 192.168.230.0 255.255.255.0
      
      crypto map myMAP 10 match address cryptoACL
      crypto map myMAP 10 set peer 10.89.129.2
      crypto map myMAP 10 set transform-set mySET
      crypto map mymap 10 set reverse-route
      
  • En una configuración de acceso remoto, los cambios de ruta no son siempre necesarios. A pesar de ello, si existen otros routers detrás del router de puerta de enlace VPN o del dispositivo de seguridad, es necesario que dichos routers conozcan de alguna manera la ruta hacia los clientes VPN. En este ejemplo se supone que a los clientes VPN se les asignan direcciones en el intervalo de 10.0.0.0 /24 cuando se conectan.

    common_ipsec_trouble-4.gif

    Si no se utiliza ningún protocolo de enrutamiento entre la puerta de enlace y otros routers, se pueden utilizar rutas estáticas en routers como el router 2:

    ip route 10.0.0.0 255.255.255.0 192.168.100.1

    Si se utiliza un protocolo de enrutamiento como EIGRP u OSPF entre la puerta de enlace y otros routers, se recomienda que la inyección de ruta inversa se utilice como se describe. La RRI agrega de manera automática rutas para el cliente VPN en la tabla de enrutamiento de la puerta de enlace. Estas rutas se pueden distribuir a los demás routers de la red.

    • Router Cisco IOS:

      crypto dynamic-map dynMAP 10
       set transform-set mySET
       reverse-route
      
      crypto map myMAP 60000 ipsec-isakmp dynamic dynMAP
    • Dispositivo de seguridad Cisco PIX o ASA:

      crypto dynamic-map dynMAP 10 set transform-set mySET
      crypto dynamic-map dynMAP 10 set reverse-route
      
      crypto map myMAP 60000 ipsec-isakmp dynamic dynMAP

Verificación de números de secuencia del mapa de cifrado

Si los pares estáticos y dinámicos están configurados en el mismo mapa de cifrado, es muy importante el orden de las entradas del mapa de cifrado. El número de secuencia de la entrada del mapa de cifrado dinámica debe ser mayor que el resto de entradas del mapa de cifrado estáticas. Si estas entradas estáticas se numeran con cifras superiores a las de la entrada dinámica, las conexiones con dichos pares fallarán.

El siguiente ejemplo muestra un mapa de cifrado correctamente numerado que contiene una entrada estática y una dinámica. Observe que la entrada dinámica presenta el número de secuencia más alto y que se ha dejado espacio para agregar otras entradas estáticas adicionales:

crypto dynamic-map cisco 20 set transform-set myset
crypto map mymap 10 match address 100
crypto map mymap 10 set peer 172.16.77.10
crypto map mymap 10 set transform-set myset
crypto map mymap 60000 ipsec-isakmp dynamic cisco

Desactivación de XAUTH para pares L2L

Si un túnel LAN a LAN y un túnel de VPN de acceso remoto se configuran en el mismo mapa de cifrado, se solicitará información XAUTH al par LAN a LAN y el túnel LAN a LAN fallará.

Nota: Este problema sólo se aplica a Cisco IOS y PIX 6.x. Este problema no afecta a PIX/ASA 7.x, puesto que utiliza grupos de túneles.

Utilice la palabra clave no-xauth cuando introduzca la clave isakmp, de forma que el dispositivo no solicite al par información XAUTH (nombre de usuario y contraseña). Esta palabra clave desactiva XAUTH para los pares IPSec estáticos. Introduzca un comando similar a éste en el dispositivo que tenga VPN L2L y RA configurados en el mismo mapa de cifrado.

router(config)# crypto isakmp key cisco123 address
   172.22.1.164 no-xauth

Problema: los usuarios de acceso remoto se conectan a la VPN y no tienen acceso a otros recursos

Los usuarios de acceso remoto no tienen conectividad con Internet una vez que se han conectado a la VPN.

Los usuarios de acceso remoto no pueden acceder a los recursos ubicados detrás de otras VPN en el mismo dispositivo.

Los usuarios de acceso remoto sólo pueden tener acceso a la red local.

Soluciones

Túnel dividido

La tunelización dividida (split-tunneling) permite a los usuarios IPSec de acceso remoto dirigir condicionalmente paquetes a través del túnel IPSec de forma cifrada, o bien dirigir paquetes no cifrados a una interfaz de red en donde se enrutan a un destino final. La tunelización dividida (split-tunneling) está desactivada de forma predeterminada, con lo que se cuenta con el tráfico de toda la tunelización.

split-tunnel-policy {tunnelall | tunnelspecified | excludespecified}

Para obtener ejemplos detallados acerca de la configuración de la tunelización dividida (split-tunneling), consulte:

Devolución de llamadas

Esta característica se utiliza para el tráfico VPN que entra en una interfaz pero, a continuación, se enruta fuera de la misma. Por ejemplo, si tiene una red VPN radial (hub and spoke), donde el dispositivo de seguridad es la estrella (hub) y las redes VPN remotas son los radios (spoke), para que un radio se comunique con otro, el tráfico debe dirigirse hacia el dispositivo de seguridad y, a continuación, salir hacia el otro radio.

Utilice la configuración same-security-traffic para permitir que el tráfico entre y salga de la misma interfaz.

securityappliance(config)# same-security-traffic permit intra-interface

Acceso LAN local

Los usuarios de acceso remoto se conectan a la VPN y sólo pueden conectarse a la red local.

Para obtener ejemplos de configuración más detallados, consulte PIX/ASA 7.x: acceso a LAN local para clientes VPN (en inglés).


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: 81824