Site-to-Site IPsec VPN

Qu’il s’agisse de sécuriser une connexion ou encore de créer une liaison entre deux sites au travers d’un réseau non sécurisé tel qu’Internet, le passage par un tunnel VPN se révèle être une arme redoutable.

Cet article présente un exemple de configuration Site-à-Site. Chaque site étant une image d’un petit réseau disposat d’un accès à internet au travers d’un NAT overload…

La topologie

Configuration de base de SITE1

Configuration de l’interface WAN

interface Serial0/0
  ip address 80.1.0.2 255.255.255.252
  ip nat outside
  clock rate 2000000

Configuration de l’interface LAN

interface Loopback0
  ip address 192.168.0.1 255.255.255.0
  ip nat inside

Configuration du NAT

access-list 100 deny   ip 192.168.0.0 0.0.0.255 172.16.0.0 0.0.0.255
access-list 100 permit ip 192.168.0.0 0.0.0.255 any
ip nat inside source list 100 interface Serial0/0 overload

Note: l’access-list est déjà préparée pour la création du VPN, c’est-à-dire qu’on exclut les communications entre les deux LANs de la règle NAT.

Configuration de la route par défaut

ip route 0.0.0.0 0.0.0.0 80.1.0.1

Configuration de base de SITE2

Configuration de l’interface WAN

interface Serial0/0
  ip address 80.2.0.2 255.255.255.252
  ip nat outside
  clock rate 2000000

Configuration de l’interface LAN

interface Loopback0
  ip address 172.16.0.1 255.255.255.0
  ip nat inside

Configuration du NAT

access-list 100 deny   ip 172.16.0.0 0.0.0.255 192.168.0.0 0.0.0.255
access-list 100 permit ip 172.16.0.0 0.0.0.255 any
ip nat inside source list 100 interface Serial0/0 overload

Note: l’access-list est déjà préparée pour la création du VPN, c’est-à-dire qu’on exclut les communications entre les deux LANs de la règle NAT.

Configuration de la route par défaut

ip route 0.0.0.0 0.0.0.0 80.2.0.1

Principe de mise en place du tunnel VPN

La mise en place du tunnel VPN peut paraître complexe, mais il s’agit plutôt d’une tâche qui demande beaucoup de rigueur. En effet, il va falloir s’assurer qu’aux deux bouts du tunnel la configuration des différents paramètres soit identique.

Voici le détail de la configuration sur SITE1:

Activation de ISAKMP (le protocole qui gère l’échange des clés, etc.)

SITE1(config)# crypto isakmp enable

Création d’une stratégie de négocation des clés et d’établissement de la laison VPN

SITE1(config)# crypto isakmp policy 10
SITE1(config-isakmp)# encryption aes
SITE1(config-isakmp)# authentication pre-share
SITE1(config-isakmp)# hash sha
SITE1(config-isakmp)# group 2
SITE1(config-isakmp)# lifetime 86400

On crée donc ici une stratégie avec un numéro de séquence 10. Ce numéro indique la priorité de l’utilisation de la stratégie. Plus petit est ce nombre plus la priorité est grande. On défini ensuite les paramètres:

  • Encryptage AES
  • Authentification par clé pré-partagées
  • Algorithme de hachage SHA (valeur par défaut)
  • Méthode de distribution des clés partagées DH-2 (Algoritme de clé asymétriques Diffie-Hellman 1024bits)
  • Durée de vie 86400 secondes (valeur par défaut)

On défini ensuite si on identifie le routeur par son adresse ou par son hostname (ici l’adresse), l’identification par hostname peut être utile si on fonctionne avec une adresse publique dynamique, ce qui permet d’éviter trop de modifications de configuration en cas de changement d’adresse.

SITE1(config)# crypto isakmp identity address

On crée ensuite la clé pré-partagée, ici « CiscoLab » qu’on associe avec l’adresse de l’autre bout du tunnel donc 80.2.0.2

SITE1(config)# crypto isakmp key 0 CiscoLab address 80.2.0.2

Le 0 indique qu’on défini la clé en texte clair, en opposition avec un clé déjà cryptée si on la copie d’un « show run » d’un routeur ou l’encryptage des mots de passe est activé.

On a maintenant terminé la configuration de la partie qui gère la négociation des clés etc. La deuxième partie consite à définir comment les données seront cryptées.

Tout d’abord on crée la méthode de cryptage (transform-set) que l’on nomme VPNSET.

SITE1(config)# crypto ipsec transform-set VPNSET esp-aes esp-sha-hmac

Esp-aes est la méthode de cryptage, esp-sha-hmac est la méthode d’authentification.

On défini ensuite la durée de vie de la clé de cryptage

SITE1(config)# crypto ipsec security-association lifetime kilobytes 4096

La durée de vie est ici limitée par un volume en kilobytes (4096), on peut également définir une durée de vie en secondes (ex:crypto ipsec security-association lifetime seconds 3600).

Il faut maintenant créer une accès-list qui servira à identifier le traffic à traiter par le tunnel VPN. Pour SITE1, ce sera le traffic originaire de 192.168.0.0/24 à destination de 172.16.0.0/24. (Ce sera l’inverse pour SITE2). On crée donc une access-list étendue:

SITE1(config)# ip access-list extended VPN
SITE1(config-ext-nacl)# permit ip 192.168.0.0 0.0.0.255 172.16.0.0 0.0.0.255

Reste maintenant à créer une Crypto-map dont le but est de rassembler les différents éléments configurés pour pouvoir les appliquer enfin à une interface.

SITE1(config)# crypto map VPNMAP 10 ipsec-isakmp
SITE1(config-crypto-map)# match address VPN
SITE1(config-crypto-map)# set peer 80.2.0.2
SITE1(config-crypto-map)# set transform-set VPNSET

On a donc créé ici une Crypto-map nommée VPNMAP dans laquelle on intègre une séquence 10 (une seule crypto-map par interface, mais on peut ajouter plusieurs maps en leur indiquant des numéros de séquence différents), avec les paramètres suivants:

  • Activée pour le trafic correspondant à l’access-list VPN
  • Destination du tunnel 80.2.0.2
  • Cryptage selon le transform-set VPNSET

La dernière étape consiste à appliquer cette crypto-map à l’interface WAN de SITE1.

SITE1(config)# interface serial 0/0
SITE1(config-if)# crypto map VPNMAP

Et voilà. SITE est prêt. Reste à faire l’équivalent sur SITE2.

Configuration sur SITE2:

Parmi les points important, SITE2 soit avoir une stratégie isakmp identique à celle de SITE1 et l’access-list qui identifie le trafic à traiter par le tunnel VPN est inversée d’un point de vue de la source et de la destination.

SITE2(config)# crypto isakmp enable
SITE2(config)# crypto isakmp policy 10
SITE2(config-isakmp)# encryption aes
SITE2(config-isakmp)# authentication pre-share
SITE2(config-isakmp)# hash sha
SITE2(config-isakmp)# group 2
SITE2(config-isakmp)# lifetime 86400
SITE2(config)# crypto isakmp identity address
SITE2(config)# crypto isakmp key 0 CiscoLab address 80.1.0.2
SITE2(config)# crypto ipsec transform-set VPNSET esp-aes esp-sha-hmac
SITE2(config)# crypto ipsec security-association lifetime kilobytes 4096
SITE2(config)# ip access-list extended VPN
SITE2(config-ext-nacl)# permit ip 172.16.0.0 0.0.0.255 192.168.0.0 0.0.0.255
SITE2(config)# crypto map VPNMAP 10 ipsec-isakmp
SITE2(config-crypto-map)# match address VPN
SITE2(config-crypto-map)# set peer 80.1.0.2
SITE2(config-crypto-map)# set transform-set VPNSET
SITE2(config)# interface serial 0/0
SITE2(config-if)# crypto map VPNMAP

Vérification du tunnel VPN

Une fois le tunnel configuré, deux commandes permettent de vérifier si le tunnel fonctionne:

  • # show crypto isakmp sa
  • # show crypto ipsec sa

Toutefois, pour que l’on pusse vérifier le fonctionnement il faut que le VPN soit établi, et pour cela il faut que du trafic soit envoyé au travers de ce tunnel. Ici le test est effectué à l’aide d’un « ping » étendu:

SITE1#ping
Protocol [ip]:
Target IP address: 172.16.0.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.0.1
Type of service [0]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 144/156/176 ms
SITE1#

On peut maintenant vérifier si le tunnel à bien fonctionné

