NAT peut casser IPsec

négociation IKE. Le récepteur vérifie que l’adresse IP source du paquet correspond à l’identité avancée par l’expéditeur. S’il y a discordance, le paquet est rejeté. L’unité NAT change l’adresse IP du paquet ; par conséquent, les négociations IKE n’aboutissent pas si le pair ne parvient pas à reconnaître la présence d’unités NAT au milieu.

Le port de transport ne peut pas être changé dans NAT si un paquet TCP est crypté. Grâce au cryptage des données, ESP contribue à la confidentialité des données. Comme on le voit dans la figure 1, tout ce qui vient après l’en-tête IP et l’en-tête ESP est crypté, y compris le numéro de port dans l’en-tête du protocole d’application, les en-têtes TCP, et les en-têtes UDP. Par conséquent, l’unité NAT n’a aucun moyen de trouver ne serait- ce que l’information du numéro de port, et encore moins de la modifier comme devrait le faire Masquerade NAT.

NAT casse les protocoles qui protègent les adresses IP contre toute modification. IPsec utilise la vérification d’authentification et d’intégrité pour protéger contre tout tripatouillage des paquets. Par ailleurs, l’unité NAT modifie l’adresse IP du paquet en transit, comme c’est son rôle. Ce faisant, NAT empêche le calcul ICV dans AH, lequel, comme nous l’avons vu précédemment, assure l’authentification en vérifiant que le contenu d’un datagramme ne change pas en cours de route. Vous vous demandez peutêtre pourquoi le même problème existe pour ESP. ESP n’a pas à authentifier l’en-tête IP, qui contient l’adresse IP modifiée. Cependant, l’information de numéro de port dans l’en-tête TCP/UDP fait partie d’ICV pour l’authentification. Par conséquent, l’authentification ESP échoue si l’on utilise Masquerade NAT. En outre, NAT peut casser les totaux de contrôle de IP et de TCP.

Pour régler ces problèmes de compatibilité et pour permettre la coexistence de NAT et d’IPsec, la solution consiste à utiliser deux standards Internet et à créer un Firewall Friendly VPN.