Tiempos de espera para pares ASA VPN

7

He configurado un sitio remoto con dos direcciones IP para pares VPN del centro de datos: uno primario (1.1.1.1), uno de respaldo (2.2.2.2). Cuando el par primario falla, el sitio remoto detecta el error usando DPD (después de aproximadamente 15 segundos). ¡Derriba a las SA, luego procede a intentar conectarse nuevamente con el par primario! Después de aproximadamente 30 segundos sin respuesta, finalmente intenta el par de respaldo y se conecta de inmediato. ¿Alguien más ha visto esto, y hay alguna forma de evitar esta innecesaria espera de 30 segundos?

(La versión del código es 8.2 (5), configuraciones a continuación)

MURO ​​DE FUEGO REMOTO:

crypto ipsec transform-set L2L-VPN-TRANSFORM esp-3des esp-sha-hmac 
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
!
tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 general-attributes
 default-group-policy L2L-VPN-POLICY
tunnel-group 1.1.1.1 ipsec-attributes
 pre-shared-key *****
tunnel-group 2.2.2.2 type ipsec-l2l
tunnel-group 2.2.2.2 general-attributes
 default-group-policy L2L-VPN-POLICY
tunnel-group 2.2.2.2 ipsec-attributes
 pre-shared-key *****
!
crypto map OUTSIDE-MAP 1 match address ATOS-DC-ENCRYPTION-DOMAIN
crypto map OUTSIDE-MAP 1 set pfs 
crypto map OUTSIDE-MAP 1 set peer 1.1.1.1 2.2.2.2 
crypto map OUTSIDE-MAP 1 set transform-set L2L-VPN-TRANSFORM
crypto map OUTSIDE-MAP 1 set security-association lifetime seconds 3600
crypto map OUTSIDE-MAP 1 set security-association lifetime kilobytes 4608000
crypto map OUTSIDE-MAP interface OUTSIDE
crypto isakmp enable OUTSIDE
crypto isakmp policy 1
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 86400

DC FIREWALLS (TANTO LO MISMO):

crypto ipsec transform-set L2L-VPN-TRANSFORM esp-3des esp-sha-hmac 
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
!
tunnel-group DefaultL2LGroup general-attributes
 default-group-policy L2L-VPN-POLICY
tunnel-group DefaultL2LGroup ipsec-attributes
 pre-shared-key *****
!
crypto dynamic-map REMOTE-DYNMAP 1 set pfs 
crypto dynamic-map REMOTE-DYNMAP 1 set transform-set L2L-VPN-TRANSFORM
crypto dynamic-map REMOTE-DYNMAP 1 set security-association lifetime seconds 3600
crypto dynamic-map REMOTE-DYNMAP 1 set security-association lifetime kilobytes 4608000
crypto dynamic-map REMOTE-DYNMAP 1 set reverse-route
crypto map OUTSIDE-MAP 1 ipsec-isakmp dynamic REMOTE-DYNMAP
crypto map OUTSIDE-MAP interface OUTSIDE
crypto isakmp enable OUTSIDE
crypto isakmp policy 1
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 86400

Registros que muestran la falla y el retraso:

