Le split tunneling n’exempte pas un hôte public des règles NAT de l’ASA

Le split tunneling est généralement décrit comme un moyen de garder le trafic d’entreprise dans le tunnel et le reste d’Internet hors du pare-feu. Les deux moitiés de cette description sont fausses de la même manière. Le split tunneling est une décision de routage prise par le client, et une décision de routage ne dit rien de ce qui arrive au paquet après son arrivée au headend.

Un seul service partenaire sur une adresse publique, qui exige de voir l’adresse de votre siège, suffit à faire tomber ce récit.

Le mythe : le split tunnel retire le pare-feu du chemin

La croyance est que toute destination hors des plages privées reste sur la connexion Internet locale, si bien que le pare-feu ne la voit jamais et n’a jamais besoin d’une règle pour elle. Cela n’est vrai que tant que la destination est absente de la liste du tunnel. Dès qu’un opérateur ajoute un hôte public à l’ACL split-include, le client envoie ce trafic dans le tunnel, et l’ASA doit le router, le filtrer et le traduire comme tout autre flux déchiffré. Rien n’a changé sur le client, sauf la liste des destinations.

Le client n’est pas devenu un routeur. Il a suivi la politique que vous lui avez donnée.

Ce que fait réellement une route split-include

Dans une configuration d’accès distant Cisco ASA, la stratégie de groupe porte split-tunnel-policy tunnelspecified et un split-tunnel-network-list qui nomme une ACL standard. Chaque ligne permit de cette ACL est une destination que le client doit envoyer dans le tunnel, et tout le reste continue d’utiliser la route par défaut locale.

Ajouter un hôte est une seule ligne, et c’est la seule partie du changement que le client peut voir : access-list RA-SPLIT standard permit host 203.0.113.20.

Reconnectez le client ensuite. La politique est échangée au moment de la connexion, donc une session établie conserve l’ancienne liste et donne l’impression que le changement n’a rien fait.

Le paquet arrive et repart par la même interface

Suivez maintenant le flux après le déchiffrement. Le paquet est entré par l’interface extérieure via le tunnel VPN, sa destination est une adresse publique, et la table de routage le renvoie par cette même interface extérieure vers Internet. Le trafic qui entre et sort par une seule interface est abandonné sauf si l’ASA est autorisée à le permettre, et c’est ce que fait same-security-traffic permit intra-interface. Sans cela, la connexion échoue d’une manière qui ressemble à un problème de routage sans en être un.

Ce paramètre est global. Il autorise le hairpinning pour chaque flux qui en a besoin, pas seulement pour cet hôte partenaire, il appartient donc à un changement revu plutôt qu’à un test rapide.

Pourquoi un PAT limité à la destination n’est pas optionnel

L’adresse source du paquet déchiffré reste l’adresse VPN du client, généralement issue d’un pool comme 10.77.0.0/24. Cette adresse n’a pas de route sur l’Internet public, donc le partenaire soit ne répond jamais, soit répond dans le vide.

La traduction corrige la source et laisse la destination intacte. Comme les objets sont déjà définis ailleurs, une règle manuelle limitée à cette destination a cette forme :

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

La partie destination static compte. Si vous l’omettez, la règle devient une traduction large qui peut correspondre à bien plus de trafic que prévu, et une règle identity large placée plus tôt dans l’ordre peut la battre entièrement. Vérifiez show nat detail et l’ordre des sections avant de supposer que votre règle est celle qui correspond.

Le PAT d’interface signifie aussi que le partenaire voit l’adresse d’interface de l’ASA, qui peut être traduite à nouveau en amont. Si le contrat nomme une adresse, confirmez-la de bout en bout plutôt qu’à un seul saut.

Prouvez-le avec la bonne destination de test

Utilisez l’hôte partenaire lui-même, pas une page what-is-my-ip générique. Cette page est presque certainement hors de la liste split, elle rapporte donc votre adresse Internet locale et ne dit rien de ce chemin. Ouvrez une nouvelle connexion au service partenaire et demandez-leur quelle source ils ont observée, ou exécutez packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed et lisez les étapes NAT et routage ligne par ligne. Un traceroute depuis le client est une vérification plus faible, car il montre le chemin qui a déjà eu lieu plutôt que la politique qui l’a choisi.

Vérifiez ensuite ce qui ne doit pas changer. Un site web ordinaire doit toujours sortir par la connexion locale, et une ressource privée de la liste du tunnel doit rester accessible. Un changement qui répare le partenaire et casse l’un des deux est un autre bug.

La version qui fonctionne de ce design est courte : un hôte dans l’ACL split, l’autorisation hairpin, une règle PAT limitée à la destination. Tout le reste de l’histoire est le mythe.