IPsec Tools – BranchOffice

Introduction

Dans cette section, nous verrons la configuration de Racoon et plus généralement des IPsec-tools pour arriver à une connexion BranchOffice entre deux sites distants.

 

Préliminaires

Pour une configuration en BranchOffice, il n’y a que peu de prérequis. Il suffira d’installer ipsec-tools et racoon.

Vérifiez bien que vous remplissez les conditions énoncées dans la page Dépendances Noyau si vous êtes sous Linux.

Pour finir, il nous faudra une paire clef/certificat pour chaque gateway. Pour cela, vous pouvez vous reporter aux documentations Création de l’autorité de certification et Création d’un certificat avec le CA pour générer des certificats signés par soi-même.

Pour FreeBSD 6.2, Il y a une petite chose à faire pour avoir le support du NAT traversal. Il faut mettre à patch au noyau avant de le compiler.

Il se récupère à l’adresse suivante: http://ipsec-tools.sourceforge.net/freebsd6-natt.diff

Puis on l’applique en se mettant dans le répertoire /usr/src/sys avec la commande patch et on recompile son noyau.

Promis un de ces jours, je ferais une doc sur la compilation noyau sur FreeBSD.

Description réseau

Dans notre cas, nous allons considérer que nous avons 2 machines reliées à Internet avec une IP publique et chacune de ces machines a son réseau privé derrière.

Ce qui nous donne quelque chose de la forme:

   ---------------- 192.168.0.0/24
         |
         | 192.168.0.254
      Gateway A
         | 1.2.3.4
         |
        ***
        *** Internet
        ***
         |
         | 5.6.7.8
      Gateway B
         | 192.168.1.254
         |
   ---------------- 192.168.1.0/24

 

Gateway A

Sur la Gateway A, nous allons devoir lui dire que pour joindre le réseau 192.168.1.0/24, elle va devoir établir une connexion IPsec avec l’IP publique (5.6.7.8) de la Gateway B.

Pour cela, nous allons configurer Racoon et IPsec-tools. Les fichiers de configuration assez bien commentés sont juste en dessous.

Fichier /etc/ipsec-tools.conf:

#!/usr/sbin/setkey -f
#
# Script pour les configs IPsec

## flush
flush ;
spdflush ;


# Création des politiques

# Pour aller au réseau 192.168.1.0/24 en venant du 192.168.0.0/24
# Il faut utiliser le tunnel qui va de 1.2.3.4 vers 5.6.7.8
spdadd 192.168.0.0/24 192.168.1.0/24 any -P out ipsec
        esp/tunnel/1.2.3.4-5.6.7.8/require ;

# Inversement dans l'autre sens !
# Vous noterez "in" au lieu du "out" après le "-P"
spdadd 192.168.1.0/24 192.168.0.0/24 any -P in ipsec
        esp/tunnel/5.6.7.8-1.2.3.4/require ;

Techniquement, la deuxième « règle » sert à dire que pour les paquets dans l’autre sens, ils doivent aussi emprunter un tunnel IPsec qui va de la gateway B à la gateway A.

Fichier /etc/racoon/racoon.conf:

# Répertoire où sont stockés les certificats
path certificate "/etc/racoon/certs";

# Les IP sur lesquelles Racoon écoute
listen {
        isakmp 1.2.3.4 [500];
}

# Définition d'un noeud distant
# On sait que cette connexion s'établie avec 5.6.7.8 
# qui est l'adresse IP publique de la gateway B
remote 5.6.7.8 {
        # Définition du mode pour la phase 1
        exchange_mode main;
        # Durée de vie de la phase 1
        lifetime time 12 hour;
        # La facon de s'identifier. Racoon prendra le ASN.1 distinguished name dans le certificat
        my_identifier asn1dn;
        # La facon d'identifier l'hôte distant. Comme pour l'identifier local
        peers_identifier asn1dn;
        # le certificat et sa clef associée que l'on a généré pour notre gateway A
        certificate_type x509 "gateA_cert.pem" "gateA_key.pem";
        # Le certificat de la gateway B pour pouvoir l'authentifier
        # A copier de facon sécuriser !!!
        peers_certfile x509 "gateB_cert.pem";
        # Proposition pour l'encryption et l'authentification
        proposal {
                # Encryptage en AES
                encryption_algorithm aes;
                # hashage en SHA1
                hash_algorithm sha1;
                # le type d'authentification
                authentication_method rsasig;
                # le groupe Diffie-Hellman utilisé
                dh_group 5;
        }
}

