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.
Respuestas:
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.
fuente
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.
fuente
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.
fuente
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.
fuente
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.
fuente