[Résolu] Faire un tunnel IPsec avec OpenSwan 2.4.4 + SNAT

Forum sur la sécurité des réseaux, la configuration des firewalls, la mise en place de protections contre les attaques, de DMZ, de systèmes anti-intrusion ...

Modérateur: modos Ixus

[Résolu] Faire un tunnel IPsec avec OpenSwan 2.4.4 + SNAT

Messagepar Geceo » 28 Déc 2006 12:26

Bonjour,

EDITION : si vous êtes intéressé par la solution, elle se trouve ici : http://forums.ixus.fr/viewtopic.php?p=233466#233466

J'essaye depuis plusieurs jours d'établir un VPN entre un routeur sous Ubuntu avec OpenSwan 2.4.4 et un D-Link DI-804HV.

Voici mon fichier "ipsec.conf" :

Code: Tout sélectionner
version 2.0

config setup
        interfaces=%defaultroute
        klipsdebug=all
        plutodebug=all
        plutowait=no

conn mon_vpn
        left=ADRESSE_EXTERNE_ROUTEUR_UBUNTU
        leftid=ADRESSE_EXTERNE_ROUTEUR_UBUNTU
        leftsubnet=192.168.0.0/24
        leftnexthop=%defaultroute
        right=ADRESSE_EXTERNE_ROUTEUR_DLINK
        rightsubnet=100.0.0.0/24
        rightid=ADRESSE_EXTERNE_ROUTEUR_DLINK
        rightnexthop=%defaultroute
        keyexchange=ike
        ikelifetime=240m
        keylife=3600s
        pfs=yes
        compress=no
        authby=secret
        keyingtries=0
        auto=start

#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf


Lorsque je tape "/etc/init.d/ipsec restart", j'obtiens ceci :

Code: Tout sélectionner
root@routeur:~# /etc/init.d/ipsec restart
ipsec_setup: Stopping Openswan IPsec...
ipsec_setup: Starting Openswan IPsec 2.4.4...
ipsec_setup: insmod /lib/modules/2.6.15-27-386/kernel/net/key/af_key.ko
ipsec_setup: insmod /lib/modules/2.6.15-27-386/kernel/net/ipv4/xfrm4_tunnel.ko
ipsec_setup: insmod /lib/modules/2.6.15-27-386/kernel/net/xfrm/xfrm_user.ko


et dans /var/log/messages ceci :

Code: Tout sélectionner
Dec 28 11:05:32 localhost kernel: [17684853.848000] NET: Unregistered protocol family 15
Dec 28 11:05:33 localhost kernel: [17684854.508000] NET: Registered protocol family 15
Dec 28 11:05:33 localhost kernel: [17684854.600000] Initializing IPsec netlink socket


Est-ce que cette erreur de "protocole" suffit à expliquer que le VPN ne s'établit pas?

Merci,
Geceo
Dernière édition par Geceo le 04 Jan 2007 15:47, édité 2 fois au total.
Geceo
Premier-Maître
Premier-Maître
 
Messages: 48
Inscrit le: 07 Juil 2005 10:53

Messagepar Franck78 » 28 Déc 2006 14:32

Salut,
Je ne vois d'erreur signalée :evil:

La commande exacte en version 1 est

#ipsec auto xyz

