IPSec Tunnel mode VS GRE over IPSEC (GREoIPSEC)

Petite mise au point sur la différence entre IPSEC tunnel mode, et Gre Over IPSEC, ainsi que comment configurer des tunnels VPN site to site…

vpn_s_to_s

Introduction

La grande difference entre Gre over IPSEC et IPSEC Tunnel mode, est que GRE vas accepter d’autre type de traffic que IP et va gérer le broadcast ainsi que le multicast. Lorsque l’on configure un tunnel GREoIPSEC, IPSEC sera en mode transport, car les paquets IP vont être encapsulés en GRE, et IPSEC va transporter ces paquets GRE. IPSEC en mode tunnel fonctionnerait aussi mais cela créérait une entête IP supplémentaire, ce qui, a part réduire la quantité de donnée dans le payload et augmenter la charge des routeurs, ne présente aucun intérêt…

Nous considérons que le routage est déjà fait (je vais utiliser EIGRP)

Configuration Tunnel IPSEC

Configuration ISAKMP

Un tunnel IPSEC se monte en deux phase, appelées phases IKE. La phase 1 permet d’établir une session ISAKMP, qui va utiliser diffie hellman pour échanger une clef afin de crypter les données transitant par ce tunnel ISAKMP.

La Phase 2 permets d’utiliser le tunnel ISAKMP afin d’échanger de manière sécurisée les paramètres pour le tunnel IPSEC.

Pour configurer ISAKMP, utiliser les commandes suivantes:

!activer ISAKMP
R1(config)#crypto isakmp enable
!Creer une politique ISAKMP: Plus petit est le nombre,
!plus prioritaire est la politique
!Il faut que les deux pair aient une politique avec les même paramètres
R1(config)#crypto isakmp policy 100
!DH Group 5
R1(config-isakmp)#group 5
!Chiffrement AES
R1(config-isakmp)#encryption aes
!Utiliser SHA pour l'auth
R1(config-isakmp)#hash sha
!Utilisation PSK
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#exit
!Renseigner le mot de passe pour la session ISAKMP pour le pair distant
R1(config)#crypto isakmp key 0 isakmpPassword address 80.0.0.2

Effectuer la même chose sur R2 (en remplaçant l’ip dans la commande crypto map isakmp key)

Configuration IPSEC

Trois étapes: Création d’un transform set, indiquant les protocoles de sécurité à utiliser: AH Pour l’authentification, ESP pour le cryptage et/ou l’authentification. On peut utiliser AH, AH+ ESP ou ESP seulement.

Creation d’une access-list identifiant le traffic à chiffrer. Le traffic permit pas cette ACL sera chiffré dans le tunnel IPSEC, le reste non…

Creation d’une crypto-map spécifiant le pair distant, le transform set, et l’access list.

Commandes Sur R1:

!Définition d'un transform set sans chiffrement
R1(config)#crypto ipsec transform-set AH_NO_ESP ah-sha-hmac
R1(cfg-crypto-trans)#exit
!Creation de l'ACL
R1(config)#ip access-list extended VPN
!uniquement le traffic entre mes 2 sites, à adapter selon ce qu'on veut chiffrer
R1(config-ext-nacl)#permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
R1(config-ext-nacl)#exit
!creation d'une crypto map pour ipsec + isakmp.
!Le numero 1 permets d'avoir plusieurs paramètes dans une même crypto map
!Cela permet d'avoir par exemple plusieurs tunnels depuis une interface car
!on ne peut avoir plus d'une crypto map par interface
R1(config)#crypto map VPNMAP 1 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
        and a valid access list have been configured.
R1(config-crypto-map)#set peer 80.0.0.2
R1(config-crypto-map)#set transform-set AH_NO_ESP
R1(config-crypto-map)#match address VPN
R1(config-crypto-map)#exit
R1(config)#int S1/0
!application de la crypto map
R1(config-if)#crypto map VPNMAP
R1(config-if)#exit
*Mar  1 00:42:52.471: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

