Sécurité des Réseaux VPN Virtual Private Networks

Sécurité des Réseaux: VPN (Virtual Private Networks)

Agenda • VPN ? • VPN Technologies • Access, Intranet, Extranet VPNs • VPN Exemples

Agenda • Concevoir, installer et configurer des réseaux privés virtuels (VPN) sécurisés • Utiliser le tunneling pour créer des liens privé étendus sur les réseaux publiques partagés • Sécuriser les VPN à l'aide des protocoles IPsec (IP Security Protocols)

Introduction • DEFINITION : Un VPN (Virtual Private Network) est un service offrant une connexion sécurisée via un réseau public (tel qu'Internet , Frame Relay . . etc). • Historiquement, on est passé du VPN de niveau 2 (ATM, X 25, Frame. Relay) à des VPN de niveau 3 (IPSEC). • Le VPN IP impose la mise en place d'un canal dédié

Introduction • Ce canal peut être implémenté de différentes manières : L 2 TP (niveau 2 du modèle OSI) ou IPSec (niveau 3) ou PPTP (Microsoft) ou GRE (Generic Routing Encapsulation permettant de créer un réseau VPN dédié) ou L 2 F (protocole Cisco). • On peut rajouter du cryptage au niveau de ce canal : DES(56 bits), 3 DES (168 bits), CET (technologie de cryptage propre à Cisco), IDEA (utilisé pour PGP) ou AES (128, 192 ou 256 bits).

Vue d'ensemble d'IPSec • • A été défini lors des spécifications d'IPv 6. Selon la RFC IETF RFC 2401: "Protocole de sécurité au sein de la couche réseau. Ce protocole est développé pour fournir un service de sécurité à base de cryptographie, permettant de garantir l'authentification, l'intégrité, le contrôle d'accès et la confidentialité des données. " D'une manière plus commune : IPSec = formatage de trame permettant le chiffrement des données au niveau IP.

ON a 3 Types de VPNs: Time Application Alternative Remote access Mobile users VPN RTC Télétravailleurs Type ISDN Benefices Universel access, lower cost Site-to-site Extranet VPN Leased line Business-to-business Intranet VPN Internal connectivity Fax External connectivity Mail Extend connectivity, lower cost Frame Relay e-commerce 12 -7

VPN Architectures et Technologies Service Access VPN Intranet / Extranet VPN Architectures Client–Initiated NAS–Initiated Protocoles d’accès VPN L 2 F/L 2 TP, IPsec, PPTP IP Tunnel Virtual Circuit MPLS GRE, IPsec, MPLS Technologies d’accès VPN Dial, ISDN, DSL, Mobile IP, FR, ATM, IP ou IP+ATM 12 -8

Vue d'ensemble d'IPSec • • • IPSec fournit les services suivants : - Confidentialité des données : pas de décryptage possible au milieu du canal - Intégrité des données : pas de modification des données pendant le transport - Authentification de l'origine des données : verifie adresse IP source. . . C'est ce que l'on appelle la non-répudiation - Anti-rejeu : pas de possibilité de rejouer des paquets afin de s'infiltrer dans une communication. Ceci est basé sur la vérification des numéros de séquences.

Vue d'ensemble d'IPSec • • • IPSec est basé sur l'un des 2 principaux protocoles : - AH (Authentication Header) - ESP (Encapsulation Security Payload) • Ipsec fonctionne en Mode tunnel/Mode transport: • Le mode tunnel correspond au cas ou au moins l'un des 2 peers IPSec se comporte comme une gateway/passerelle IPSec , qui décrypte/encrypte, mais les paquets ne lui sont pas directement destinés.

Vue d'ensemble d'IPSec • • Exemple de IPsec en Mode TUNNEL : - Cas ou les 2 peers sont des gateways (Routeur VPN) : si on fait un VPN LAN TO LAN => les deux peers encryptent et décryptent tour à tour, mais les paquets sont destinés aux LAN inside qu‘ils protègent. Le mode transport est utilisé quand on fait du VPN entre 2 hosts (2 Serveurs, 2 PC, . . . ), ou entre un host et une gateway qui dans ce cas se comporte comme un simple host. Exemple : - PC à PC - Serveur à Serveur

IKE (Internet Key Exchange) • IKE (Internet Key Exchange) • IKE est un protocole servant à IPSec : - authentification des peers IPSec, – négociation des SA(Security Associations) IKE et IPSec, établissement des clefs pour les algorithmes d'encryption utilisés par IPSec.

AH (Authentication Header) : (IP: 51) • AH (Authentication Header) : (IP: 51) • AH fournit l'authentification et l'intégrité des données, mais pas la confidentialité (encryption des données). • L'authentification est assurée par la création d'une signature ou digest avec MD 5. • En option, AH peut aussi fournir l'anti-rejeu. •

AH (Authentication Header) : (IP: 51) • Plus de détails sur AH protocol: • • • Intégrité du paquet dans son intégralité (sauf le TTL bien sûr qui diminue à chaque routeur). Par contre pas de cryptage des données => pas de confidentialité. Paquet d'origine : IP Header + Data 1 - A l'aide de MD 5 ou SHA-1 on fait un hash du [IP Header + data] => production d'un AH Header => Nouveau paquet : IP Header + AH + Data 2 - Le paquet est transmis à l'autre peer IPSec 3 - L'autre peer hash le IP Header + Data du paquet venant de lui arriver. Il en extrait le AH header, puis compare les 2 hash. 1 bit de différence suffit à rendre le paquet invalidé.

ESP (Encapsulating Security Payload) : (IP: 50) • ESP (Encapsulating Security Payload) : (IP: 50) • Fournit les mêmes services que AH, mais en plus, assure la confidentialité des données. • Cette confidentialité est basée sur l'utilisation d'un algorithme dit "symétrique" : DES (56 -bits), 3 DES. • ESP Ne prend pas en compte l'en-tête IP dans l'intégrité du paquet. En d'autre termes, il n'y a pas de hash de la partie IP Header.

mode transport • Si on est en mode transport (mode bout en bout) : • On chiffre le "reste du paquet (autres headers + payloads)" avec la clef secrète génèrée, et on rajoute au paquet un header ESP. • Le paquet IPsec devient donc : • IP Header + Header ESP + le reste du paquet (autres headers H 4+ payloads) crypté •

Agenda • Si on est en mode tunnel (les peers IPSec jouant le rôle de gateway IPSec): • • • De nouveaux IP Headers sont ajoutés lors du routage des paquets, mais TOUT le paquet origine est crypté avec la secret key => le IP Header d'origine est conservé intacte dans la partie cryptée. Le paquet devient donc : New Ip Header + ESP Header + Crypté[Ip Header origine + le reste du paquet (autres headers + payloads)] => ESP -> confidentialité car on a chiffrement des données -> plus grande consommation de CPU.

IPsec 3 types de Paquets IPsec AH Protocol (RFC 2402) Original IP Layer IP HDR Data IPsec Authenticated session Original IP Layer IP HDR AH HDR Data ESP Transport Mode (RFC 2406) Original IP Layer IP HDR Data IPsec Encrypted session IP HDR ESP HDR Data Original IP Layer IP HDR Data encrypted ESP Tunnel Mode (RFC 2406) Original IP Layer IP HDR Data IPsec Tunnel New IP HDR ESP HDR IP HDR Data encrypted Original IP Layer IP HDR Data 12 -18

IPsec Définitions des 3 Normes IPsec Protocol Authentication Header (AH) RFC 2402 Encapsulation Secure Payload (ESP) Transport Mode RFC 2406 Encapsulation Secure Payload (ESP) Tunnel Mode RFC 2406 Definition • Provides authentication of sender and receiver • Low byte overhead • No impact on Qo. S/Co. S options • Minimal impact on performance • Moderate byte overhead • Maintains all Layer 2/3 Qo. S info (IP TOS bits, MAC, IP addresses, etc) • Provides confidentiality • Provides both confidentiality and protection from traffic analysis • Maintains Layer 2/3 Qo. S info • Can be transparent to end systems! Limitations Résumé • No confidentiality (no encryption) • No traffic analysis protection Does not actually segregate traffic to provide VPNs, but may be used in conjunction with ESP to authenticate partners, customers, etc. • Moderate overhead • Lose all Layer 4+ Qo. S info (ports, flows, applications, etc. ) • Decreased performance due to en/decryption • End systems must be IPsec capable Provides confidentiality of packet data, but not source and destination addresses. Both end systems must be IPsec capable since no tunneling is done. • Additional bandwidth consumption (overhead) • Lose all Layer 4+ Qo. S info • Decreased performance of network devices that initiate/terminate tunnel due to en/decryption Most complete security but highest cost (overhead and decreased performance of network devices). Most VPNs will use this method so that the gateway/firewall is the only IPsec needed on their Intranet. 12 -19

IPsec Access VPN Step 1 Client Gateway/Firewall Identity Certification ISDN POTS Certificate Authority POP with NAS LCP negotiation (PPP setup) NAS issues CHAP challenge CHAP Response / CHAP Auth-OK Step 2 Corporate Intranet PPP setup with ISP’s NAS AAA DNS/DHCP PPP Internet Key Exchange (IKE) Security Association is setup between client and gateway to negotiate tunnel protocols and authentication methods PPP IPsec Tunnel Layer 3 Tunnel is setup and authenticated with home gateway using IKE Step 3 Internal IP layer functionality is passed through tunnel with Corporate Intranet IP IPsec Tunnel PPP Step 4 IP IP Client’s software now uses the IPsec ESP Tunnel with the corporate gateway to pass the corporate, internal IP connectivity through the ISP(s)’s IP network(s) 12 -20

DES • • DES => Chiffrement des blocs de 64 bits avec une clé de 56 bits. 3 DES => Les données à crypter sont segmentées en blocs de 64 bits. Puis on crypte chaque bloc 3 fois (d'où le 3 de DES) avec une clef de 56 -bits différente à chaque process. 3 DES = 3 processus DES en cascade avec 3 clefs de 56 bits => clef « totale » de 168 bits. ).

DES/3 DES et AES • • DES/3 DES et AES = Algorithmes de chiffrement à clé secrète DES/3 DES Inventé à l'origine par IBM. Algorithmes de chiffrement « par blocs » : les messages sont chiffrés par blocs entiers (de 64 bits dans le cas de DES et 3 DES). Terminologie : on parle de : - CYPHERTEXT pour désigner des données cryptées ; - CLEARTEXT pour désigner des données passant en clair (non cryptées).

AES • AES (Advanced Encryption Standard) : nouveau standard de chiffrement • Il constitue le remplaçant du DES/3 DES. • Cet algorithme a été développé par 2 universitaires Belges (Rijmen et Daemen). • Il s'agit comme pour DES/3 DES, d'un algorithme de chiffrement par blocs.

AES • • Les blocs sont ici de 128 bits (contrairement à DES/3 DES où les blocs ne sont que de 64 bits). Les clés de chiffrement soit de 128, 192, ou 256 bits. Contrairement à DES, AES ne comporte que des opérations arithmétiques simples ce qui a pour conséquence de ne pas nécessiter l'utilisation de composant hardware pour le chiffrement/dechiffrement, et offre des performances supérieures (AES est considéré comme 3 fois plus rapide que 3 DES sur plate-forme identique).

Diffie-Hellman • • Diffie-Hellman et RSA : Cryptographie à clef publique Ce concept révolutionna le monde de la cryptographie. DH est un protocole de cryptographie à clefs publiques. Il permet à 2 peers d'établir une clef secrète partagée utilisée par les algorithmes d'encryption (DES, MD 5, . . . ) Cet établissement de clef partagée se faisant via un canal non sécurisé (ex : Internet).

Diffie-Hellman • • • DH est utilisé au sein d'IKE pour établir les clefs de sessions. RSA (Rivest, Shamir, and Adelman Signature) Les inventeurs : Rivest, Shamir et Adleman, en 1978. RSA est un mécanisme cryptographique à clefs publiques utilisé pour l'authentification. D'une manière courante, IKE utilise DH pour déterminer les clefs secrètes de chaque peer IPSec. L'échange DH peut être authentifié avec une signature ou une pre-shared key suivant l'algorithme RSA.

HASHING DIGEST ? • • HASHING : MD 5 (128 bits) / SHA-1(168 bits) = Signature = hashing crypté avec clef privé de l'utilisateur A Utilisé pour certifier l'intégrité et l'authenticité d'un document. Le résultat est un digest de taille fixe. Les mots Resume et digest représentent la même chose. . Caractéristiques du digest : - Impossibilité de reconstruire les données à partir du digest ; - Si un bit des données change, le digest résultant sera très différent de l'originel (= effet d'avalanche).

HASHING DIGEST ? Exemple : • Utilisateur A (émettant le message) : • 1. Message 1 -> Processus de hashing (MD 5 ou SHA 1) -> Resume 1 • 2. Message 1 + Resume 1 + clef privée A • -> Message 1 crypté • Utilisateur B (recevant le message) : • 3. Décryptage du message 1 avec la clef publique de A => Message 1 + Resume 1 • 4. On passe le message 1 dans le hashage => Resume 2 • Si Resume 1 = Resume 2, alors le message est intègre = non modifié.

MD 5 (Message Digest 5) Il s'agit d'un algorithme de hashage utilisé pour authentifié les données. Un algorithme de hashage est un mécanisme d'encryption prenant en entrée un message de taille arbitraire, et produisant un message de taille fixe (appelé Resume ou Digest). IKE, AH et ESP utilisent MD 5 pour les processus d'authentification. Le digest toujours de taille fixe : 128 bits dans le cas de MD 5. SHA-1 (Secure Hash Algorithm-1) Un équivalent de MD 5, mais plus sûr. . . Le digest toujours de taille fixe : 168 bits dans le cas de SHA-1.

Mécanisme DE ESP • Mécanisme de ESP: • • • Peer 1: Le peer 1 possède une Clef A + une clef secrète (shared secret) incorporée au niveau de l'algorithme. => avec ça on crypte le texte. Le texte clair est envoyé à l'autre peer via ESP (rappel, il n'y a pas d'encryption avec AH, donc DES n'est utilisé que dans le cas d'ESP!!) • • Peer 2: Il possède la même clef A et le même secret partagé.

Comment s'opère la méthode DH • • Comment s'opère la méthode DH Prenons le cas classique de 2 utilisateurs : BOB et ALICE • • • 1 - Bob choisit un grand nombre premier (noté P) 2 - Alice fait de même (son nombre sera noté Q) =================== 3 - Bob envoie P à Alice 4 - Alice envoie son nombre Q à Bob =================== 5 - Bob génère une racine primitive (à l'aide de P et Q) : G 6 - Alice fait de même. Cette racine est identique à celle de Bob. On la note donc G aussi. • • •

Agenda • • • 7 - Bob choisit un nombre Xa (clef privée) dans une liste de valeurs exponentielles Soit la liste est codée sur 768 bits => DH groupe 1 Soit cette liste est codée sur 1024 bits => DH groupe 2 8 - Alice fait de même : nombre Xb (clef privée) =================== 9 - Bob génère sa clef publique : Ya = reste de la division entière = G exp (Xa) * modulo (P) 10 - Alice fait de même : Yb = G exp (Xb) * modulo (P) =================== 11 - Bob envoie sa clef publique (Ya) à Alice 12 - Alice envoie sa clef publique (Yb) à Bob Nota : Bob et Alice conservent leur clef privée respective. Cette clef n'est bien sur jamais donnée !

Agenda • • • 13 - Bob génère la clef intermédiaire de cryptage : ZZa = Yb exp (Xa) * modulo (P) 14 - Alice fait de même : ZZb = Ya exp (Xb) * modulo (P) • AVEC DH : ZZa = ZZb !!!! ================================ 15 - Bob génère la clef secrète partagée. Cette clef est dérivée de ZZ en utilisant DES ou un algorithme HMAC 16 - Alice fait de même. Cette clef commune est soit codé sur 56 bits si on utilise DES, soit sur 168 bits si on utilise 3 DES

Agenda • • Bilan : Toute la solidité de cet algorithme repose sur le choix de Xa et Xb (les clefs privées). Plus l'espace de nombre, pour ce choix, est grand, mieux c'est. Il existe 5 groupes d'espaces de choix => 5 groupes DH : Dans un espace pris le long d'une courbe exponentielle : - DH groupe 1 => espace codé sur 768 bits - DH groupe 2 => espace codé sur 1024 bits - DH groupe 3 => espace codé sur 2048 bits

Agenda • • La clef ZZ est appelée : clef de cryptage. C'est elle qui sera utilisée pour l'établissement du canal IKE puis IPSec. • • • Attention : On voit bien que DH n'EST PAS UNE METHODE DE CRYPTAGE. C'est une méthode d'échange de clefs. Tout passe en clair dans l'algorithme DH => attaque MAN IN THE MIDDLE !! Il faut donc, pendant DH, utiliser RSA avec un certificat ou une pre-shared key pour crypter les échanges de clef de cryptage !

Combien a t on de clefs dans un transfert IPSec ? • • Combien a t on de clefs dans un transfert IPSec ? - Une clef privée (X) qui n'est jamais partagée. Elle est utilisée pour signer les messages. - Une clef publique qui est partagée (= commune = Y). Elle est utilisée par l'autre peer pour vérifier la signature. - Une clef secrète partagée (dérivée de ZZ) qui est utilisée, pour crypter les données, de manière combinée avec un algorithme de cryptage (DES, 3 DES, . . . ).

Vue d'ensemble d'IKE Introduction IKE ? IKE négocie les SA (Security Associations) pour IPSec (RFC 2409) • IKE négocie les IPSec security associations (SAs). Ce processus nécessite que les systèmes IPSec s'authentifient entre eux et établissent les clefs IKE (= ISAKMP) partagées. • •

Vue d'ensemble d'IKE • En d'autres termes, IKE = Schéma de chiffrement <=> comment va se faire l'échange des informations entre les différents peers d'un VPN. • • • Schématiquement : IKE = ISAKMP (RFC 2408) + Oakley (RFC 2412) ISAKMP = protocole pour la négociation préalable à l'établissement des associations de sécurité (SA). Oakley = détermine le mécanisme pour l'échange automatique des clés.

Agenda • • IKE démarre donc avant IPSEC !!! On a 1 tunnel IKE en premier, puis un tunnel IPSec ensuite. Ce dernier étant issu des négociations IKE préalables. • • • SA ? SA = Security Associations = descriptif des process (algorithme, clefs, méthodes d'échanges, . . . ) qui seront utilisé par chaque peer d'un VPN. = objet décrivant tous les éléments qui caractérisent la communication.

Agenda • • • IKE Phase 1 = premier tunnel = ISAKMP IKE crée un canal crypté et authentifié entre les 2 peers. Cette phase est nommée IKE Security Association. C'est DH qui est l'algorithme principal de cette phase. Les sessions ISAKMP utilisent UDP (source ET destination port = 500) Les résultats de l'établissement d'une session ISAKMP sont des SAs ISAKMP (bidirectionnelles).

Agenda • • ISAKMP établit tous les SAs IPSEC à la demande. Une session ISAKMP est authentifiée : • - Soit par une clef partagée (pre-shared key) • • - Soit par RSA signature et chiffrement. De plus une session ISAKMP est chiffrée (DES) pour l'échange des clefs de session. => phase 1 = authentification des peers + établissement de la policy IKE => génération d'une SA BIDIRECTIONNELLE par peer. • •

IKE Phase 2 = deuxième tunnel = OAKLEY • IKE négocie les SA IPSec, et génère le • • matériel IPSec. Chaque peer doit donner ses préférences en matière d'algorithmes d'échange et de cryptage (c'est que l'on appelle les transform-set). C'est aussi pendant cette phase que les peers établissent le type de trafic respectif devant être crypté.

IKE Phase 2 = deuxième tunnel = OAKLEY • Lors de cette phase 2, une nouvelle utilisation de DH est faite ou alors les clefs utilisées pendant cette seconde phase seront dérivées de celles négociées lors de la phase 1. • => phase 2 = négociation des paramètres IPSec • => génération par peer de 2 SA : • 1 SA pour les flux entrants • 1 SA pour les flux sortants • Ces 2 SA sont donc UNIDIRECTIONNELLES

La 1 ere méthode • Plus spécifiquement , avec IKE Phase 1 • L’Authentification utilise 2 méthodes : – - Pre-shared keys = une clef commune entrée manuellement dans la configuration de chaque peer. – Les 2 peers s'authentifient en s'envoyant leur @IP et utilisant un challenge lié à la fameuse clef partagée.

La 2 eme méthode • La 2 eme méthode utilise un certificat numérique chacun signe avec sa clef privée (format X. 509) authentifié par une signature RSA. • Dans cette architecture tri-parties (les 2 peers + l'autorité de certification ayant délivré ET signé les certificats présents sur chaque peer), chaque peer reçoit un certificat propre émanant d'une autorité de certification. Chaque peer signe alors son certificat avec sa clef privée et crypte avec sa clef publique(elle même ayant au préalable été signée par l'autorité de certification), puis l'envoie à l'autre peer. • •

IKE Policy • IKE Policy : • Détermination de la politique ISAKMP= – IPSec SA : une politique ISAKMP définie une combinaison de paramètres de sécurité utilisés durant la négociation ISAKMP. – Pour qu'il y ait communication IPSec possible, il faut que les 2 peers trouvent un accord sur une politique ISAKMP commune.

IKE phase 1 • IKE Policy : • Une politique ISAKMP contient : • * Algorithme d'encryption : DES/3 DES • * Algorithme de hashing : MD 5/SHA-1 • * IKE SA Lifetime = durée de vie des SA IKE : 86400 secondes, ou moins.

IKE phase 2 • IKE phase 2 : • - Négociation des algorithmes IPSec = transform-set : ESP-DES, . . . • - Cette négociation est protégée grâce à la SA IKE prédéfinie. • - Identification des peers par adresse IP ou bien nom (FQDN) ; • - Détermination des adresses IP des hôtes qui doivent communiquer en crypté ;

IKE phase 2 • - Établissement des IPSec security associations : – soit de manière manuelle (pas conseillé), – soit via IKE (conseillé), dans ce dernier cas, il faut spécifier ipsec-isakmp. - Ces IPSec SAs sont périodiquement renégociées afin d'augmenter le niveau de sécurité. De plus on peut forcer le fait que les clefs de sessions IPSec seront nouvelles à chaque fois, ou simplement dérivées des clefs négociées en IKE phase 1. Cette dernière fonctionnalité est appelée PFS ( Perfect Forward Secrecy).

IKE phase 2 • - Établissement des IPSec security associations : – – – – Le contenu d'une IPSec SA est le suivant : - Adresse IP du peer d'en face ; - Identifiant de VPN (SPI = Security Parameter Index) - Algorithmes IPSec : AH/ESP + rien ou HMAC-MD 5/HMAC-SHA-1 ; - Mode (Tunnel ou Transport) ; - Clef de session ; - Attributs supplémentaires (Lifetime = durée de vie des clefs de session, . . . )

RESUME IKE IPsec • Les différentes étapes d'une connexion IPSec : • Une communication IPSec peut se découper en 3 étapes et 2 tunnels. • – Etape 1 = Tunnel IKE – IKE Phase 1 : Authentification des peers + negociation des SA IKE + montage du tunnel crypté pour la négociation des SA IPSec en phase 2. –

RESUME IKE IPsec • Etape 2 = Tunnel IPSec : – IKE Phase 2 : négociation des paramètres des SA IPSec + mise en place de ces SA sur chaque peer. • • Etape 3 : Transfert des données. – Les données sont transférées entre les peers IPSec en utilisant les paramètres IPSec + les clefs enregistrées au niveau des SA.

IPSec • • • IPSec comporte normalement 2 protocoles (AH et ESP). Suivant que l'on utilise AH ou ESP on pourra faire du VPN au travers devices faisant de la NAT. - AH (Authentication Header) = IP: 51, – permettant l'authentification de la source + anti – rejeu + intégrité. Dans ce cas le hashing (MD 5 ou SHA-1) est fait sur tout le paquet, IP headers compris (sauf bien sur les champs naturellement variables : TTL, . . . ). Ce mode est incompatible avec la NAT qui change le AH Header et cause ainsi le rejet du paquet par le peer IPSec.

IPSec • • IPSec comporte normalement 2 protocoles (AH et ESP). - ESP (Encapsulation Security Payload) = IP: 50, ESP fournit, en plus de AH, la confidentialité grâce à l'encryption au niveau IP. L'algorithme par défaut est DES (56 bits) ou 3 DES. Ce protocole supporte la NAT car le hashing (utilisé pour l'intégrité) ne prend pas en compte l'en-tête IP. Ainsi la NAT peut changer le Header IP, et pourtant le paquet sera accepté par le peer IPSec. Le petit moins, c'est que qu'en ESP, il n'y a pas de protection de l'entité IP.

REMARQUE SUR VPN et NAT • • • ATTENTION : l'utilisation d'ESP permet que les peers VPN fassent de la NAT. Cependant, dans le cas ou c'est un élément en amont du peer qui fait de la NAT, le fait d'utiliser ESP ne suffit pas ! Imaginons le cas suivant : Vous avez au sein de votre entreprise un device servant de peer VPN pour des itinérants (par exemple un firewall avec module VPN). Les itinérants utilisent en général un client VPN pour accéder à votre réseau interne via le device VPN. Quand vos itinérants sont directement connectés à Internet (via RTC , ADSL , RNIS ), . . . pas de problème !

REMARQUE SUR VPN et NAT • • • Par conter si vos itinérants se rendent chez un partenaire qui possède lui un routeur ou un firewall faisant de la NAT, çà ne marchera plus !!! En effet, le device du partenaire faisant de la NAT, il ré-écrit le header IP du paquet envoyé par vos itinérants. Votre device faisant du VPN accepte bien le paquet entrant à destination du LAN , mais la réponse venant de votre réseau interne sera destinée au device ayant officiellement envoyé le 1 er paquet. . . donc celui qui a écrit le header IP. Dans ce cas, on voit bien que c'est le device de NAT du partenaire, et non votre itinérant ! Le paquet ne reviendra donc jamais à votre itinérant !

Agenda • Le problème vient du fait qu'IPSec ne possède pas la notion de port indispensable en cas de NAT afin que le device (faisant la NAT) sache reconnaître et distinguer les connexions. •

Agenda • Questions & Réponses