xyz est un ordre type 'add,up,down,delete,...' appliqué au tunnel choisi (le nom dans le .con.

C'est le log de ceci qu'il faut.

#ipsec barf
sort un rapport complet (ne le publie pas).
Franck
L'art de poser une question sur ce site afin d'obtenir la réponse
A LIRE
Avatar de l’utilisateur
Franck78
Amiral
Amiral
 
Messages: 5625
Inscrit le: 20 Fév 2004 01:00
Localisation: Paris

Messagepar Geceo » 28 Déc 2006 14:55

Ah ok! :oops:

Alors voilà ce que j'obtiens avec la commande "ipsec auto --up mon_vpn" :

Code: Tout sélectionner
021 no connection named "mon_vpn"


Comme s'il n'avait pas lu mon fichier ipsec.conf!

Même si j'indique l'option --config /etc/ipsec.conf j'obtiens la même erreur. J'ai vu sur Google que je n'étais pas le premier à avoir ce problème mais chez moi il ne s'agit pas d'un problème d'indentation du fichier "ipsec.conf". J'ai bien mis des tabulations en-dessous des lignes "config setup" et "conn mon_vpn" (au passage, je ne comprends pas qu'il y ait encore sur Terre des gens qui font des fichiers de configuration qui ne sont pas du XML, mais bon, c'est un autre débat).

EDITION : en lisant le rapport que m'a sorti "ipsec barf", je vois ceci :

Code: Tout sélectionner
localhost ipsec__plutorun: ipsec_auto: fatal error in "mon_vpn": %defaultroute requested but not known


Comment corriger ce problème?

Geceo
Geceo
Premier-Maître
Premier-Maître
 
Messages: 48
Inscrit le: 07 Juil 2005 10:53

Messagepar Geceo » 28 Déc 2006 15:06

Bon en virant la ligne qui commence par "interfaces=" j'arrive un peu plus loin.

Apparemment une commande indispensable est "ipsec setup restart" qu'il faut taper avant "ipsec barf".

Les erreurs que j'obtiens maintenant sont du genre :
Code: Tout sélectionner
sendto on eth0 to IP_ROUTEUR_DLINK:500 failed in EVENT_RETRANSMIT. Errno 1: Operation not permitted


D'où vient cette erreur?
Geceo
Premier-Maître
Premier-Maître
 
Messages: 48
Inscrit le: 07 Juil 2005 10:53

Messagepar Geceo » 28 Déc 2006 18:00

Bon j'ai encore avancé : je laisse passer le port UDP 500 dans mes règles NetFilter, ainsi que le protocol IP n°50. Ça résoud l'erreur mentionné précédemment. Pour information, ça donne ça :

Code: Tout sélectionner
# On ouvre le port UDP 500 qui est utilise par IKE pour le VPN
iptables --append INPUT --source $ADRESSE_EXTERNE_ROUTEUR_DISTANT --protocol udp --sport 500 --dport 500 --jump ACCEPT
iptables --append OUTPUT --destination $ADRESSE_EXTERNE_ROUTEUR_DISTANT --protocol udp --sport 500 --dport 500 --jump ACCEPT

# On autorise aussi le protocole IP 50 (ESP) pour le VPN
iptables --append INPUT --protocol 50 --source $ADRESSE_EXTERNE_ROUTEUR_DISTANT --jump ACCEPT
iptables --append OUTPUT --protocol 50 --destination $ADRESSE_EXTERNE_ROUTEUR_DISTANT --jump ACCEPT


J'ai aussi mis les adresses externes des deux bouts du tunnel dans le fichier /etc/ipsec.secrets ainsi que la chaîne qui fait office de secret partagé. Ce n'est pas ce qu'on fait de plus sûr, je sais, mais le routeur distant (DLink) ne propose rien d'autre.

Voici où j'en suis :
Code: Tout sélectionner
root@routeur:~# ipsec auto --up mon_vpn
117 "mon_vpn" #3: STATE_QUICK_I1: initiate
004 "mon_vpn" #3: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x78000010 <0xf1ccd631 xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}
root@routeur:~#


Il semblerait que ça soit bon car j'ai bien le message "IPsec SA established", mais pourtant "ping 100.0.0.1" ne renvoie rien. Est-ce que le problème vient du pare-feu? Pourtant j'arrive à faire un ping sur l'adresse externe du routeur distant.

Geceo
Geceo
Premier-Maître
Premier-Maître
 
Messages: 48
Inscrit le: 07 Juil 2005 10:53

Messagepar Geceo » 29 Déc 2006 17:32

Bonjour,

Je résume la situation :
- sur le premier site, j'ai un routeur Ubuntu en frontal sur Internet (on va dire que son adresse publique est 212.0.0.78), qui sert de passerelle à un réseau privé 192.168.0.0/24. La route par défaut est le routeur 212.0.0.77 qui est situé sur Internet et qui laisse tout passer.
- sur le deuxième site, j'ai un routeur D-Link DI-804HV en frontal sur Internet (on va dire que son adresse publique est 212.0.0.14), qui sert de passerelle à un réseau privé 100.0.0.0/24. La route par défaut est le routeur 212.0.0.13, là encore qui laisse tout passer.

J'arrive à faire un ping de chaque routeur à partir de l'autre routeur, en utilisant les adresses publiques 212.0.0.78 et 212.0.0.14. Les machines des deux réseaux privés peuvent accéder à Internet.

Ensuite viennent mes problèmes de VPN. Voici le fichier "ipsec.conf" que j'ai sur le routeur Ubuntu :

Code: Tout sélectionner
version 2.0

config setup
        # plutodebug / klipsdebug = "all", "none" or a combation from below:
        # "raw crypt parsing emitting control klips pfkey natt x509 private"
        # eg:
        # plutodebug="control parsing"
        #
        # Only enable klipsdebug=all if you are a developer
        #
        # NAT-TRAVERSAL support, see README.NAT-Traversal
        #nat_traversal=yes
        #virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%4:172.16.0.0/12
        #interfaces=%defaultroute
        #klipsdebug=all
        #plutodebug=all
        plutowait=no

# Add connections here

# sample VPN connection
conn mon_vpn
        left=212.0.0.78
        leftid=212.0.0.78
        leftnexthop=212.0.0.77
        leftsubnet=192.168.0.0/24
        right=212.0.0.14
        rightid=212.0.0.14
        rightnexthop=212.0.0.13
        rightsubnet=100.0.0.0/24
        keyexchange=ike
        ikelifetime=240m
        keylife=3600s
        pfs=yes
        compress=no
        authby=secret
        keyingtries=0
        auto=start

#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf


Actuellement la négociation des clés (IKE) fonctionne. Pourtant je n'arrive pas à pinguer, comme s'il y avait un problème de routage.

Questions :
# Voyez-vous des incohérences entre la description du réseau et le contenu du fichier ipsec.conf? En particulier sur les valeurs de "leftnexthop" et de "rightnexthop" : est-il vraiment nécessaire de parler des routeurs 212.0.0.77 et 212.0.0.13? À partir du moment où la route par défaut pointe déjà sur ces routeurs, pourquoi est-il nécessaire de les indiquer dans ipsec.conf ? C'est un truc que je n'arrive pas à comprendre! Mais si je ne les mets pas, "ping 100.0.0.100" me dit :
Code: Tout sélectionner
PING 100.0.0.100 (100.0.0.100) 56(84) bytes of data.
From 212.0.0.78 icmp_seq=1 Destination Host Unreachable
From 212.0.0.78 icmp_seq=2 Destination Host Unreachable
From 212.0.0.78 icmp_seq=3 Destination Host Unreachable

--- 100.0.0.100 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4017ms
, pipe 3


Je retourne le problème dans tous les sens depuis hier et je ne vois vraiment pas!...

Geceo
Geceo
Premier-Maître
Premier-Maître
 
Messages: 48
Inscrit le: 07 Juil 2005 10:53

Messagepar Franck78 » 29 Déc 2006 18:20

Actuellement la négociation des clés (IKE) fonctionne. Pourtant je n'arrive pas à pinguer, comme s'il y avait un problème de routage.


Donc pour l'IPSec c'est ok (ipsec sa establish).

Comme tu as viré "interfaces=%defaultroute" qui te généait, je pense que tu as effectivement un vrai problème de config IP sur cette machine...
La première commande pour traquer ça est bienb sur

#route :!:

A titre d'exemple:

Code: Tout sélectionner
root@thewall:~ # route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
1.1.1.1         *               255.255.255.255 UH    0      0        0 ppp0
1.1.1.1         *               255.255.255.255 UH    0      0        0 ipsec0
127.11.1.0      *               255.255.255.0   U     0      0        0 eth1
10.0.0.0        *               255.255.0.0     U     0      0        0 eth0
10.44.0.0       1.1.1.1         255.255.0.0     UG    0      0        0 ipsec0
default         1.1.1.1         0.0.0.0         UG    0      0        0 ppp0
root@thewall:~ #


Le 1.1.1.1 est une aberration neuftélécom. Ce qu'il faut noter, c'est la route par ipsec0 pour atteindre le réseau 10.44.0.0/16
Franck
L'art de poser une question sur ce site afin d'obtenir la réponse
A LIRE
Avatar de l’utilisateur
Franck78
Amiral
Amiral
 
Messages: 5625
Inscrit le: 20 Fév 2004 01:00
Localisation: Paris

Messagepar Geceo » 29 Déc 2006 18:46

Salut Franck78,

Merci de te pencher sur mon problème! La table de routage vaut ceci :

Code: Tout sélectionner
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
212.0.0.76      *               255.255.255.252 U     0      0        0 eth0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth1
100.0.0.0       212.0.0.77      255.255.255.0   UG    0      0        0 eth0
default         212.0.0.77      0.0.0.0         UG    0      0        0 eth0


Comme tu peux le constater, je n'ai pas d'interface ipsec0. J'ai cru comprendre que c'était normal avec les noyaux 2.6. Utilises-tu un noyau 2.4.x ?

Merci,
Geceo

AJOUT : lorsque je supprime les lignes "leftnexthop=" et "rightnexthop=", "route" me renvoie ceci :

Code: Tout sélectionner
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
212.0.0.76      *               255.255.255.252 U     0      0        0 eth0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth1
100.0.0.0       *               255.255.255.0   UG    0      0        0 eth0
default         212.0.0.77      0.0.0.0         UG    0      0        0 eth0


La seule différence avec ci-dessus, c'est que la route pour mon réseau privé distant n'est plus explicitement 212.0.0.77, elle l'est implicitement. En fait y'a rien qui indique que les paquets pour le réseau 100.0.0.0/24 doivent passer par le tunnel! :evil:
Geceo
Premier-Maître
Premier-Maître
 
Messages: 48
Inscrit le: 07 Juil 2005 10:53

Messagepar Franck78 » 30 Déc 2006 14:42

Je suis effectivement en 2.4 (IPCop).

Puisque ta machine est un routeur, elle possède au moins deux cartes réseaux, eth0 et eth1. Il ne reste donc aucune interface déclarée pour ipsec (cela eut pu être eth1...).

Je pense que cela vient de l'absence de la ligne "interface=..." dans ipsec.conf

Elle devrait au moins être acceptée avec %defaultroute; sinon cela indique que ta config IP n'est elle même pas bonne. Pas de route par défaut trouvée.

Il y a plusieurs syntaxes faciles à trouver avec google.

Laisse leftnexthop rightnexthop vides pour commencer.
Franck
L'art de poser une question sur ce site afin d'obtenir la réponse
A LIRE
Avatar de l’utilisateur
Franck78
Amiral
Amiral
 
Messages: 5625
Inscrit le: 20 Fév 2004 01:00
Localisation: Paris

Messagepar Geceo » 30 Déc 2006 16:54

Salut!

J'ai ajouté la ligne "interfaces=%defaultroute" mais ça ne change rien. Par contre, j'ai observé une différence de comportement :

1) Dans le cas où je n'indique pas les "next hops", la commande "ipsec auto --status" montre la situation suivante :
Code: Tout sélectionner
000 "mon_vpn": 192.168.0.0/24===212.0.0.78...212.0.0.14===100.0.0.0/24; erouted; eroute owner: #4


