Problema con acceso remoto, IPSEC L2L fijo y L2L dinámico trabajando juntos en ASA 5540 8.2

Tengo un problema con una combinación de acceso remoto, L2L y túneles dinámicos L2L en un ASA5540 con 8.2

Aquí hay un fragmento de la configuración relevante: -

crypto dynamic-map outside-crypto-dynamic-map 10 match address outside-crypto-dynamic-map-10
crypto dynamic-map outside-crypto-dynamic-map 10 set transform-set ESP-3DES-MD5
crypto dynamic-map outside-crypto-dynamic-map 20 set transform-set ESP-3DES-MD5
crypto map outside-crypto-map 201 match address outside-crypto-map-201
crypto map outside-crypto-map 201 set peer X.X.X.X
crypto map outside-crypto-map 201 set transform-set ESP-3DES-MD5
crypto map outside-crypto-map 202 match address outside-crypto-map-202
crypto map outside-crypto-map 202 set peer Y.Y.Y.Y
crypto map outside-crypto-map 202 set transform-set ESP-AES256-SHA
crypto map outside-crypto-map 65535 ipsec-isakmp dynamic outside-crypto-dynamic-map
crypto map outside-crypto-map interface outside

Tengo varios sitios remotos que usan IP dinámicas. Las subredes LAN para estos se encuentran en una ACL "outside-crypto-dynamic-map-10".

Estos coinciden bien en función de esta línea: -

crypto dynamic-map outside-crypto-dynamic-map 10 match address outside-crypto-dynamic-map-10

Tengo otros túneles L2L "estáticos" que funcionan bien por 201 y 202 en la configuración anterior.

Con mis usuarios de acceso remoto (Cisco VPN Client), a menos que tenga la siguiente línea, no se conectarán: -

crypto dynamic-map outside-crypto-dynamic-map 20 set transform-set ESP-3DES-MD5

Si intento agregar una declaración de "dirección de coincidencia" a esa secuencia (como a continuación), el acceso remoto deja de funcionar (donde "vpc-client-subnet" es una ACL que contiene la subred del grupo de IP utilizado para los clientes de acceso remoto) ya que no puede encontrar un local / remoto que coincida.

crypto dynamic-map outside-crypto-dynamic-map 20 match address vpc-client-subnet

El problema es que tengo una serie de puntos finales L2L (que ya no quiero conectar pero que no tengo control) que todavía están configurados (en el extremo remoto) con el PSK utilizado por los pares dinámicos L2L. He eliminado sus subredes LAN de "outside-crypto-dynamic-map-10" (ya que no quiero que se conecten más) para que ya no coincidan en el seq 10 de mapa dinámico, sin embargo, todavía pueden completar con éxito la fase 2 contra "mapa-cripto-dinámico-externo 20" y parece que este extremo solo acepta lo que el control remoto propone como local / remoto para la SA.

No estoy en condiciones de cambiar el PSK. No puedo agregar una "dirección de coincidencia" al "mapa externo-cripto-dinámico 20" ya que evitará que los clientes de acceso remoto se conecten, sin embargo, si no lo hago, entonces actúa como un todo para otros pares que de lo contrario conocemos el PSK.

Idealmente, podría agregar "dirección de coincidencia" a la secuencia 20, para que los usuarios de acceso remoto coincidan con ella, pero los pares "antiguos" de la secuencia 10 no. Alternativamente, ¿hay alguna manera de evitar que el ASA acepte la idea de pares remotos del local / remoto para el SA cuando se compara con un mapa que no tiene una declaración de "dirección de coincidencia"?

EDITAR:

La configuración del grupo de túneles relevante: -

tunnel-group DefaultL2LGroup ipsec-attributes
 pre-shared-key *****
 peer-id-validate nocheck
 isakmp keepalive threshold 30 retry 5

tunnel-group x.x.x.x type ipsec-l2l
tunnel-group x.x.x.x ipsec-attributes
 pre-shared-key *****
 isakmp keepalive threshold 30 retry 5

tunnel-group ravpn type remote-access
tunnel-group ravpn general-attributes
 address-pool ip-pool-ravpn
 authentication-server-group Edirectory
 default-group-policy ravpn
tunnel-group ravpn ipsec-attributes
 pre-shared-key *****
 isakmp keepalive threshold 30 retry 2

tunnel-group-map default-group DefaultL2LGroup

Hay varios grupos de túneles para los túneles "estáticos" (según el ejemplo xxxx anterior). Los usuarios de acceso remoto golpean el grupo de túnel "ravpn", y los dinámicos coinciden con el "DefaultL2LGroup". El PSK no es lo mismo entre estos.

Sugeriría crear un segundo grupo de túnel de acceso remoto para todos sus usuarios de acceso remoto. Comience a migrarlos, uno por uno y cuando haya terminado, puede eliminar el Grupo L2L predeterminado existente o puede cambiar el PSK.

Si encuentra algunos usuarios que no desean cambiar, puede aplicar una versión específica del Cliente VPN e informarles que está realizando una actualización de seguridad importante.

Por lo general, los usuarios de VPN remotos solo necesitan un par de líneas debajo del mapa criptográfico dinámico que les permita conectarse correctamente. Algo como esto:

mapa dinámico criptográfico DYN_CRY_MAP 65535 set transform-set ESP-AES-128-SHA

mapa criptográfico OUTSIDE_map 65535 ipsec-isakmp dynamic DYN_CRY_MAP

Esto supone que ya tiene especificado el conjunto de transformación apropiado correspondiente.

Sus subredes VPN de usuario remoto no necesitan especificarse en el mapa criptográfico ya que son puntos finales dinámicos. El ASA lo sabe y ajusta las tablas de cifrado en consecuencia. Sus puntos finales dinámicos L2L tampoco necesitan especificarse en el mapa criptográfico y funcionarán de la misma manera. Además, una "característica" es que la última de las dos líneas anteriores DEBE aplicarse al final de su mapa criptográfico. Ya lo tienes allí, pero solo quería decírtelo.

Esta línea es lo que permite que la Fase 1 se conecte desde un punto final dinámico L2L:

túnel-grupo DefaultL2LGroup ipsec-atributos

 clave precompartida *****

 peer-id-validate nocheck

 isakmp keepalive umbral 30 reintento 5

La fase 2 es manejada por sus entradas de mapa criptográfico.

Me temo que la forma más fácil y efectiva de hacer esto sería cambiar el PSK en el grupo de túnel DefaultL2LGroup y luego cambiarlo en todos los dispositivos que aún desea conectar. Como son puntos finales dinámicos, no se puede filtrar por IP en la interfaz externa, y no tiene control sobre ellos para establecer un túnel si conocen el PSK.

Si tiene alguna pregunta, no dude en preguntar.

Ian

@aleks: si sabe qué dispositivos L2L ya no desea que se le permita, y conoce sus rangos de IP privada, ¿no podría simplemente negar esas IP privadas en su ACL entrante (el que se aplica a la interfaz externa de su ASA). Es posible que esto no impida la configuración de la Fase 2, pero seguramente no permitirá que pase el tráfico. Solo un pensamiento (me encontré con esta pregunta mientras buscaba en Google un problema diferente).