Route par défaut tunnelée sur Cisco ASA : quand elle s'applique vraiment

Un utilisateur d'accès distant n'atteint rien au-delà de l'ASA alors que le même serveur répond aux ping depuis le LAN interne. Le tunnel monte, le client reçoit une adresse du pool, et le paquet sort toujours par la route par défaut internet ou disparaît. Ce schéma signifie généralement que le trafic déchiffré n'a pas trouvé de route propre et est retombé sur la route par défaut ordinaire. Le correctif n'est pas une règle NAT de plus ; c'est la route par défaut tunnelée.

Partez du symptôme, pas de la configuration

Regardez où va le paquet plutôt que où vous vous attendiez à ce qu'il aille. Une capture sur l'interface externe pendant une session échouée montre le paquet déchiffré se dirigeant vers la passerelle du FAI avec l'adresse du pool encore intacte, ou ne montre rien du tout parce que la recherche a échoué. Dans les deux cas, le tunnel n'est pas le problème.

Le tunnel paraît sain dans show vpn-sessiondb, et c'est exactement pourquoi les gens continuent à déboguer IKE.

Ce qui distingue cela d'un rejet ACL, c'est la direction. Un rejet ACL est journalisé et compté, tandis qu'une route manquante produit un échec de recherche sans entrée correspondante. Lancez show route pour la destination du client et lisez ce que l'ASA a réellement sélectionné, y compris si une route par défaut a été choisie et laquelle.

En quoi la recherche tunnelée diffère

Le guide Cisco du routage statique sur l'ASA 9.23 documente une route par défaut distincte pour le trafic VPN déchiffré qui n'a ni route statique ni route apprise. Le mot-clé tunneled marque cette route, de sorte qu'un paquet déchiffré peut retomber sur un prochain saut différent de celui que l'ASA utilise pour son propre transport. Les routes plus spécifiques l'emportent toujours, et c'est pourquoi un client peut atteindre 10.0.0.0/8 via la passerelle interne et perdre tout le reste.

Une disposition minimale conserve deux routes par défaut avec des prochains sauts différents. L'une porte le trafic propre de l'ASA, l'autre le trafic déchiffré sans meilleure route. Les deux prochains sauts doivent encore être joignables depuis l'interface à laquelle vous les rattachez.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

Si les deux routes par défaut pointent vers le même prochain saut, le mot-clé ne change rien et le symptôme ne bougera pas.

Les restrictions qui décident si cela fonctionne

Le même guide n'autorise qu'une seule route par défaut tunnelée et indique qu'ECMP n'est pas pris en charge pour elle, vous ne pouvez donc pas répartir la charge sur ce chemin. Il énumère aussi des restrictions concernant le suivi de routes, la vérification du chemin inverse et certains flux d'inspection et de gestion. Lisez-les au regard de votre version installée avant de concevoir autour de la fonction. Une conception qui les ignore échoue généralement à un endroit précis plutôt que partout, et c'est pourquoi le symptôme paraît intermittent.

La vérification du chemin inverse est celle qui mord dans les conceptions asymétriques. Si la réponse arrivait par une interface différente de celle qu'attend l'ASA, le paquet est abandonné avant même que le routage n'ait d'importance. Corrigez la topologie ou le chemin de retour au lieu de désactiver la vérification pour forcer un prochain saut.

Le suivi de routes est un piège à part : l'objet suivi protège généralement la route par défaut ordinaire, pas la route tunnelée.

Ce que le mot-clé ne fait pas

Il ne choisit pas l'adresse source que l'ASA utilise pour construire IKE. L'extrémité extérieure du tunnel suit la sélection d'interface et de source propre à la plateforme, et la route par défaut tunnelée n'a aucune part à cette décision. La changer ne réparera pas une phase 1 qui part de la mauvaise adresse.

Il ne transforme pas non plus le prochain saut en mandataire. Si la destination attend un échange HTTP CONNECT, envoyer des paquets IP bruts à un hôte mandataire ne vous donne qu'un hôte qui ne les route pas. Configurez plutôt le mécanisme de mandataire pris en charge par le client.

Et il ne crée pas de réacheminement en aval. La passerelle que vous visez a toujours besoin d'une route de retour vers le pool VPN, plus la traduction de source là où la conception l'exige.

Vérifiez le chemin de bout en bout

Une fois la route en place, vérifiez quatre choses dans l'ordre : show route pour une destination dont le pool a besoin, une capture sur l'interface vers le nouveau prochain saut, une capture sur la passerelle elle-même et un chemin de retour de cette passerelle vers l'adresse du pool. Les deux premières prouvent que l'ASA a choisi le chemin, et les deux dernières que quelqu'un y répond.

Si la passerelle répond mais que le client ne voit jamais de réponse, regardez la traduction de source et la route de retour avant de retoucher la table de routage.

Notez la version sur laquelle vous avez validé, car la liste des restrictions est propre à chaque version et une conception qui fonctionne sur une branche peut avoir besoin d'un autre chemin sur une autre. Cette note survit à l'extrait de configuration.