Problème de routage avec l'envoi du trafic via un tunnel VPN de secours

Bonjour à tous,

Je rencontre des choses étranges sur notre réseau lorsque j’essaie d’utiliser le tunnel VPN nouvellement créé comme connexion WAN de secours pour notre connexion WAN MPLS principale entre nos sites.

Nous avons une connexion MPLS principale entre nos deux sites distants. Ce circuit MPLS est connecté directement à notre switch central. Le switch central est également connecté directement au pare-feu ASA 5516-x. Le switch central a des routes OSPF dynamiquement remplie à partir du circuit MPLS lorsque le circuit est opérationnel. Les deux sites sont configurés de la même manière. Tout fonctionne parfaitement. Mais maintenant, je souhaite créer une connexion WAN de secours utilisant un tunnel VPN, afin que lorsque le MPLS tombe en panne, le trafic destiné au site distant soit automatiquement routé par le tunnel VPN.

J’ai donc créé un tunnel VPN en utilisant le site distant comme pair à chaque emplacement. Pour simuler un scénario de panne, j’ai utilisé l’outil intégré packet-tracer sur l’ASA pour tenter de router le trafic destiné au réseau distant via le nouveau tunnel VPN. L’ASA n’a pas voulu envoyer le trafic via le tunnel au départ lors de l’utilisation de l’outil packet-tracer. Au lieu de cela, l’ASA envoyait tout le trafic vers le switch central via l’interface intérieure en raison d’une route statique qui utilisait un format de réseau résumé incluant les VLAN locaux et distants pour être envoyés via l’interface intérieure. C’est le résultat souhaité lorsque le circuit MPLS est opérationnel. Mais lorsque le trafic ne peut pas passer par le circuit MPLS, les routes OSPF sur le switch central disparaissent et le switch central envoie tout vers l’ASA via la route par défaut 0.0.0.0/0 pointant vers l’ASA en tant que passerelle. L’ASA dans ce scénario devrait envoyer ce trafic via le tunnel VPN.

Pour résoudre ce problème, j’ai ajouté une route statique supplémentaire aux routes statiques sur l’ASA pour indiquer à l’ASA de router le trafic VLAN distant du site local vers le site distant en utilisant l’interface extérieure, cette route statique supplémentaire ressemble à ceci :

route outside 172.20.x.x 255.255.255.0 12.x.x.x (<-- IP de la passerelle de l’interface extérieure sur l’ASA)

Cela a finalement permis à l’outil packet-tracer d’envoyer le trafic destiné à ce VLAN distant 172.20.x.x via le tunnel VPN. Pendant le fonctionnement normal, le trafic WAN site à site passait par le circuit MPLS, mais lorsque le circuit disparaissait, le trafic pour le VLAN spécifié passait par le tunnel VPN. Super, mais c’était de courte durée. Peu de temps après, un autre problème est survenu lorsque j’ai ajouté cette route. J’ai commencé à recevoir des appels d’utilisateurs se connectant au site local via le client VPN Cisco AnyConnect se plaignant qu’ils ne pouvaient accéder à aucune connexion sur le VLAN distant 172.20.x.x. J’ai donc dû supprimer cette route pour éviter que ce problème ne se produise.

Comme j’étais de nouveau sans solution, j’ai décidé d’appeler le support technique Cisco et un ingénieur m’a dit que pour surmonter ce problème, je devais utiliser SLA sur l’ASA et j’ai trois options différentes :

  1. Je peux utiliser la surveillance SLA pour suivre chaque VLAN, mais arriver à un point où si un seul VLAN tombe, le reste du trafic continuera à être routé via le MPLS.

  2. Je peux utiliser la surveillance SLA pour suivre le périphérique qui gère tous ces VLAN, de sorte que lorsque ce périphérique tombe en panne, tout le trafic de ces VLAN sera routé vers le tunnel site à site.

  3. Je peux utiliser un protocole de routage dynamique sur les ASA pour que, en cas de défaillance du lien, la route soit supprimée de la table de routage et qu’il prenne comme chemin l’interface extérieure où la carte cryptographique est configurée pour le VPN.

L’option n°1 n’est pas pratique. Je dois router tout le trafic VLAN distant via le VPN de secours lorsque la connexion MPLS principale est coupée. Quelqu’un sait-il laquelle des autres options serait la meilleure ? Je ne pense pas demander quelque chose qui n’a jamais été fait auparavant. Je n’ai pas beaucoup d’expérience en routage, donc c’est peut-être la cause du problème. Je veux simplement envoyer le trafic WAN distant par le tunnel VPN sur l’ASA lorsque la connexion MPLS principale sur le switch central est en panne, sans empêcher les utilisateurs VPN Cisco AnyConnect connectés d’accéder aux ressources du site distant. Surrement quelqu’un est déjà tombé sur cette situation dans le passé et a trouvé une solution.