Dans ce cas, un ping sur une adresse en 100.0.0.100 me donne un "Destination Host Unreachable" pour tous les paquets.

2) Quand je mets "leftnexthop=%defaultroute" et "rightnexthop=212.0.0.13", "ipsec auto --status" me donne le chemin suivant :
Code: Tout sélectionner
000 "mon_vpn": 192.168.0.0/24===212.0.0.78---212.0.0.77...212.0.0.13---212.0.0.14===100.0.0.0/24; erouted; eroute owner: #3


Dans cette configuration, "ping 100.0.0.100" conduit à 100% de paquets perdus.

Donc l'erreur renvoyée n'est pas la même. Qu'est-ce qui est le mieux, des paquets perdus ou un hôte inaccessible!?

Merci,
Geceo
Geceo
Premier-Maître
Premier-Maître
 
Messages: 48
Inscrit le: 07 Juil 2005 10:53

Messagepar Franck78 » 30 Déc 2006 18:34

Geceo a écrit:
Donc l'erreur renvoyée n'est pas la même. Qu'est-ce qui est le mieux, des paquets perdus ou un hôte inaccessible!?


ben aucune :!:

Ou as-tu vu qu'il n'y avait plus de 'ipsec0'....? Je suis étonné. Tu ne réponds pas aux questions :evil: eth0 et eth1 sont ?
Franck
L'art de poser une question sur ce site afin d'obtenir la réponse
A LIRE
Avatar de l’utilisateur
Franck78
Amiral
Amiral
 
