Basculement VPN de site à site Cisco ASA

21

Nous avons récemment remplacé le MPLS international par de nouveaux ASA 5510 et des VPN de site à site. Cependant, lorsque nous avons déployé cela, nous avons rencontré un problème où chaque emplacement distant a 2 FAI pour la redondance, mais lors de l'activation du VPN sur les deux interfaces, il oscille entre les deux et le tunnel monte et descend lorsque le tunnel est démoli et déplacé entre FAI. Cisco y travaille depuis 8 mois maintenant et nous n'avons toujours pas de tunnels stables avec plusieurs FAI.

Bureau distant:

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

Bureau 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 *****

Donc, ce que j'ai trouvé, c'est que lorsque ISAKMP est activé sur les deux interfaces externes (bureau distant) et que les deux IP sont configurées en tant que pairs (bureau central), le VPN arrive avec succès sur les deux interfaces, mais à un moment donné, il commencera à basculer entre les IP. Cela est vrai avec ou sans la surveillance SLA, donc même si les routes sont toutes statiques, le comportement se produit toujours.

Toute idée est appréciée.

Scott Boultinghouse
la source
Pour aider à diagnostiquer le problème, essayez d'activer la fonction "crypto isakmp déconnect-notifier" et faites-nous savoir ce que vous trouvez. Je suis très curieux de savoir pourquoi ces tunnels commencent finalement à battre.
skrumcd

Réponses:

14

J'ai migré des sites loin des VPN basés sur des politiques pour cette raison. Les VPN basés sur des stratégies sont trop imprévisibles en ce qui concerne le comportement de basculement. Je préfère de loin les tunnels IPsec basés sur l'itinéraire, soit point à point, soit DMVPN. Malheureusement, à ma connaissance, la plate-forme ASA ne prend toujours pas en charge les tunnels basés sur l'itinéraire.

Jeremy Stretch
la source
9

Je recommanderais d'utiliser une solution DMVPN pour connecter des sites distants sur des tunnels IPSec L2L (Lan-to-Lan) entre ASA. La solution DMVPN est beaucoup plus facile, plus propre et permettra également la communication entre les rayons.

twidfeki
la source
Pouvez-vous nous expliquer les réflexions fondamentales qui se cachent derrière cela et comment cela serait mis en œuvre?
SimonJGreen
Avec une solution DMVPN, toute la configuration est effectuée côté client (rayons), vous n'avez pas à apporter de modifications aux concentrateurs après la configuration initiale. Pour le client, vous pouvez créer un modèle à utiliser encore et encore. Vous pouvez avoir plusieurs tunnels depuis les rayons vers plusieurs hubs et utiliser des protocoles de routage pour déterminer le tunnel sur lequel acheminer le trafic. En outre, vous pouvez configurer le DMVPN pour utiliser le GRE multipoint et les rayons peuvent communiquer directement sans passer de trafic via les concentrateurs.
twidfeki
4

Pourrait être:

CSCub92666

ASA: les anciennes connexions détruisent le tunnel VPN IPSEC lors du basculement

Symptôme: dans la configuration de basculement de tunnel VPN IPsec sur ASA, le basculement entre le lien principal et le lien de sauvegarde fonctionne. Mais après le deuxième basculement de la sauvegarde vers le tunnel vpn du lien principal, commencez à battre en quelques minutes et reste instable. Le comportement est observé car l'ancienne connexion restante pointe toujours vers l'ISP de sauvegarde.

t0i
la source
2

Je suis d'accord avec les déclarations ci-dessus. Allez simple IPSec basé sur VTI ou DMVPN alternativement. N'oubliez pas d'exécuter différentes instances de procotol de routage dans et sans les tunnels. Oui, vous devrez remplacer les ASA par des ISR.

Les deux FAI retournent-ils à un seul siège social ASA ou deux? Si deux, j'ai du mal à voir (avec la configuration disponible au moins) comment ce comportement pourrait se produire, mais si c'est la même ASA (ou la même paire), il pourrait être lié.

wintermute000
la source
Oui, nous avons une paire HA dans l'emplacement central. Le routage BGP y cache les multiples FAI, mais pour les bureaux distants, le FAI se termine directement sur l'ASA.
Scott Boultinghouse
Je séparerais la tête de réseau afin que l'autre connexion ISP se termine sur un appareil différent ou au moins entre sur une interface physique / IP différente sur l'ASA. Cela devrait aider / essayer un périphérique de terminaison différent devrait être gratuit / non perturbateur, utilisez simplement un ISR de rechange pour l'instant
wintermute000
2

Pour faire suite à cette question, je travaille avec Cisco TAC sur ce sujet depuis plus d'un an. Ils ont finalement identifié qu'il s'agit d'un bug avec la façon dont la plate-forme ASA gère les connexions. essentiellement, il n'effaçait pas les connexions d'une interface lorsqu'il déplaçait le tunnel vers l'autre interface et il deviendrait incontrôlable alors qu'il commençait à voir des entrées dans la table de connexion sur les deux interfaces.

J'ai déployé la version 8.4.7 d'IOS sur le pare-feu avec deux FAI et il semble en fait se comporter correctement. Le basculement se produit lorsque l'interface principale tombe en panne, puis revient lorsque cette interface revient ET reste sur cette interface. Nous verrons.

Scott Boultinghouse
la source
1
Avez-vous un ID de bug pour le bug sur lequel TAC a travaillé?
Le tunnel prévaut-il de la sauvegarde sur le serveur principal lorsque le serveur principal est restauré?
Federi