SITE1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
80.2.0.2        80.1.0.2        QM_IDLE           1001    0 ACTIVE
IPv6 Crypto ISAKMP SA
SITE1#
SITE1#sh crypto ipsec sa
interface: Serial0/0
Crypto map tag: VPNMAP, local addr 80.1.0.2
protected vrf: (none)
local  ident (addr/mask/prot/port): (192.168.0.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (172.16.0.0/255.255.255.0/0/0)
current_peer 80.2.0.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 19, #pkts encrypt: 19, #pkts digest: 19
#pkts decaps: 19, #pkts decrypt: 19, #pkts verify: 19
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0
local crypto endpt.: 80.1.0.2, remote crypto endpt.: 80.2.0.2
path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0
current outbound spi: 0xE912A86D(3910314093)
...

Les deux lignes en bleu indiquent les paquets reçus et envoyés par le tunnel VPN

Pour conclure voici une capture réalisée par WireShark sur la liaison entre SITE1 et VPN lors de l’envoi de requêtes ICP de 192.168.0.1 à 172.16.0.1:

Il est ici impossible de voir qu’il s’agit de paquets ICMP, la seule chose visible c’est qu’il y a un trafic crypté d’un bout à l’autre du tunnel.

VN:F [1.9.22_1171]
Rating: 9.3/10 (8 votes cast)
Site-to-Site IPsec VPN, 9.3 out of 10 based on 8 ratings
Posted in Cisco, La pratique, Routing
Tags: , , , , , , , , , ,
17 commentaires sur “Site-to-Site IPsec VPN
  1. nicolas dit :

    Merci pour ce tuto très clair, l’étude des VPN commence à partir de quelle certification? je n’ai pas d’information à ce sujet sur le ccna. merci

    • Les premières config de VPN sont dans la CCNA Security. On en trouve quelque trace dans la CCNP, mais pas énormément. C’est un sujet majeur de la branche sécurité (CCNA Security, CCSP, …)

  2. stuart dit :

    Slt, je ne comprends pas. Je fait la même configuration et ça ne marche pas. Je fait un test de ping en ajoutant un pc au site 1. Lorsque je ping l’adresse 80.1.0.1 cela ne fonctionne pas.

  3. Problème de routage ça …
    Le PC a-t-il la bonne passerelle par défaut ?
    le routeur WAN a -t-il une route vers le Site 1 (normalement non, ce n’est pas le but du lab).

    Ici le but est de sécuriser le traffic entre le site 1 et le site 2, pas de permettre au site 1 d’accéder au réseau WAN.

  4. EDDY dit :

    Bonjour à tous

    Merci pour ce tuto

    Jai respecté toutes kles configs jeffectue bien les pings entre les 02 routeur mais lorsque je fais sh crypto isakmp sa rien ne s’affiche

    Puis je avoir de l’aide??

    Merci

    • Difficile de dire ou se situe le probléme sans info complémentaire. En admettant que les configs soient parfaitement identiques, la première chose à vérifier, c’est le Ping en lui-même. Le tunnel VPN ne prendra effet que pour le trafic provenant du réseau 192.168.0.0/24 vers 172.16.0.0/24 et vice versant, il faut donc utiliser un Ping avancé ex: Ping 172.16.0.1 source 192.168.0.1

  5. maya dit :

    merci pr ce tuto c est b1 marché
    je pense le problème de ping et que dans ce tuto vs n avez activé les interface de ts les routeur par la cmd « no shut »

  6. maya dit :

    et aussi vs n avez ps configuré les add des interfaces du routeur wan

  7. Cet article montre la partie config qui concerne la liaison vpn. La config de base des interfaces est suffisamment simple que pour ne pas la détailler ici. De plus certains extrait de config sont des copies de la running … le no shut n’y apparaît jamais.

  8. dafunkychild dit :

    J’étais à la recherche d’un configuration similaire.

    Il y a une faute de frappe dans la configuration de l’ACL étendue sur le routeur SITE2.

    SITE2(config-ext-nacl)# permit ip 172.16.0.0.255 192.168.0.0 0.0.0.255

    j’ai corrigé par : permit ip 172.16.0.0 0.0.0.255 192.168.0.0 0.0.0.255

    Pour tout le reste, copier-coller a marché à merveille et le test a été concluant au premier essai.

    Merci Steve.

  9. Julien dit :

    Merci pour ce tutorial clair. J’ai pu tester tout marche nickel !!

  10. Alexandre dit :

    Bonjour Steve,

    je me posais une question… Ici, si je comprend bien, le VPN Ipsec créer un tunnel entre les deux routeurs site 1 et 2 de sorte qu’ils sont reliés en Peer-to-peer ? C’est la raison pour laquelle les deux LAN peuvent commuinquer sans mettre de routes sur le routeur ?

    Dans ce cas là pourquoi je vois sur Internet et dans des cours CCNA des TP dans lesquels on met des tunnels GRE à travers l’IPsec ? Quel intéret de faire un VPN dans un VPN ?

  11. Alors tout d’abord les deux lan ne sont pas connectés directement. LA liaison VPN sert de réseau point à point entre les deux sites.

    Pour ce qui concerne GRE. C’est un protocole d’encapsulation qui permet de créer ces liaisons point à point virtuelles … mais pas de les sécuriser.
    Les tunnels IPsec-GRE sont une manière pratique de permettre quasi n’importe quelles données d’être cryptées entre deux points. Sans l’emballage GRE, certains types de messages comme les broadcast ou multicast ne pourraient pas passer … donc par exemple pas de protocole de routage possible.

  12. BENNY dit :

    Bsr à tous. Merci pour le tuto, il est parfait et le VPN monte sans problème. Mon souci est que je ne peux pas traverser le routeur de part et d’autre. C’est à dire du routeur R1 je peux accéder à l’interface WAN et LAN du routeur 2 mais je ne peux pas accéder à un PC qui se trouve après le routeur 2 et vis versa. Urgence, merci pour votre aide.

  13. Milou dit :

    Bonsoir,
    Merci pour votre tuto, il est tres bien détaillé

    Tous ce qui touche au VPN c’est nouveau pour moi, excusez moi si je pose une question bete.

    Voila, je n’ai pas compris pourquoi nous devons exclure les communications entre les deux LANs de la règle NAT ??

    merci infiniment.

1 Pings/Trackback pour "Site-to-Site IPsec VPN"
  1. […] le 4 novembre 2010 par Steve De Jongh — 16 commentaires […]

Laisser un commentaire

Visit Us On FacebookVisit Us On GooglePlusVisit Us On TwitterVisit Us On LinkedinVisit Us On YoutubeCheck Our Feed

Archives

Connexion à WordPress protégée par Clef
%d blogueurs aiment cette page :