Messages: 5625
Inscrit le: 20 Fév 2004 01:00
Localisation: Paris

Messagepar Geceo » 30 Déc 2006 19:17

Salut,

Concernant l'interface ipsec0, elle n'existe pas avec le noyau 2.6 car le 2.6 dispose de sa propre pile IPsec, alors que les noyaux 2.4 utilisaient KLIPS. Là je répète ce que j'ai lu à plusieurs endroits. Par exemple ici :
http://lists.opensuse.org/opensuse/2004 ... 03740.html
ou là :
http://lists.openswan.org/pipermail/use ... 05415.html
Cherche "ipsec0 kernel 2.6" et tu verras.

Je n'ai pas compris ce que tu voulais savoir sur eth0 et eth1. eth0 a pour adresse 212.0.0.78 et eth1 a pour adresse 192.168.0.1. Je ne vois pas quoi dire d'autre.

Merci,
Geceo
Geceo
Premier-Maître
Premier-Maître
 
Messages: 48
Inscrit le: 07 Juil 2005 10:53

Messagepar Franck78 » 30 Déc 2006 20:11

Alors je vois pas comment ca marche sans interface dédiée au tunnel !
Faut que j'aille étudier la chose ;-)
Franck
L'art de poser une question sur ce site afin d'obtenir la réponse
A LIRE
Avatar de l’utilisateur
Franck78
Amiral
Amiral
 