Même chose sur R2 en changeant l’adresse IP du peer, et bien sur l’ACL (permutter source et destination)

Maintenant, si je fait un PING entre R1 et R2, en ayant bien les adresses sources des réseaux 192.168.1.0, le traffic vas être sécurisé via IPSEC (utilisation de AH).

R1#ping
Protocol [ip]:
*Mar  1 00:38:54.215: %SYS-5-CONFIG_I: Configured from console by console
Target IP address: 192.168.2.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/24/36 ms
R1#
AH

Capture AH+ESP

On remarque que les IP source et de destination sont celle du ping. Cela est du au fait que AH ne permet pas le tunneling, il faut utiliser ESP:

R1(config)#crypto ipsec transform-set AH_ESP ah-sha-hmac esp-aes
R1(cfg-crypto-trans)#exit
R1(config)#crypto map VPNMAP 1 ipsec-isakmp
R1(config-crypto-map)#set transform-set AH_ESP

A faire aussi sur R2

Capture AH+ESP

Capture AH+ESP

On voit ici que ESP à encapsulé le paquet IP, et que les IP sources sont celles du tunnel.

Voila pour IPSEC Tunnel

GRE Over IPSEC

Penser à enlever la crypto map avant toute configuration

R1(config)#int s1/0
R1(config-if)#no crypto map VPNMAP

Création de l’interface tunnel:

R1(config)#interface tunnel 0
R1(config-if)#tunnel source S1/0
R1(config-if)#tunnel destination 80.0.0.2
R1(config-if)#ip address 192.168.0.1 255.255.255.252