# Spécifications du SA pour aller au réseau 192.168.1.0/24
# qui est derrière la gateway B
sainfo address 192.168.0.0/24 any address 192.168.1.0/24 any {
        # le groupe Diffie-Hellman utilisé
        pfs_group 5;
        # Durée de vie de la phase 2
        lifetime time 6 hour;
        # Encryption en AES
        encryption_algorithm aes;
        # Authentification par SHA1
        authentication_algorithm hmac_sha1;
        # Compression activée
        compression_algorithm deflate;
}

Avec tout cela notre gateway A devrait fonctionner.

Attention aux droits sur le répertoire /etc/racoon/certs et sur les fichiers qui sont dedans. Si les droits sont trop larges, Racoon ne démarrera pas !

Il ne reste plus qu’à redémarrer les services. Sur notre Debian:

# /etc/init.d/setkey restart
# /etc/init.d/racoon restart

 

Gateway B

Sur la Gateway B, nous allons devoir lui dire que pour aller joindre le réseau 192.168.0.0/24, elle va devoir établir une connexion IPsec avec l’IP publique (1.2.3.4) de la Gateway A.

Pour cela, nous allons aussi bien évidement configurer Racoon et IPsec-tools. Les fichiers de configuration assez bien commentés sont juste en dessous.

Fichier /etc/ipsec-tools.conf:

#!/usr/sbin/setkey -f
#
# Script pour les configs IPsec

## flush
flush ;
spdflush ;


# Création des politiques

# Pour aller au réseau 192.168.0.0/24 en venant du 192.168.1.0/24
# Il faut utiliser le tunnel qui va de 5.6.7.8 vers 1.2.3.4
spdadd 192.168.1.0/24 192.168.0.0/24 any -P out ipsec
        esp/tunnel/5.6.7.8-1.2.3.4/require ;

# Inversement dans l'autre sens !
# Vous noterez "in" au lieu du "out" après le "-P"
spdadd 192.168.0.0/24 192.168.1.0/24 any -P in ipsec
        esp/tunnel/1.2.3.4-5.6.7.8/require ;

Idem que tout à l’heure, il faut la règle pour les paquets qui vont dans l’autre sens.

Fichier /etc/racoon/racoon.conf:

# Répertoire où sont stockés les certificats
path certificate "/etc/racoon/certs";

# Les IP sur lesquelles Racoon écoute
listen {
        isakmp 5.6.7.8 [500];
}

# Définition d'un noeud distant
# On sait que cette connexion s'établie avec 1.2.3.4
# qui est l'adresse IP publique de la gateway B
remote 1.2.3.4 {
        # Définition du mode pour la phase 1
        exchange_mode main;
        # Durée de vie de la phase 1
        lifetime time 12 hour;
        # La facon de s'identifier. Racoon prendra le ASN.1 distinguished name dans le certificat
        my_identifier asn1dn;
        # La facon d'identifier l'hôte distant. Comme pour l'identifier local
        peers_identifier asn1dn;
        # le certificat et sa clef associée que l'on a généré pour notre gateway A
        certificate_type x509 "gateB_cert.pem" "gateB_key.pem";
        # Le certificat de la gateway B pour pouvoir l'authentifier
        # A copier de facon sécuriser !!!
        peers_certfile x509 "gateA_cert.pem";
        # Proposition pour l'encryption et l'authentification
        proposal {
                # Encryptage en AES
                encryption_algorithm aes;
                # hashage en SHA1
                hash_algorithm sha1;
                # le type d'authentification
                authentication_method rsasig;
                # le groupe Diffie-Hellman utilisé
                dh_group 5;
        }
}

# Spécifications du SA pour aller au réseau 192.168.0.0/24
# qui est derrière la gateway A
sainfo address 192.168.1.0/24 any address 192.168.2.0/24 any {
        # le groupe Diffie-Hellman utilisé
        pfs_group 5;
        # Durée de vie de la phase 2
        lifetime time 6 hour;
        # Encryption en AES
        encryption_algorithm aes;
        # Authentification par SHA1
        authentication_algorithm hmac_sha1;
        # Compression activée
        compression_algorithm deflate;
}

Avec tout cela notre gateway B devrait fonctionner.

Encore une fois, attention aux droits sur le répertoire /etc/racoon/certs et sur les fichiers qui sont dedans.

Il ne reste plus qu’à redémarrer les services. Sur notre Debian:

# /etc/init.d/setkey restart
# /etc/init.d/racoon restart

 

Tests

Après tout cela, notre VPN devrait fonctionner sans soucis. Pour tester, il faut se mettre sur une machine d’un des deux réseaux privés et faire un ping vers une machine du réseau qui est derrière l’autre gatewau.

Le ou les premiers paquets ne passeront peut-être pas le temps que la connexion IPsec s’établisse !

 

Configurations annexes

Elles sont donc annexes mais pas forcement facultatives !!!

Il vous faudra changer la MTU de l’interface à cause de l’encapsulation IPsec. Elle doit être mise à 1400 qui est une valeur avec laquelle cela doit fonctionner correctement.

Si vous vous placez sur la gateway A et que vous faites un ping vers une adresse IP du réseau privé de la gateway B, cela ne répondra pas… car la gateway A prend comme IP source son IP publique qui est « plus proche » du réseau d’en face que son IP privée.

Pour remédier à cela, plusieurs solutions:

  • Définir au niveau de Racoon et ipsec-tools sur les deux gateways des « règles » pour les traffics:
    • de 1.2.3.4 vers 192.168.1.0/24
    • de 5.6.7.8 vers 192.168.0.0/24
    • de 1.2.3.4 vers 5.6.7.8
  • Mettre une route au niveau des gateways pour lui spécifier l’interface et l’IP source à utiliser selon la destination.

J’ai choisi la deuxième solution beaucoup plus simple et tout aussi propre à mon gout.

Pour cela, vous aurez besoin de la commande ip qui se trouve dans le paquet iproute sur une Debian.

Pour placer la route sur la gateway A:

ip route add 192.168.1.0/24 via <gateway A default gateway> src 192.168.0.254 [mtu 1415]

et pour la gateway B:

ip route add 192.168.0.0/24 via <gateway B default gateway> src 192.168.1.254 [mtu 1415]

Vous noterez que grâce à iproute, on peut aussi spécifier la MTU pour une route plutôt que pour l’interface complète.

 

TODO

Valider tout cela sur FreeBSD.

 

Mot de la fin

N’oubliez pas les règles Iptables si jamais les gateways servent aussi de firewalls !!!

il faudra autoriser les traffics suivants:

  • UDP/500
  • AH
  • ESP

D’autres parts, le traitement IPsec est fait, puis les paquets passent dans les règles iptables sur Linux. Donc iptables verra des paquets avec comme ip source 192.168.0.0/24 sur l’interface publique… ce qui pourrait lui paraître étrange…

Il faut donc penser à accepter dans la table nat dans la chaine prerouting sur l’interface externe les paquets ayant comme ip source celle du réseau privé de la gateway d’en face.

A vous de voir les restrictions à mettre en place si vous ne souhaitez pas autoriser tous les traffics venant des réseaux distants !

Les filtrages peuvent être fait à la source ou à l’arrivée dans le mesure où les paquets passent par iptables puis dans le traitement IPsec pour sortir et inversement à l’arrivée.

2 commentaires sur “IPsec Tools – BranchOffice

  1. Bonjour,
    J’essaie de mettre en place une connexion ipsec (esp/tansport/require) et j’ai étudier votre configuration concernant racoon, que j’ai adapté pour faire du host to host entre un RHEL7 et un windows 8.1 néanmoins je suis bloqué.

    Ma connexion tourne en boucle sur ce point :
    « INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
    INFO: received Vendor ID: FRAGMENTATION
    DEBUG: received unknown Vendor ID
    ERROR: ignore information because ISAKMP-SAhas not been established yet. »

    A savoir que lorsque je me connecte avec une PKS tout ce passe bien.

    J’ai généré et re-généré des Clés et certificats à ne plus savoir qu’en faire avec openssl.
    (j’ai aussi essayé les instructions des sites http://shebangthedolphins.net/vpn_ipsec_04linux-to-windows_transport-x509.html et http://www.infond.fr/2010/03/basics-9-tutoriel-ipsec.html#comment-form)

    Voila, si vous connaissez un détail important pour le host to host avec windows, ou si vous souhaitez voire mes fichiers de conf / logs n’hésitez pas.

    Cordialement,

    Anthony

    J'aime

    1. Bonjour,

      Je n’ai clairement aucune connaissance avec Windows et encore moins de l’IPsec sous windows et encore encore moins avec windows 8.1.
      Désolé de ne pas pouvoir vous aider.

      Guillaume

      J'aime

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s