Messages: 5625
Inscrit le: 20 Fév 2004 01:00
Localisation: Paris

Messagepar Geceo » 30 Déc 2006 22:03

D'après ce document, la configuration "kernel 2.6 avec IPsec intégré, donc sans interfaces virtuelles "ipsecX"" n'est pas compatible avec le SNAT/DNAT :

http://www.xelerance.com/talks/linuxtag ... nLinux.pdf

En même temps j'ai pas trop compris ce document et il date de 2004... :?

Geceo
Geceo
Premier-Maître
Premier-Maître
 
Messages: 48
Inscrit le: 07 Juil 2005 10:53

Messagepar Geceo » 04 Jan 2007 15:42

Bonjour!

J'ai résolu le problème! :D La solution est la suivante :

- quand on veut avoir sur une seule machine avec un noyau 2.6.x les deux fonctions "point d'entrée d'un tunnel IPsec" et "masquage de réseau privé" (règles iptables "SNAT" et "DNAT" ou bien "MASQUERADE"), il faut impérativement utiliser au moins un noyau 2.6.16 et la version 1.3.5 de "NetFilter/iptables" : j'ai donc mis à jour Ubuntu 6.06 (noyau 2.6.15) vers la version 6.10 qui est fournie avec un noyau 2.6.17 et iptables 1.3.5;

- pour que l'explication qui suit soit plus claire, je redonne la topologie du réseau (elle apparaît avec la commande "ipsec auto --status"):
Code: Tout sélectionner
192.168.0.0/24===212.0.0.78...212.0.0.14===100.0.0.0/24

La machine que je veux configurer est celle de gauche, d'adresse IP publique valant 212.0.0.78 et d'adresse IP privée 192.168.0.1.

