Conmutación por error de VPN de sitio a sitio de Cisco ASA

21

Recientemente reemplazamos MPLS internacionales con nuevos ASA 5510 y VPN de sitio a sitio. Sin embargo, cuando implementamos esto, nos encontramos con un problema en el que cada ubicación remota tiene 2 ISP para la redundancia, pero al habilitar la VPN en ambas interfaces, se agita entre los dos y el túnel está arriba y abajo a medida que el túnel se rompe y se mueve entre ISP Cisco ha estado trabajando en esto durante 8 meses y todavía no tenemos túneles estables con múltiples ISP.

Oficina remota:

access-list RWS_TUNNEL remark Interesting traffic for IND-RWS tunnel
access-list RWS_TUNNEL extended permit ip object-group BNG_tunnel_NETS object-group CORP_tunnel_NETS
crypto map RWS_TUNNEL 1 match address RWS_TUNNEL
crypto map RWS_TUNNEL 1 set peer 216.xxx.102.2 
crypto map RWS_TUNNEL 1 set transform-set IND-RWS
tunnel-group 216.xxx.102.2 type ipsec-l2l
tunnel-group 216.xxx.102.2 ipsec-attributes
 pre-shared-key *****


route outside 0.0.0.0 0.0.0.0 216.xxx.206.1 1 track 2
route outside2 0.0.0.0 0.0.0.0 182.xxx.26.229 100
sla monitor 55
 type echo protocol ipIcmpEcho 63.251.61.142 interface outside
 num-packets 5
 timeout 1000
 frequency 10
sla monitor schedule 55 life forever start-time now
track 2 rtr 55 reachability

Oficina central:

access-list BNG_TUNNEL remark Interesting traffic for IND-RWS tunnel
access-list BNG_TUNNEL extended permit ip object-group CORP_tunnel_NETS object-group BNG_tunnel_NETS 

route outside2 0.0.0.0 0.0.0.0 216.xxx.102.1
crypto map BNG_TUNNEL 1 match address BNG_TUNNEL
crypto map BNG_TUNNEL 1 set peer 182.xxx.26.230 216.xxx.206.4
crypto map BNG_TUNNEL 1 set transform-set L2L

tunnel-group 182.xxx.26.230 type ipsec-l2l
tunnel-group 182.xxx.26.230 ipsec-attributes
 pre-shared-key *****
tunnel-group 216.xxx.206.4 type ipsec-l2l
tunnel-group 216.xxx.206.4 ipsec-attributes
 pre-shared-key *****

Entonces, lo que he encontrado es que cuando ISAKMP está habilitado en ambas interfaces externas (oficina remota) y ambas IP se configuran como pares (oficina central), la VPN aparece con éxito en ambas interfaces, pero en algún momento comenzará a agitarse entre las IP. Esto es cierto con o sin la supervisión de SLA, por lo que incluso si las rutas son todas estáticas, el comportamiento sigue ocurriendo.

Cualquier idea es apreciada.

Scott Boultinghouse
fuente
Para ayudar a diagnosticar el problema, intente habilitar la función "crypto isakmp desconecta-notifique" y díganos qué encuentra. Tengo mucha curiosidad por saber por qué esos túneles eventualmente comienzan a agitarse.
skrumcd

Respuestas:

14

He estado migrando sitios fuera de las VPN basadas en políticas solo por esta razón. Las VPN basadas en políticas son demasiado impredecibles cuando se trata del comportamiento de conmutación por error. Prefiero los túneles IPsec basados ​​en rutas, ya sea punto a punto o DMVPN. Desafortunadamente, que yo sepa, la plataforma ASA todavía no admite túneles basados ​​en rutas.

Jeremy Stretch
fuente
9

Recomendaría usar una solución DMVPN para conectar sitios remotos a través de túneles IPSec L2L (Lan-to-Lan) entre ASA. La solución DMVPN es mucho más fácil, más limpia y también permitirá la comunicación entre radios.

twidfeki
fuente
¿Puede explicar los pensamientos fundamentales detrás de esto y cómo se implementaría?
SimonJGreen
Con una solución DMVPN, toda la configuración se realiza en el lado del cliente (radios), no tiene que hacer ningún cambio en los concentradores después de la configuración inicial. Para el cliente, puede crear una plantilla para usar una y otra vez. Puede tener varios túneles desde los radios hasta varios centros y utilizar protocolos de enrutamiento para determinar qué túnel enrutar el tráfico. Además, puede configurar el DMVPN para utilizar GRE multipunto y los radios pueden comunicarse entre sí directamente sin pasar el tráfico a través de los concentradores.
twidfeki
4

Podría ser:

CSCub92666

ASA: Las conexiones antiguas derriban el túnel vpn IPSEC en la conmutación

Síntoma: en el túnel IPsec vpn, la configuración de conmutación por error en ASA, la conmutación por error del primario al enlace de respaldo funciona. Pero después de una segunda conmutación por error desde el respaldo al túnel vpn de enlace primario, comienza a aletear en pocos minutos y permanece inestable. El comportamiento se observa debido a que la conexión sobrante anterior todavía apunta a isp de respaldo.

t0i
fuente
2

Estoy de acuerdo con las declaraciones anteriores. Vaya a IPSEC simple basado en VTI o alternativamente DMVPN. Solo recuerde ejecutar diferentes instancias de protocolo de enrutamiento dentro y fuera de los túneles. Sí, tendrá que reemplazar los ASA con ISR.

¿Ambos ISP volverán a una sola oficina central ASA o dos? Si dos me resulta difícil ver (con la configuración disponible al menos) cómo podría ocurrir este comportamiento, pero si es el mismo ASA (o el mismo par) podría estar relacionado.

wintermute000
fuente
Sí, tenemos un par de HA en la ubicación central. El enrutamiento BGP oculta los múltiples ISP allí, pero para las oficinas remotas, el ISP termina directamente en el ASA.
Scott Boultinghouse
Separé la cabecera para que la otra conexión del ISP termine en un dispositivo diferente o al menos entre en una interfaz física / IP diferente en el ASA. Eso debería ayudar / probar un dispositivo de terminación diferente debería ser gratuito / no disruptivo, solo use un ISR de repuesto por ahora
wintermute000
2

Como seguimiento a esta pregunta, he estado trabajando con Cisco TAC en esto durante más de un año. Finalmente han identificado que esto es un error con la forma en que la plataforma ASA maneja las conexiones. esencialmente no estaba limpiando las conexiones de una interfaz cuando movía el túnel a la otra interfaz y se saldría de control cuando comenzara a ver entradas en la tabla de conexiones de ambas interfaces.

Implementé la versión 8.4.7 de IOS en el firewall con dos ISP y parece que se está comportando correctamente. La conmutación por error ocurre cuando la interfaz principal se cae, y luego retrocede cuando esa interfaz regresa Y permanece en esa interfaz. Ya veremos.

Scott Boultinghouse
fuente
1
¿Tiene una identificación de chinche para el error en el que trabajó TAC?
¿El túnel se adelanta desde el respaldo al primario cuando se restaura el primario?
Federi