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.