- voici le fichier "/etc/ipsec.conf" que j'utilise :
Code: Tout sélectionner
version 2.0
config setup
        nat_traversal=no
        interfaces=%defaultroute
        plutowait=no
conn mon_vpn
        left=212.0.0.78
        leftsourceip=192.168.0.1
        leftsubnet=192.168.0.0/24
        right=212.0.0.14
        rightsourceip=100.0.0.1
        rightsubnet=100.0.0.0/24
        keyexchange=ike
        ikelifetime=240m
        keylife=3600s
        pfs=yes
        compress=no
        authby=secret
        keyingtries=0
        auto=start

#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf


- et voici le fichier "/etc/ipsec.secrets" :
Code: Tout sélectionner
212.0.0.78 212.0.0.14 : PSK "mettre_ici_le_secret_partagé_par_les_deux_routeurs"


- Ensuite il faut configurer le pare-feu pour que le tunnel puisse s'établir. L'échange des secrets partagés nécessite l'ouverture du port UDP 500 dans les deux sens :
Code: Tout sélectionner
iptables --append INPUT --source $ADRESSE_IP_ROUTEUR_DISTANT --protocol udp --sport 500 --dport 500 --jump ACCEPT
iptables --append OUTPUT --destination $ADRESSE_IP_ROUTEUR_DISTANT --protocol udp --sport 500 --dport 500 --jump ACCEPT


- Il faut aussi autoriser le protocole ESP puisque c'est le protocole qui sert à encapsuler les paquets "tunnelés" :
Code: Tout sélectionner
iptables --append INPUT --protocol esp --source $ADRESSE_IP_ROUTEUR_DISTANT --jump ACCEPT
iptables --append OUTPUT --protocol esp --destination $ADRESSE_IP_ROUTEUR_DISTANT --jump ACCEPT


- Pour éviter le conflit entre le SNAT et le tunnel IPsec, au niveau de NetFilter, il faut exclure le réseau distant de la translation d'adresse source qui est effectuée pour tous les paquets à destination d'Internet. Donc au lieu de :
Code: Tout sélectionner
iptables --table nat --append POSTROUTING --out-interface eth0 --jump SNAT --to-source $ADRESSE_IP_PUBLIQUE

il faut mettre :
Code: Tout sélectionner
iptables --table nat --append POSTROUTING --out-interface eth0 --destination ! 100.0.0.0/24 --jump SNAT --to-source $ADRESSE_IP_PUBLIQUE


- Pour que les paquets en provenance du réseau distant soient acceptés, il faut avoir ceci :
Code: Tout sélectionner
iptables --append FORWARD --match policy --dir in --pol ipsec --mode tunnel  --tunnel-src 100.0.0.1 --tunnel-dst 192.168.0.1 --jump ACCEPT


- On autorise aussi, évidemment, les paquets circulant dans l'autre sens :
Code: Tout sélectionner
iptables --append FORWARD --match policy --dir out --pol ipsec --mode tunnel --tunnel-src 192.168.0.1 --tunnel-dst 100.0.0.1 --jump ACCEPT


- Il faut aussi autoriser le routeur à recevoir les messages ICMP de type "fragmentation-needed" à partir de l'extérieur, car sinon certains gros paquets ne passeront pas à travers le tunnel (plus d'information sur le filtrage des paquets ICMP) :
Code: Tout sélectionner
iptables --append INPUT --protocol icmp --icmp-type fragmentation-needed --jump ACCEPT


Voilà! Avec tout ça, ça fonctionne! J'espère que les indications ci-dessus seront utiles à d'autres personnes et que ça leur évitera les nombreuses heures de recherche que j'y ai passé. :wink:

Cordialement,
Geceo
Dernière édition par Geceo le 10 Jan 2007 22:58, édité 3 fois au total.
Geceo
Premier-Maître
Premier-Maître
 
Messages: 48
Inscrit le: 07 Juil 2005 10:53

Suivant

Retour vers Sécurité et réseaux

Qui est en ligne ?

Utilisateur(s) parcourant actuellement ce forum : Aucun utilisateur inscrit et 0 invité(s)