Jun 18 2013 00:52:46: %ASA-5-111008: User 'enable_15' executed the 'clear logging buffer' command.
Jun 18 2013 00:54:37: %ASA-3-713123: Group = 1.1.1.1, IP = 1.1.1.1, IKE lost contact with remote peer, deleting connection (keepalive type: DPD)
Jun 18 2013 00:54:37: %ASA-5-713259: Group = 1.1.1.1, IP = 1.1.1.1, Session is being torn down. Reason: Lost Service
Jun 18 2013 00:54:37: %ASA-4-113019: Group = 1.1.1.1, Username = 1.1.1.1, IP = 1.1.1.1, Session disconnected. Session Type: IPsec, Duration: 0h:03m:00s, Bytes xmt: 480192, Bytes rcv: 478992, Reason: Lost Service
Jun 18 2013 00:54:37: %ASA-5-713041: IP = 1.1.1.1, IKE Initiator: New Phase 1, Intf OUTSIDE, IKE Peer 1.1.1.1  local Proxy Address 10.233.224.4, remote Proxy Address 1.1.1.1,  Crypto map (OUTSIDE-MAP)
Jun 18 2013 00:54:39: %ASA-3-713042: IKE Initiator unable to find policy: Intf INSIDE-TRANSIT, Src: 10.60.1.1, Dst: 10.250.1.1
Jun 18 2013 00:54:41: %ASA-3-713042: IKE Initiator unable to find policy: Intf INSIDE-TRANSIT, Src: 10.60.1.1, Dst: 10.250.1.1
Jun 18 2013 00:54:43: %ASA-3-713042: IKE Initiator unable to find policy: Intf INSIDE-TRANSIT, Src: 10.60.1.1, Dst: 10.250.1.1
Jun 18 2013 00:54:45: %ASA-3-713042: IKE Initiator unable to find policy: Intf INSIDE-TRANSIT, Src: 10.60.1.1, Dst: 10.250.1.1
Jun 18 2013 00:54:47: %ASA-3-713042: IKE Initiator unable to find policy: Intf INSIDE-TRANSIT, Src: 10.60.1.1, Dst: 10.250.1.1
Jun 18 2013 00:54:48: %ASA-3-713042: IKE Initiator unable to find policy: Intf INSIDE-TRANSIT, Src: 10.60.1.1, Dst: 10.250.1.1
Jun 18 2013 00:54:49: %ASA-3-713042: IKE Initiator unable to find policy: Intf INSIDE-TRANSIT, Src: 10.60.1.1, Dst: 10.250.1.1
Jun 18 2013 00:54:51: %ASA-3-713042: IKE Initiator unable to find policy: Intf INSIDE-TRANSIT, Src: 10.60.1.1, Dst: 10.250.1.1
Jun 18 2013 00:54:53: %ASA-3-713042: IKE Initiator unable to find policy: Intf INSIDE-TRANSIT, Src: 10.60.1.1, Dst: 10.250.1.1
Jun 18 2013 00:54:55: %ASA-3-713042: IKE Initiator unable to find policy: Intf INSIDE-TRANSIT, Src: 10.60.1.1, Dst: 10.250.1.1
Jun 18 2013 00:54:57: %ASA-3-713042: IKE Initiator unable to find policy: Intf INSIDE-TRANSIT, Src: 10.60.1.1, Dst: 10.250.1.1
Jun 18 2013 00:54:59: %ASA-3-713042: IKE Initiator unable to find policy: Intf INSIDE-TRANSIT, Src: 10.60.1.1, Dst: 10.250.1.1
Jun 18 2013 00:55:01: %ASA-3-713042: IKE Initiator unable to find policy: Intf INSIDE-TRANSIT, Src: 10.60.1.1, Dst: 10.250.1.1
Jun 18 2013 00:55:03: %ASA-3-713042: IKE Initiator unable to find policy: Intf INSIDE-TRANSIT, Src: 10.60.1.1, Dst: 10.250.1.1
Jun 18 2013 00:55:05: %ASA-3-713042: IKE Initiator unable to find policy: Intf INSIDE-TRANSIT, Src: 10.60.1.1, Dst: 10.250.1.1
Jun 18 2013 00:55:07: %ASA-3-713042: IKE Initiator unable to find policy: Intf INSIDE-TRANSIT, Src: 10.60.1.1, Dst: 10.250.1.1
Jun 18 2013 00:55:09: %ASA-5-713041: IP = 2.2.2.2, IKE Initiator: New Phase 1, Intf OUTSIDE, IKE Peer 2.2.2.2  local Proxy Address 10.233.224.4, remote Proxy Address 2.2.2.2,  Crypto map (OUTSIDE-MAP)
Jun 18 2013 00:55:09: %ASA-5-713119: Group = 2.2.2.2, IP = 2.2.2.2, PHASE 1 COMPLETED
Jun 18 2013 00:55:09: %ASA-5-713049: Group = 2.2.2.2, IP = 2.2.2.2, Security negotiation complete for LAN-to-LAN Group (2.2.2.2)  Initiator, Inbound SPI = 0xd21ad657, Outbound SPI = 0xd7d9c25a
Jun 18 2013 00:55:09: %ASA-5-713120: Group = 2.2.2.2, IP = 2.2.2.2, PHASE 2 COMPLETED (msgid=1949f878)
Jun 18 2013 00:55:09: %ASA-5-713041: Group = 2.2.2.2, IP = 2.2.2.2, IKE Initiator: New Phase 2, Intf INSIDE-TRANSIT, IKE Peer 2.2.2.2  local Proxy Address 10.60.0.0, remote Proxy Address 10.0.0.0,  Crypto map (OUTSIDE-MAP)
Jun 18 2013 00:55:09: %ASA-5-713049: Group = 2.2.2.2, IP = 2.2.2.2, Security negotiation complete for LAN-to-LAN Group (2.2.2.2)  Initiator, Inbound SPI = 0xd4218cd3, Outbound SPI = 0xf9a8108b
Jun 18 2013 00:55:09: %ASA-5-713120: Group = 2.2.2.2, IP = 2.2.2.2, PHASE 2 COMPLETED (msgid=c0a82858)
vpn  ipsec  failover  cisco-asa 
— Daren Fulwell
fuente

Respuestas:

5

El ASA no tiene un mecanismo para marcar pares como arriba o abajo. Cuando DPD detecta que un par ya no está disponible, cualquier SA con ese par se derriba. Cuando el "tráfico interesante" requiere una nueva SA, el ASA pasa por su proceso normal de fase 1, lo que significa comenzar con el primer par en su mapa criptográfico y si no se puede establecer una conexión, intente con el segundo.

Los 30 segundos de retraso son un problema de tiempo, mientras que el ASA "soluciona las cosas", por así decirlo. Tiene tráfico que activa una nueva SA, mientras que DPD está derribando la SA existente al mismo par, lo que crea una condición de carrera que finalmente se resuelve.

Si se desea una conmutación por error más rápida, generalmente implica mantener ambos túneles simultáneamente y usar GRE y enrutamiento dinámico para mover el tráfico cuando falla un túnel. Sin embargo, eso requeriría usar enrutadores en lugar de ASA, ya que los ASA no admiten GRE y tienen algunas deficiencias con el enrutamiento dinámico.

— Santino
fuente
1
Habiendo hablado con Cisco TAC, confirman exactamente eso. Tengo la intención de enviar una solicitud de mejora, ya sea para establecer un mecanismo para marcar a un par como "muerto" por un tiempo una vez que ha sido detectado por DPD, o para colocar un valor de tiempo de espera definido por el usuario en la negociación de la Fase 1 que es de donde provienen los 30 segundos. ¡He descubierto que si cambia los pares en la configuración una vez que se establece el túnel y las SA son válidas, esa conmutación por error es solo DPD + 1 segundo, ya que primero se intenta el par "secundario" en funcionamiento! ¡Podría usar esto como una solución por ahora!
— Daren Fulwell
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.