Le trafic UDP via ASA échoue après la reconnexion de la liaison ISP primaire dans une configuration ISP double

Introduction

Si un dispositif de sécurité adaptatif (ASA) possède deux interfaces de sortie par sous-réseau de destination et que la route préférée vers une destination est supprimée de la table de routage pendant un certain temps, les connexions UDP (User Datagram Protocol) peuvent échouer lorsque la route préférée est rajoutée à la table de routage. Les connexions TCP peuvent également être affectées par le problème, mais comme le protocole TCP détecte la perte de paquets, ces connexions sont automatiquement interrompues par les points d’extrémité et reconstruites en utilisant les routes les plus optimales après la modification des routes.

Ce problème peut également être observé si un protocole de routage est utilisé et qu'une modification de topologie déclenche une modification de la table de routage sur l'ASA.

Avant de commencer

Exigences

Afin de rencontrer ce problème, la table de routage de l'ASA doit changer. Ceci est commun avec les liaisons ISP doubles de manière redondante ou lorsque l'ASA apprend des routes via un IGP (OSPF, EIGRP, RIP).

Ce problème se produit lorsque la liaison ISP principale revient en ligne ou que ledit IGP voit une reconvergence en raison de laquelle une route moins préférée qui était utilisée par l'ASA est remplacée par la route à métrique inférieure préférée. Vous constaterez alors que les connexions à longue durée de vie, telles que les enregistrements SIP UDP, GRE, etc., échouent une fois que la route principale ou préférée est réinstallée dans la table de routage de l'ASA.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Tout appareil de sécurité adaptatif de la gamme Cisco ASA 5500

• ASA versions 8.2(5), 8.3(2)12, 8.4(1)1, 8.5(1) et ultérieures

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous aux Conventions relatives aux conseils techniques Cisco.

Problème

Si une entrée de table de routage est supprimée de la table de routage de l'ASA et qu'il n'y a aucune route en dehors d'une interface pour atteindre une destination, les connexions établies à travers le pare-feu avec cette destination étrangère seront supprimées par l'ASA. Cela se produit de sorte que les connexions peuvent être établies à nouveau à l'aide d'une interface différente avec des entrées de routage pour la destination présente.

Cependant, si des routes plus spécifiques sont ajoutées à la table, les connexions ne seront pas mises à jour pour utiliser les nouvelles routes plus spécifiques et continueront à utiliser l'interface moins optimale.

Par exemple, considérez que le pare-feu a deux interfaces qui font face à Internet - "externe" et "de secours" - et ces deux routes existent dans la configuration de l'ASA :

route outside 0.0.0.0 0.0.0.0 10.1.1.1 1 track 1
route backup 0.0.0.0 0.0.0.0 172.16.1.1 254

Si les interfaces externe et de secours sont toutes deux activées, les connexions établies en sortie via le pare-feu utiliseront l’interface externe, car elle a la métrique préférée de 1. Si l’interface externe est arrêtée (ou si la fonction de surveillance SLA qui suit la route rencontre une perte de connectivité avec l’IP suivie), les connexions utilisant l’interface externe seront désactivées et recréées à l’aide de l’interface de secours, car l’interface de secours est la seule interface avec une route vers la destination.

Le problème se produit lorsque l’interface externe est rétablie ou que la route suivie redevient la route privilégiée. La table de routage est mise à jour pour privilégier la route d'origine, mais les connexions existantes continuent d'exister sur l'ASA et traversent l'interface de sauvegarde et ne sont PAS supprimées et recréées sur l'interface externe avec la métrique la plus préférée. En effet, la route de sauvegarde par défaut existe toujours dans la table de routage spécifique à l'interface de l'ASA. La connexion continue d'utiliser l'interface avec la route la moins préférée jusqu'à ce que la connexion soit supprimée ; dans le cas du protocole UDP, cette durée peut être indéterminée.

Cette situation peut entraîner des problèmes avec les connexions à longue durée de vie, telles que les enregistrements SIP externes ou d'autres connexions UDP.

Solution

Afin de résoudre ce problème spécifique, une nouvelle fonctionnalité a été ajoutée à l'ASA qui provoquera l'interruption des connexions et leur reconstruction sur une nouvelle interface si une route plus préférée vers la destination est ajoutée à la table de routage. Afin d'activer la fonctionnalité (elle est désactivée par défaut), définissez un délai d'attente non nul à la commande timeout flottante-conn. Ce délai d'attente (spécifié dans HH:MM:SS) spécifie le délai d'attente de l'ASA avant qu'il n'interrompe la connexion une fois qu'une autre route préférée est rajoutée à la table de routage :

Voici un exemple d'interface de ligne de commande permettant d'activer cette fonction. Avec cette interface de ligne de commande, si un paquet est reçu sur une connexion existante pour laquelle il existe maintenant une route différente, plus préférée vers la destination, la connexion sera interrompue 1 minute plus tard (et reconstruite à l'aide de la nouvelle route, plus préférée) :

ASA# config terminal
ASA(config)# timeout floating-conn 0:01:00
ASA(config)# end
ASA# show run timeout
timeout conn 1:00:00 half-closed 0:10:00 udp 0:50:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:01:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout xlate 0:01:00
timeout pat-xlate 0:00:30
timeout floating-conn 0:01:00
ASA#

Cette fonctionnalité est ajoutée à la plate-forme ASA dans les versions 8.2(5), 8.3(2)12, 8.4(1)1 et 8.5(1), y compris les versions ultérieures du logiciel ASA.

Si vous exécutez une version du code ASA qui n'implémente pas cette fonctionnalité, une solution de contournement du problème serait de vider manuellement les connexions UDP qui continuent à prendre la route moins préférée malgré une meilleure route rendue disponible via un clear local-host <IP> ou clear-conn <IP> .

La référence de commande répertorie cette nouvelle fonctionnalité sous la section timeout.

Informations connexes

• Assistance et documentation techniques - Cisco Systems