Faire pareil sur R2 en changeant la destination et l’adresse ip (je vais utiliser 192.168.0.2 /30

Modifier EIGRP pour avoir les route passant par le tunnel:

!avant
R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     80.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       80.0.0.0/24 is directly connected, Serial1/0
D       80.0.0.0/8 is a summary, 01:11:47, Null0
     192.168.0.0/30 is subnetted, 1 subnets
C       192.168.0.0 is directly connected, Tunnel0
C    192.168.1.0/24 is directly connected, Loopback1
D    192.168.2.0/24 [90/2297856] via 80.0.0.2, 01:08:04, Serial1/0

Modification (à faire également sur R2)

R1(config)#router eigrp 65000
R1(config-router)#no network 80.0.0.0 0.0.0.255
!*Mar  1 01:25:49.679: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65000: Neighbor 80.0.0.2 (Serial1/0) is down: interface downw
R1(config-router)#network 192.168.0.0 0.0.0.3
R1(config-router)#exit

Après:

*Mar  1 01:27:08.151: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65000: Neighbor 192.168.0.2 (Tunnel0) is up: new adjacency
R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     80.0.0.0/24 is subnetted, 1 subnets
C       80.0.0.0 is directly connected, Serial1/0
     192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.0.0/30 is directly connected, Tunnel0
D       192.168.0.0/24 is a summary, 00:01:56, Null0
C    192.168.1.0/24 is directly connected, Loopback1
D    192.168.2.0/24 [90/297372416] via 192.168.0.2, 00:00:45, Tunnel0
R1#

Capture d’un ping:

Capture d'un ping avec GRE

Capture d'un ping avec GRE

On a bien 2 entêtes IP. Créons un tunnel IPSec avec les mêmes commandes (l’access list fera un match sur le protocole gre, étant donné que les paquets seront encapsulés par GRE avant d’ête envoyés dans IPSEC).

R1(config)#ip access-list extended VPNGRE
R1(config-ext-nacl)#permit GRE any any
R1(config-ext-nacl)#exit
R1(config)#crypto map VPNMAPGRE 1 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
        and a valid access list have been configured.
R1(config-crypto-map)#set peer 80.0.0.2
!transform set créé précédement
R1(config-crypto-map)#set transform-set AH_ESP
R1(config-crypto-map)#match address VPNGRE
R1(config-crypto-map)#exit
R1(config)#int S1/0
R1(config-if)#crypto map VPNMAPGRE
R1(config-if)#exit
R1(config)#

Maintenant, je vais faire une capture du ping avec ip sec en mode tunnel, et en mode transport. Pour passer en mode transport, taper ces commandes sur R1 et R2:

Enter configuration commands, one per line. End with CNTL/Z.

R1(config)#crypto ipsec transform-set AH_ESP ah-sha-hmac esp-aes
R1(cfg-crypto-trans)#mode transport
R1(cfg-crypto-trans)#^Z
R1#clear crypto sa

Mon ping fonctionne toujours

GRE ESP Mode tunnel

GRE ESP Mode tunnel

GRE ESP Mode transport

GRE ESP Mode transport

Evidemment, on ne peut vérifier s’il y a 1 ou 2 entêtes IP dans le payload, étant donné qu’il est chiffré par ESP.

Conclusion:

J’espère que la configuration de tunnels VPN site to site avec IPSEC est maintenant un jeu d’enfant. Une petite remarque cepandant, si avec le tunnel ip sec j’avais mis un permit ip any any pour le match, il aurait fallu que je déclares des neighbor unicast à EIGRP, IPSEC ne gérant pas le multicast.

Un petit lien aussi (en anglais) pour faire des tunnels VPN sans crypto map, si vous n’aimez pas ça:

http://www.ciscoblog.com/archives/2006/08/vpn_virtual_tun.html

Un article ou sont expliqué les différences entre le mode GREoIPSEC et IPSEC tunnel avec des schémas:

http://www.nil.si/ipcorner/IPsecVPN2/ (cliquer sur full article en bas à droite)

Recent Entries

« Attribution d’adresses via PPP/IPCP avec un pool DHCP
ISAKMP Pre-shared key par défaut »

This entry was posted on Vendredi, janvier 16th, 2009 at 17:44 and is filed under CCSP, IINS (ccna security), Réseau Avancé, Sécurité réseau, SNRS. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

19 Responses to “IPSec Tunnel mode VS GRE over IPSEC (GREoIPSEC)”

  1. julito Says:
    avril 22nd, 2009 at 19:18

    Bonjour,

    Je viens de tomber sur ton blog qui est très intéressant.

    J’essaye en ce moment de mettre en place un tunnel IPSec IPv4 encapsulant de l’IPv6. A la lecture de ton article, la solution d’un tunnel GREoIPSEC serait peut-être celle adaptée car je n’arrive pas à le mettre en place d’une autre façon. Aurais-tu une idée?

    Par contre tu dis : « Cela est du au fait que AH ne permet pas le tunneling », je ne suis pas d’accord, j’arrive bien à faire du tunneling avec AH uniquement.

    Merci beaucoup et bonne continuation pour ton blog.

  2. Bastien Migette Says:
    avril 22nd, 2009 at 20:03

    Salut, que veux tu faire ? Protéger de l’IPv6 ? Dans ce cas tu peux utiliser IPSec pour IPv6 directement, si tu veux faire transiter de l’IPv6 dans de l’IPv4 de manière sécurisée, à ce moment, soit tu fait un tunnel IPv4 que tu peux chiffrer, ces genre de tunnels sont appelés 6to4, mais je pourrais te dire comment ça marche avec IPSec… Sinon, AH ne fait pas de tunneling, lorsque tu n’utilises que AH, tu utilises GRE pour le tunneling, c’est pour ça que lorsque l’on utilise ESP avec GRE, il faut mettre mode transport dans le transform set sous peine de créer des en têtes supplémentaires (cela fonctionne mais est inutile, cela revient à avoir un tunnel dans un tunnel…).
    Jettes un coup d’oeil la dessus cela pourra t’aider:
    http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-tunnel.html#wp1055623

  3. julito Says:
    avril 23rd, 2009 at 9:55

    Merci pour ta réponse rapide!
    Ce que je cherche à faire est bien de faire transiter de l’IPv6 dans de l’IPv4 de manière sécurisé, par contre sans utiliser un tunnel automatique de type 6to4 mais un simple tunnel statique ipv6ip. Il doit bien y avoir un moyen de faire ça mais je ne trouve nul par l’information. Protéger en mode transport un tunnel ipv6ip devrait pourtant convenir.

    Je vais continuer à chercher!

  4. julito Says:
    avril 23rd, 2009 at 15:07

    J’ai effectivement réussi à faire ce que je voulais en passant par un tunnel gre pour encapsuler l’ipv6 (en fait le problème réside à matcher l’ipv6 dans une access-list ipv4…)

    Une dernière question qui m’embète et à laquelle je ne trouve pas vraiment de réponse malgrès les docs cisco :
    Quel est la différence entre appliquer une crypto map sur une interface physique et appliquer un profile IPsec sur une interface tunnel via la commande tunnel protection ipsec profile ?

  5. Bastien Migette Says:
    avril 23rd, 2009 at 15:33

    Salut, déjà tu peux faire des access list pour ipv6, la commande est, je crois, ipv6 access-list …
    Tu peux peut être faire un match d’acl IPv6 non ?
    Sinon, les crypto map permettent de ne chiffrer que certains type de trafic, que ça soit du trafic d’un tunnel ou non, tandis que la commande tunnel protection encrypte tout ce qui passe par le tunnel.
    PS: si tu arrives à faire ce que tu veux, n’hésite pas à mettre un petit exemple en commentaire ça peut intéresser d’autres personnes ;)

  6. julito Says:
    avril 24th, 2009 at 10:35

    Effectivement on peut faire des access-lists en IPv6 sans aucun problème. Cependant la commande match address dans la crypto map reçoit apparemment uniquement des access-list ipv4…
    La seule documentation cisco pour faire de l’ipsec sur ipv6 est celle-ci : http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-ipsec.html#wp1083106 et la configuration s’applique uniquement sur le tunnel et pas sur une interface physique.

    Merci pour la précision entre crypto map et tunnel protection ipsec, c’est logique au final!

  7. doudou Says:
    juillet 12th, 2009 at 17:39

    Salut, merci pour ton article qui est tres interessant, en ce moment j’essaie de configurer GREoIPSEC en utilisant les signatures rsa mais je n’arrive pas à mettre en place le serveur de certificats mscep sous w2k. J »attends votre aide avec impatience.

    laffdoudou@hotmail.fr

  8. Bastien Migette Says:
    juillet 12th, 2009 at 23:59

    salut, l’installation du CA avec SCEP est détaillée mon article sur le DMVPN:
    http://bmigette.fr/2009/02/08/dmvpn-certificats/

  9. doudou Says:
    juillet 13th, 2009 at 10:55

    j’ai deja visité cette page mais le lien http://micronetsolution.net/Microsoft_CA_Cisco_setup.pdf ne fonctionne pas.

  10. Bastien Migette Says:
    juillet 13th, 2009 at 11:05

    effectivement, le lien est HS, mais j’ai résumé le tutorial dans l’étape 1. En gros, activer IIS, le supports des certificats, et installer l’addon MSCEP du site de MS.

  11. doudou Says:
    juillet 13th, 2009 at 16:57

    j’aimerai savir si est ce que le serveur de certificats peut se trouver au niveau du HUB.

  12. jimmy Says:
    avril 22nd, 2010 at 14:14

    hello
    tp réalisé au top avec mes stagiaires !!
    je me demande juste comment peut on au travers un tunnel récupérer une adresse ip en automatique en ayant le dhcp sur le site distant sans avoir une deuxième étendue (tp que j’ai également réalisé et qui fonctionne) . je sais que les deux sites doivent être dans des lan privés différents mais pourtant, j’ai déjà utilisé des vpn qui m’attribuent une ip dans l’étendue du meme site distant , comment celà peut il être possible dans la mesure où le routeur doit router la meme classe d’adresse sur des interfaces différents ??
    je reste perplexe et je cherche en vain la réponse depuis des jours ….
    merci

  13. Bastien Migette Says:
    mai 6th, 2010 at 9:07

    tu peux mettre sur un des sites un ip helper address pour qu’il transmette les requête DHCP à travers ton tunnel, par contre, avoir le même adressage des 2 coté risque de te poser des problèmes de routage

  14. Koop Says:
    novembre 18th, 2011 at 10:56

    Pourquoi ne pas préciser « tunnel mode gre ipv4″ sur l’interface tunnel ?
    Par défaut on a « tunnel mode ipsec ipv4″ il me semble..

  15. Bastien Migette Says:
    novembre 22nd, 2011 at 0:16

    Salut,
    Cela dépend peut être des versions, mais en général c’est du GRE par défaut:
    R1#sh int tun0 | i Tunnel proto
    Tunnel protocol/transport GRE/IP
    R1#sh run int tun 0
    Building configuration…

    Current configuration : 40 bytes
    !
    interface Tunnel0
    no ip address
    end

    On le voit par ailleurs sur la capture, il y a une en tête GRE.

  16. Usherth Says:
    décembre 28th, 2011 at 16:55

    Merci mon frère pour ton site qui est très intéressant. J’ai une préoccupation majeure, c’est celle dont j’ai deux sites distants, le premier étant le central a un routeur cisco 2911 et le site client, un 2801. J’aimerais faire du cryptage IPSEC, GRE TUNNEL entre le deux sites. Il se pose un problème, au niveau du routeur 2801, ce dernier accepte la commande crypto isakmap et non le crypto pki et c’est le sens inverse au routeur 2911 or j’ai tentais à plusieurs reprises de taper la commande crypto isakmp enable au niveau de 2911 mais en vain, que faudrait-il alors faire pour pouvoir établir un tunnel entre ces deux sites???, please!!!

  17. Bastien Migette Says:
    janvier 7th, 2012 at 13:11

    Bonjour Usherth.

    Le 2911 est un ISR G2, aussi, sur cette génération, les « features » s’activent via des licenses… Le votre n’a probablement pas la license IPSEC.

  18. killer73 Says:
    février 15th, 2012 at 1:08

    Bonsoir,

    Alors voila je vous expose mon problème. J’ai actuellement un réseau de 3 routeurs :

    http://imageshack.us/photo/my-images/15/sanstitreqsm.jpg/

    J’émule donc ces 3 routeurs sous GNS3 (même si la photo provient de PacketTracer). Je commence par réaliser mon premier tunnel Gre over IPSEC sur mon lien serial, j’effectue ensuite le routage avec le protocole EIGRP. Tout fonctionne très bien. En revanche, lorsque je veux réaliser mon tunnel entre mon routeur en haut à gauche et mon routeur en bas, qui sont reliés avec un câble FastEthernet, les soucis arrivent. En effet, dès que je met le protocole EIGRP en place, j’obtiens sans arrêt des messages UP et DOWN sur mon tunnel (du type « retry limit excedeed »). C’est un vrai problème car mon réseau, de ce fait, ne cesse de se couper !

    Merci d’avance !

  19. Bastien Migette Says:
    mars 2nd, 2012 at 20:47

    Salut,

    Ce cas est typique d’un EIGRP Qui avertie des réseau publics…
    En gros, tes IPs publiques qui sont les extrémités du tunnels vont êtres routées par le tunnels, et donc cela n’a pas de sens, le tunnel vas tomber… Je peux me tromper mais le résultat est typiquement un tunnel qui flap ;)

Leave a Reply