On me demande de monter un tunnel ipsec entre 2 sites via Internet. J'ai
donc monté 2 machines de test à base de Debian Sarge, modifiée avec un
kernel Vanilla 2.6.18.2 avec tout ce qu'il faut pour ipsec compilé en
module, et les outils ipsec-tools et racoon 0.6.6 (backportés depuis
etch)
je fais ma popote de config pour setkey, psk et racoon.conf, et je lance
les démons racoon en foreground sur les 2 machines... et rien ne se passe
!
Bon, je relis l'IPsec-Howto (http://www.ipsec-howto.org/) et je tombe là-
dessus :
"The IKE daemon racoon does not start the tunnel negotiation immediately
when started. Rather racoon waits until the tunnel is needed. For this
notification to occur the kernel needs to know when to notify racoon. To
achieve this, the administrator needs to define security policies without
the appropiate security associations. Whenever the Linux kernel needs to
protect a packet according to the security policies and when no security
association is available, the Linux kernel calls racoon and asks for the
required security associations. Racoon will then start the IKE
negotiations and will create the SAs when finished. The Linux kernel can
then send the packets."
Pour résumer, si je comprends bien, le tunnel est monté à la demande.
Qu'à cela ne tienne, je tente un ping vers le réseau distant :
# ping 192.168.221.254
PING 192.168.221.254 (192.168.221.254) 56(84) bytes of data.
From 193.253.14.185 icmp_seq=32 Destination Net Unreachable
Et c'est le 1er routeur de bordure derrière ma passerelle par défaut qui
me répond que le paquet n'est pas routable !
Forcément, ma table de routage ne contient aucune route vers mon réseau
distant, puisque je n'ai encore aucune interface de montée !
J'en conclus que je dois louper quelque chose, mais j'ai beau lire et
relire le ipsec howto, je vois pas quoi ?
Un petit coup de pouce sera le bienvenu :)
Certes. Mais note aussi que ce n'est pas du tout nécessaire. Dans mon setup, les tunnels VPNs permanents sont établis de réseau à réseau, sans passer par un adressage supplémentaire.
c'est ce que je me suis dit, après avoir constaté que KAME travaille
directement sur une interface réelle : mon routage à la openvpn n'a plus lieu d'être, et ne sert plus à rien... sauf dans le cas où je voudrais joindre un réseau sur le même plan d'eddressage que moi ! dans ce cas, je suppose qu'il faudrait que je mette en place un réseau "tampon" qui ferait de la translation d'adresse d'un réseau à l'autre ?
Probable, même si ce serait galère sans plan d'adressage précis ; tu aurais besoin d'une route statique par machine, si je ne me trompe.
Et comme les end-points VPN sont situés sur les passerelles par défaut de chaque réseau, les machines clientes n'ont pas besoin de routes supplémentaires pour atteindre chaque côté du VPN.
Par contre, les routeurs eux-mêmes en ont besoin (sinon, ils sont incapables de communiquer entre eux via le VPN, alors que le reste du réseau y arrive, IIRC).
là par contre je suis pas sur de saisir ?
Dans mon exemple, mettons qu'une machine 192.168.50.12 veuille communiquer avec 192.168.51.13. on est d'accord que la route par défaut pour 192.168.50.12 est 192.168.50.254 ? donc tout paquet à destination de 192.168.51.13 sera routé vers 192.168.50.254 ? Donc 192.168.50.254 va avoir une décision deroutage à prendre afin de router le paquet vers 192.168.51.254 Et c'est _seulement_ à ce moment que KAME va intercepter le paquet, l'encapsuler dans ipsec et le réinjecter dans la pile IP ?
Je pense que l'ordre est exactement inverse. Le paquet arrive, est (mal)traité par le stack KAME puis routé pour sa véritable destination. Note qu'il est possible aussi que cette approche soit différente selon l'OS, je n'en sais rien. N'oublions pas non plus que, selon les cas, il peut y avoir des règles de NAT en plus, pour corser la chose.
Donc le routeur _doit_ connaitre le moyen de router un endpoint à un autre ? Ou j'ai faux ?
Expérimentalement, oui ! :)
De mon expérience sur NetBSD, si le paquet vient de la machine locale, il essaie de partir directement par la route par défaut (à cause de mon NAT ?). Il ne passe par le tunnel IPSEC qu'avec une route explicite, je viens encore de faire le test...
Fred -- While you are wasting your time on you enemies Engulfed in a fever of spite Beyond your tunnel vision reality fades Like shadows into the night (Pink Floyd, Lost For Words)
"F. Senault" <fred@lacave.net> wrote in
news:8exrixk74ihn.dlg@tamnavulin.lacave.local:
Certes. Mais note aussi que ce n'est pas du tout nécessaire. Dans
mon setup, les tunnels VPNs permanents sont établis de réseau à
réseau, sans passer par un adressage supplémentaire.
c'est ce que je me suis dit, après avoir constaté que KAME travaille
directement sur une interface réelle : mon routage à la openvpn n'a plus
lieu d'être, et ne sert plus à rien... sauf dans le cas où je voudrais
joindre un réseau sur le même plan d'eddressage que moi ! dans ce cas,
je suppose qu'il faudrait que je mette en place un réseau "tampon" qui
ferait de la translation d'adresse d'un réseau à l'autre ?
Probable, même si ce serait galère sans plan d'adressage précis ; tu
aurais besoin d'une route statique par machine, si je ne me trompe.
Et comme les end-points VPN sont situés sur les passerelles par défaut
de chaque réseau, les machines clientes n'ont pas besoin de routes
supplémentaires pour atteindre chaque côté du VPN.
Par contre, les routeurs eux-mêmes en ont besoin (sinon, ils sont
incapables de communiquer entre eux via le VPN, alors que le reste du
réseau y arrive, IIRC).
là par contre je suis pas sur de saisir ?
Dans mon exemple, mettons qu'une machine 192.168.50.12 veuille
communiquer avec 192.168.51.13. on est d'accord que la route par défaut
pour 192.168.50.12 est 192.168.50.254 ? donc tout paquet à destination
de 192.168.51.13 sera routé vers 192.168.50.254 ? Donc 192.168.50.254 va
avoir une décision deroutage à prendre afin de router le paquet vers
192.168.51.254 Et c'est _seulement_ à ce moment que KAME va intercepter
le paquet, l'encapsuler dans ipsec et le réinjecter dans la pile IP ?
Je pense que l'ordre est exactement inverse. Le paquet arrive, est
(mal)traité par le stack KAME puis routé pour sa véritable destination.
Note qu'il est possible aussi que cette approche soit différente selon
l'OS, je n'en sais rien. N'oublions pas non plus que, selon les cas, il
peut y avoir des règles de NAT en plus, pour corser la chose.
Donc le routeur _doit_ connaitre le moyen de router un endpoint à un
autre ? Ou j'ai faux ?
Expérimentalement, oui ! :)
De mon expérience sur NetBSD, si le paquet vient de la machine locale,
il essaie de partir directement par la route par défaut (à cause de mon
NAT ?). Il ne passe par le tunnel IPSEC qu'avec une route explicite, je
viens encore de faire le test...
Fred
--
While you are wasting your time on you enemies
Engulfed in a fever of spite
Beyond your tunnel vision reality fades
Like shadows into the night (Pink Floyd, Lost For Words)
Certes. Mais note aussi que ce n'est pas du tout nécessaire. Dans mon setup, les tunnels VPNs permanents sont établis de réseau à réseau, sans passer par un adressage supplémentaire.
c'est ce que je me suis dit, après avoir constaté que KAME travaille
directement sur une interface réelle : mon routage à la openvpn n'a plus lieu d'être, et ne sert plus à rien... sauf dans le cas où je voudrais joindre un réseau sur le même plan d'eddressage que moi ! dans ce cas, je suppose qu'il faudrait que je mette en place un réseau "tampon" qui ferait de la translation d'adresse d'un réseau à l'autre ?
Probable, même si ce serait galère sans plan d'adressage précis ; tu aurais besoin d'une route statique par machine, si je ne me trompe.
Et comme les end-points VPN sont situés sur les passerelles par défaut de chaque réseau, les machines clientes n'ont pas besoin de routes supplémentaires pour atteindre chaque côté du VPN.
Par contre, les routeurs eux-mêmes en ont besoin (sinon, ils sont incapables de communiquer entre eux via le VPN, alors que le reste du réseau y arrive, IIRC).
là par contre je suis pas sur de saisir ?
Dans mon exemple, mettons qu'une machine 192.168.50.12 veuille communiquer avec 192.168.51.13. on est d'accord que la route par défaut pour 192.168.50.12 est 192.168.50.254 ? donc tout paquet à destination de 192.168.51.13 sera routé vers 192.168.50.254 ? Donc 192.168.50.254 va avoir une décision deroutage à prendre afin de router le paquet vers 192.168.51.254 Et c'est _seulement_ à ce moment que KAME va intercepter le paquet, l'encapsuler dans ipsec et le réinjecter dans la pile IP ?
Je pense que l'ordre est exactement inverse. Le paquet arrive, est (mal)traité par le stack KAME puis routé pour sa véritable destination. Note qu'il est possible aussi que cette approche soit différente selon l'OS, je n'en sais rien. N'oublions pas non plus que, selon les cas, il peut y avoir des règles de NAT en plus, pour corser la chose.
Donc le routeur _doit_ connaitre le moyen de router un endpoint à un autre ? Ou j'ai faux ?
Expérimentalement, oui ! :)
De mon expérience sur NetBSD, si le paquet vient de la machine locale, il essaie de partir directement par la route par défaut (à cause de mon NAT ?). Il ne passe par le tunnel IPSEC qu'avec une route explicite, je viens encore de faire le test...
Fred -- While you are wasting your time on you enemies Engulfed in a fever of spite Beyond your tunnel vision reality fades Like shadows into the night (Pink Floyd, Lost For Words)
Pascal Hambourg
Salut,
Là est la clé de mon problème ! Dans mon esprit racoon montait une interface virtuelle (genre tun/tap, ou même ppp) à la manière d'openvpn !!!
Nope. Ca a déjà été discuté, mais il semblerait que ça soit compliqué, surtout de manière à peu près portable.
Même pas en mode tunnel ? Et comment il fait iptables pour reconnaître ses petits ?
Salut,
Là est la clé de mon problème ! Dans mon esprit racoon montait une
interface virtuelle (genre tun/tap, ou même ppp) à la manière d'openvpn !!!
Nope. Ca a déjà été discuté, mais il semblerait que ça soit compliqué,
surtout de manière à peu près portable.
Même pas en mode tunnel ?
Et comment il fait iptables pour reconnaître ses petits ?
Là est la clé de mon problème ! Dans mon esprit racoon montait une interface virtuelle (genre tun/tap, ou même ppp) à la manière d'openvpn !!!
Nope. Ca a déjà été discuté, mais il semblerait que ça soit compliqué, surtout de manière à peu près portable.
Même pas en mode tunnel ? Et comment il fait iptables pour reconnaître ses petits ?
F. Senault
portable.
iptables
Trooooooooooll !
Fred -- FreeBSD talisker.lacave.net 5.3-STABLE FreeBSD 5.3-STABLE #1: Sun Jan 2 19:24:30 CET 2005 :/usr/obj/usr/src/sys/TALISKER i386
portable.
iptables
Trooooooooooll !
Fred
--
FreeBSD talisker.lacave.net 5.3-STABLE FreeBSD 5.3-STABLE #1: Sun Jan 2
19:24:30 CET 2005 root@talisker.lacave.net:/usr/obj/usr/src/sys/TALISKER
i386
Fred -- FreeBSD talisker.lacave.net 5.3-STABLE FreeBSD 5.3-STABLE #1: Sun Jan 2 19:24:30 CET 2005 :/usr/obj/usr/src/sys/TALISKER i386
Pascal Hambourg
portable.
iptables
Trooooooooooll !
Moi ? Jamais ! Tu peux remplacer "iptables" par tout autre filtre de paquets. L'interface d'entrée et/ou de sortie est pour moi un critère de tri capital. Si le trafic décapsulé d'un tunnel IPSec apparaît comme passant par la même interface que le trafic internet, comment je fais ?
portable.
iptables
Trooooooooooll !
Moi ? Jamais !
Tu peux remplacer "iptables" par tout autre filtre de paquets.
L'interface d'entrée et/ou de sortie est pour moi un critère de tri
capital. Si le trafic décapsulé d'un tunnel IPSec apparaît comme passant
par la même interface que le trafic internet, comment je fais ?
Moi ? Jamais ! Tu peux remplacer "iptables" par tout autre filtre de paquets. L'interface d'entrée et/ou de sortie est pour moi un critère de tri capital. Si le trafic décapsulé d'un tunnel IPSec apparaît comme passant par la même interface que le trafic internet, comment je fais ?
Julien Salgado
Pascal Hambourg a écrit(wrote):
portable.
iptables
Trooooooooooll !
Moi ? Jamais ! Tu peux remplacer "iptables" par tout autre filtre de paquets. L'interface d'entrée et/ou de sortie est pour moi un critère de tri capital. Si le trafic décapsulé d'un tunnel IPSec apparaît comme passant par la même interface que le trafic internet, comment je fais ?
Tu marques le paquet lorsqu'il arrive en IPSEC (tu as l'IP du peer comme critère de sélection et le proto (esp),... ), la marque est conservée durant toute la vie du paquet. Un truc du genre (exemple un peu permissif :)) : iptables -t mangle -A PREROUTING -p esp -s $IP_PEER -j MARK --set-mark 1 iptables -A FORWARD -m mark --mark 1 -j ACCEPT Tu peux faire ton tri sur l'interface d'entrée (celle d'internet), la mark que tu a mis (qui indentifie ton peer), des adresses source et/ou destination (qui doivent normalement correspondre à la SA). En sortie (après chiffrement), c'est encore plus interessant on peut utiliser la marque mise lorsque le paquet était en clair pour faire de la prioritisation de trafic, même s'il est chiffré...
Sinon il y a la solution des patchs-o-matic ipsec-01-output-hooks et ipsec-02-input-hooks, mais bon c'est en test.
-- Julien
Pascal Hambourg a écrit(wrote):
portable.
iptables
Trooooooooooll !
Moi ? Jamais !
Tu peux remplacer "iptables" par tout autre filtre de paquets.
L'interface d'entrée et/ou de sortie est pour moi un critère de tri
capital. Si le trafic décapsulé d'un tunnel IPSec apparaît comme passant
par la même interface que le trafic internet, comment je fais ?
Tu marques le paquet lorsqu'il arrive en IPSEC (tu as l'IP du peer comme
critère de sélection et le proto (esp),... ), la marque est conservée
durant toute la vie du paquet. Un truc du genre (exemple un peu
permissif :)) :
iptables -t mangle -A PREROUTING -p esp -s $IP_PEER -j MARK --set-mark 1
iptables -A FORWARD -m mark --mark 1 -j ACCEPT
Tu peux faire ton tri sur l'interface d'entrée (celle d'internet), la
mark que tu a mis (qui indentifie ton peer), des adresses source et/ou
destination (qui doivent normalement correspondre à la SA).
En sortie (après chiffrement), c'est encore plus interessant on peut
utiliser la marque mise lorsque le paquet était en clair pour faire de
la prioritisation de trafic, même s'il est chiffré...
Sinon il y a la solution des patchs-o-matic ipsec-01-output-hooks et
ipsec-02-input-hooks, mais bon c'est en test.
Moi ? Jamais ! Tu peux remplacer "iptables" par tout autre filtre de paquets. L'interface d'entrée et/ou de sortie est pour moi un critère de tri capital. Si le trafic décapsulé d'un tunnel IPSec apparaît comme passant par la même interface que le trafic internet, comment je fais ?
Tu marques le paquet lorsqu'il arrive en IPSEC (tu as l'IP du peer comme critère de sélection et le proto (esp),... ), la marque est conservée durant toute la vie du paquet. Un truc du genre (exemple un peu permissif :)) : iptables -t mangle -A PREROUTING -p esp -s $IP_PEER -j MARK --set-mark 1 iptables -A FORWARD -m mark --mark 1 -j ACCEPT Tu peux faire ton tri sur l'interface d'entrée (celle d'internet), la mark que tu a mis (qui indentifie ton peer), des adresses source et/ou destination (qui doivent normalement correspondre à la SA). En sortie (après chiffrement), c'est encore plus interessant on peut utiliser la marque mise lorsque le paquet était en clair pour faire de la prioritisation de trafic, même s'il est chiffré...
Sinon il y a la solution des patchs-o-matic ipsec-01-output-hooks et ipsec-02-input-hooks, mais bon c'est en test.
-- Julien
elpadrino
Eric Belhomme a écrit le 13/11/2006 à 09h55 :
Bonjour,
On me demande de monter un tunnel ipsec entre 2 sites via Internet. J'ai donc monté 2 machines de test à base de Debian Sarge, modifiée avec un kernel Vanilla 2.6.18.2 avec tout ce qu'il faut pour ipsec compilé en module, et les outils ipsec-tools et racoon 0.6.6 (backportés depuis etch)
je fais ma popote de config pour setkey, psk et racoon.conf, et je lance les démons racoon en foreground sur les 2 machines... et rien ne se passe !
Bon, je relis l'IPsec-Howto (http://www.ipsec-howto.org/) et je tombe là- dessus :
"The IKE daemon racoon does not start the tunnel negotiation immediately when started. Rather racoon waits until the tunnel is needed. For this notification to occur the kernel needs to know when to notify racoon. To achieve this, the administrator needs to define security policies without the appropiate security associations. Whenever the Linux kernel needs to protect a packet according to the security policies and when no security association is available, the Linux kernel calls racoon and asks for the required security associations. Racoon will then start the IKE negotiations and will create the SAs when finished. The Linux kernel can then send the packets."
Pour résumer, si je comprends bien, le tunnel est monté à la demande. Qu'à cela ne tienne, je tente un ping vers le réseau distant : # ping 192.168.221.254 PING 192.168.221.254 (192.168.221.254) 56(84) bytes of data. From 193.253.14.185 icmp_seq2 Destination Net Unreachable
Et c'est le 1er routeur de bordure derrière ma passerelle par défaut qui me répond que le paquet n'est pas routable !
Forcément, ma table de routage ne contient aucune route vers mon réseau distant, puisque je n'ai encore aucune interface de montée !
J'en conclus que je dois louper quelque chose, mais j'ai beau lire et relire le ipsec howto, je vois pas quoi ? Un petit coup de pouce sera le bienvenu :)
-- Rico
salut Eric , j'ai le meme probleme , j'ai fait un reseau entre deux machine , chaque machine a deux machine viruelle sur VMware ( fedora7) , mais le ping ne fonctionne pas entre les sites ... je sais meme pas est ce que je dois ajouter des routes ou c'est automatique par le lancement de racoon .. besoin d'aiddddde svp
Eric Belhomme a écrit le 13/11/2006 à 09h55 :
Bonjour,
On me demande de monter un tunnel ipsec entre 2 sites via Internet. J'ai
donc monté 2 machines de test à base de Debian Sarge,
modifiée avec un
kernel Vanilla 2.6.18.2 avec tout ce qu'il faut pour ipsec compilé en
module, et les outils ipsec-tools et racoon 0.6.6 (backportés depuis
etch)
je fais ma popote de config pour setkey, psk et racoon.conf, et je lance
les démons racoon en foreground sur les 2 machines... et rien ne se
passe
!
Bon, je relis l'IPsec-Howto (http://www.ipsec-howto.org/) et je tombe
là-
dessus :
"The IKE daemon racoon does not start the tunnel negotiation immediately
when started. Rather racoon waits until the tunnel is needed. For this
notification to occur the kernel needs to know when to notify racoon. To
achieve this, the administrator needs to define security policies without
the appropiate security associations. Whenever the Linux kernel needs to
protect a packet according to the security policies and when no security
association is available, the Linux kernel calls racoon and asks for the
required security associations. Racoon will then start the IKE
negotiations and will create the SAs when finished. The Linux kernel can
then send the packets."
Pour résumer, si je comprends bien, le tunnel est monté à
la demande.
Qu'à cela ne tienne, je tente un ping vers le réseau distant :
# ping 192.168.221.254
PING 192.168.221.254 (192.168.221.254) 56(84) bytes of data.
From 193.253.14.185 icmp_seq=32 Destination Net Unreachable
Et c'est le 1er routeur de bordure derrière ma passerelle par
défaut qui
me répond que le paquet n'est pas routable !
Forcément, ma table de routage ne contient aucune route vers mon
réseau
distant, puisque je n'ai encore aucune interface de montée !
J'en conclus que je dois louper quelque chose, mais j'ai beau lire et
relire le ipsec howto, je vois pas quoi ?
Un petit coup de pouce sera le bienvenu :)
--
Rico
salut Eric , j'ai le meme probleme , j'ai fait un reseau entre deux machine , chaque machine a deux machine viruelle sur VMware ( fedora7) , mais le ping ne fonctionne pas entre les sites ... je sais meme pas est ce que je dois ajouter des routes ou c'est automatique par le lancement de racoon .. besoin d'aiddddde svp
On me demande de monter un tunnel ipsec entre 2 sites via Internet. J'ai donc monté 2 machines de test à base de Debian Sarge, modifiée avec un kernel Vanilla 2.6.18.2 avec tout ce qu'il faut pour ipsec compilé en module, et les outils ipsec-tools et racoon 0.6.6 (backportés depuis etch)
je fais ma popote de config pour setkey, psk et racoon.conf, et je lance les démons racoon en foreground sur les 2 machines... et rien ne se passe !
Bon, je relis l'IPsec-Howto (http://www.ipsec-howto.org/) et je tombe là- dessus :
"The IKE daemon racoon does not start the tunnel negotiation immediately when started. Rather racoon waits until the tunnel is needed. For this notification to occur the kernel needs to know when to notify racoon. To achieve this, the administrator needs to define security policies without the appropiate security associations. Whenever the Linux kernel needs to protect a packet according to the security policies and when no security association is available, the Linux kernel calls racoon and asks for the required security associations. Racoon will then start the IKE negotiations and will create the SAs when finished. The Linux kernel can then send the packets."
Pour résumer, si je comprends bien, le tunnel est monté à la demande. Qu'à cela ne tienne, je tente un ping vers le réseau distant : # ping 192.168.221.254 PING 192.168.221.254 (192.168.221.254) 56(84) bytes of data. From 193.253.14.185 icmp_seq2 Destination Net Unreachable
Et c'est le 1er routeur de bordure derrière ma passerelle par défaut qui me répond que le paquet n'est pas routable !
Forcément, ma table de routage ne contient aucune route vers mon réseau distant, puisque je n'ai encore aucune interface de montée !
J'en conclus que je dois louper quelque chose, mais j'ai beau lire et relire le ipsec howto, je vois pas quoi ? Un petit coup de pouce sera le bienvenu :)
-- Rico
salut Eric , j'ai le meme probleme , j'ai fait un reseau entre deux machine , chaque machine a deux machine viruelle sur VMware ( fedora7) , mais le ping ne fonctionne pas entre les sites ... je sais meme pas est ce que je dois ajouter des routes ou c'est automatique par le lancement de racoon .. besoin d'aiddddde svp
