L’utilisation d’IPSEC interdit la translation d’adresse au milieu d’un tunnel VPN. Pour remédier à ce problème, dans le cas d’un tunnel établi entre un client VPN nomade présent sur un réseau LAN privé et un Firewall frontal d'entreprise, les paquets IP/ESP chiffrés du VPN peuvent être encapsulés dans des paquets UDP.
Cette technique est déjà opérationnelle sur les clients VPN nomades de VPcom, de NetAsq, de SSH Sentinel 1.4, du client nomade CISCO et du client nomade Checkpoint. Nous l'avons testé avec succès. Le client SafeNet ne semble pas, dans la version que nous possédons, bénéficier de cette fonctionnalité, il bénéficie par contre d'une autre méthode de contournement du NAT des routeurs : le "NAT traversal" ou "transversal" (la solution proposée par feu freeS/WAN). Cette méthode implique néanmoins que le routeur ne soit pas équipé d'IPS bloquant cette solution.
Pourquoi la translation d'adresses n'est pas supportée ?
Lors de l’établissement d’un tunnel VPN, il y a création d’une SA (Security Association) pour les deux entités distantes. Cette SA contient les paramètres permettant aux deux entités de mettre en place les services de sécurité entre elles. Elle contient le protocole de sécurité AH ou ESP utilisé avec les services de sécurité (confidentialité, intégrité, authentification, protection contre le rejeu), les algorithmes et clés de chiffrement, la fonction de hachage. La SA contient aussi le mode du protocole IPSEC (tunnel ou transport), la durée de vie de la SA. Une SA est identifiée par le triplet suivant :
- indice SPI (Security Parameters Index)
- adresse de l’équipement de sécurité distant
- protocole de sécurité (AH ou ESP)
Un tunnel est associé à une SA (remarque : la SA est recréée au bout d’un intervalle de temps défini). Il est donc directement associé aux adresses IP des extrémités. Les adresses utilisées pour identifier une SA sont les adresses des extrémités.
Lorsqu’une extrémité du tunnel reçoit une demande d'établissement de tunnel VPN, elle vérifie si le tunnel demandé a bien été défini par l'administrateur. Si c'est le cas, le tunnel VPN se monte entre les deux extrémités.
Ensuite, lorsqu'une extrémité reçoit un paquet ESP du tunnel VPN, elle vérifie à quelle SA correspond le paquet reçu. Si l’adresse IP source est modifiée, l’entité ne peut plus déterminer la SA correspondante et les paquets ESP sont rejetés.
La translation d’adresse sur la route que devrait emprunter un VPN interdit la création de ce dernier puisque l’adresse source d’une des extrémités est modifiée (adresse privée vers adresse publique).
Solution apportée : l'encapsulation ESP dans UDP
Afin d’autoriser la translation d’adresse en utilisant un VPN, les paquets IP/ESP sont encapsulés dans de l’UDP. Cette option doit être activée au niveau du client VPN et autorisé au niveau du Firewall IPSEC.
Il faut pour cela autoriser le Firewall à recevoir des flux UDP à destination du port correspondand à l'ESP encapsulé, et l'autoriser à émettre des flux UDP à partir de ce port source d'encapsulation ESP pour les réponses.
port d'encapsulation référencé :
2787 udp : Encapsulation ESP Netasq
2746 udp : Encapsulation ESP Checkpoint
80 udp : Encapsulation ESP Cisco VPN concentrator
Attention :
1 - L'encapsulation de l'ESP dans de l'UDP ne peut se faire qu'entre un firewall et un client mobile comptatible. Il n'est pas possible d'utiliser cette option entre deux firewalls frontaux.
2 - Lorsque des clients mobiles se trouvent derrière un équipement réalisant de la translation d'adresse de type map (translation dynamique), un seul pourra établir un tunnel VPN au travers de l'équipement.
3 - Seul le protocole ESP peut-être encapsulé, pas le protocole AH.
Détail de l’encapsulation
L’adresse IP qui est utilisée pour identifier la SA est celle du paquet IP/ESP.
Sur la route empruntée par le VPN, l’adresse source du paquet IP peut être modifiée sans problème car elle ne sera pas vérifiée par la passerelle VPN pour identifier la SA. Au niveau de la passerelle VPN, les données seront désencapsulées jusqu’au paquet IP/ESP, la passerelle comparera alors l’adresse source de ce paquet avec l’adresse IP de la SA (cette fois-ci les deux adresses correspondent).
L’UDP est préférable à TCP car il rajoute moins d’overhead et les re-émissions éventuelles de paquets seront gérées par les couches encapsulées.
Règles spécifiques à mettre en place pour l'utilisation de l'option
Nous prendrons ici l'exemple d'une passerelle IPSec Netasq
En premier lieu, il faut définir un nouveau service au niveau du Firewall IPSec, correspondant au port utilisé par l'ESP encapsulé dans l'UDP. Ce service porte le numéro 2787.
Vous pouvez ensuite définir les règles suivantes :
La première règle correspond à l'autorisation du service isakmp nécessaire à l'établissement du tunnel VPN. Les deux suivantes correspondent à l'autorisation de l'ESP encapsulé dans l'UDP, puisqu'il vous faudra créer une règle dans chaque sens [nomade(eph)-->fw(2787) puis (fw(2787)-->nomade(eph)], ce type de règle n'étant pas comptatible avec le mode Statefull.