Si quelqu’un peut me donner des conseils, je lui serais reconnaissant.

Nous avons cette même configuration sur tous nos sites. Vous ne devriez pas avoir besoin d’ajouter de routes à l’ASA pour vos sous-réseaux privés, sa route par défaut devrait suffire. Lorsque le circuit tombe en panne, ces routes OSPF devraient expirer sur votre core, et si la seule route qui reste est votre route par défaut vers votre ASA, le tunnel devrait se mettre en place presque immédiatement tant qu’il est configuré correctement.

Option n°3. Faites en sorte que les dispositifs qui savent si le MPLS est actif ou non l’annoncent à l’ASA, puis les routes de secours ou par défaut prennent le relais quand la connexion est perdue pour router via le VPN.

De bonnes réponses, mais une analyse vraiment curieuse du support Cisco TAC.
Vous pouvez tester en ajoutant la distance administrative [1 route statique par défaut]
route 0.0.0.0 0.0.0.0 WANMPLS [1]
route 0.0.0.0 0.0.0.0 backupVPN [10]
Bien sûr, dans votre cas, si vous souhaitez utiliser EIGRP ou OSPF, utilisez simplement la route statique sur MPLS, une fois que MPLS tombe, c’est les protocoles de routage dynamiques qui prendront le relais {les routes statiques prennent la priorité sauf pour celles directement connectées}.
Si vous souhaitez faire du dynamique en priorité puis du statique, changez simplement les distances administratives par défaut pour qu’elles soient supérieures à votre protocole dynamique, et les routes statiques prendront le relais lorsque MPLS est hors service.
Je vous conseille juste de déconnecter le câble pour tester. J’imagine que vous avez plus d’une connexion WAN… Sinon… oubliez tout ce qui précède…

Une option serait-elle d’utiliser un tunnel GRE ? Vous pouvez chiffrer les tunnels GRE avec une configuration VPN ASA assez simple puis gérer votre basculement avec tous vos routes via les interfaces Tunnel, et l’ASA continuera à faire ses trucs, sans se préoccuper de votre astuce.

Ce n’est peut-être pas adapté à votre scénario exact, mais cela m’a énormément simplifié la vie.

Bonjour à tous - MISE À JOUR

J’ai activé OSPF sur l’ASA Cisco du site local pour suivre les recommandations ci-dessus. L’objectif était de rendre l’ASA conscient des routes OSPF sur le switch central.

Cependant, cela a mis la liaison WAN hors service car toutes les routes OSPF sur le switch HP ont expiré soudainement et sont apparues sur l’ASA. Je ne vois pas pourquoi cela s’est produit, car je n’ai pas eu le temps de résoudre le problème plus en détail. J’ai dû rapidement annuler les modifications. Pour restaurer les routes OSPF sur le switch central, j’ai dû redémarrer le switch central.

Pour simplifier, nous avons 2 zones OSPF : zone 0 (périmètre) et zone 1.

Tous les VLAN locaux appartiennent à la zone 0 (périmètre). Le VLAN MPLS qui relie le site local et le site distant appartient à la zone 1. Les routes OSPF avec destination pour les VLAN distants utilisent l’interface VLAN MPLS du switch central du site distant comme passerelle.

J’ai exécuté la commande suivante sur le switch central pour l’un des VLAN locaux :
no ip ospf 10.x.x.x passive

Sur l’ASA, j’ai lancé ces commandes :
router ospf 1
network 10.x.x.x x.x.x.x area 0

Ai-je utilisé la mauvaise zone pour redistribuer les routes destinées au site distant vers l’ASA ? Étant donné que les VLAN distants sont configurés avec la zone 1 et non 0 ?

Ou peut-être dois-je utiliser les deux zones OSPF : 0 et 1, auquel cas dois-je supprimer toutes les routes statiques sur l’ASA pointant vers l’interface intérieure ?

Pourquoi les routes OSPF MPLS expirent-elles sur le switch central après avoir exécuté les commandes ci-dessus ? Elles ne devraient expirer que lorsque la connexion est coupée.

Merci pour l’information routetehpacketz. C’est ce que je pensais aussi, jusqu’à ce que Cisco TAC commence à me guider vers la solution du tunnel SLA.

Juste pour suivre votre configuration. Si vous regardez vos routes statiques sur l’ASA, avez-vous plusieurs routes statiques pour chaque VLAN local pointant vers le commutateur connecté à l’ASA, ou avez-vous une route où tous vos VLAN internes sont regroupés sous une adresse telle que : 172.16.0.0 255.240.0.0 ?

Avez-vous aussi, par hasard, configuré des routes statiques pour les VLANs distants avec l’interface extérieure comme passerelle ?