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 :)
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 !
Si tu utilises ipsec en mode tunnel c'est normal, tu peux voir les SP paramétrées via setkey -DP.
J'en conclus que je dois louper quelque chose, mais j'ai beau lire et relire le ipsec howto, je vois pas quoi ?
Quelle tête a ton ipsec.conf ?
-- Arretez de lui répondre, mon clavier est inondé de café à chaque fois ! Vous croyez vraiment qu'un clavier de d'ordinateur portable ça se remplace aussi facilement que ça ? -+- RG in GNU-SE : Café affaire attenfion -+-
Eric Belhomme <{rico}+no/spam@ricospirit.net> writes:
'Lut,
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 !
Si tu utilises ipsec en mode tunnel c'est normal, tu peux voir les SP
paramétrées via setkey -DP.
J'en conclus que je dois louper quelque chose, mais j'ai beau lire et
relire le ipsec howto, je vois pas quoi ?
Quelle tête a ton ipsec.conf ?
--
Arretez de lui répondre, mon clavier est inondé de café à chaque fois !
Vous croyez vraiment qu'un clavier de d'ordinateur portable ça se
remplace aussi facilement que ça ?
-+- RG in GNU-SE : Café affaire attenfion -+-
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 !
Si tu utilises ipsec en mode tunnel c'est normal, tu peux voir les SP paramétrées via setkey -DP.
J'en conclus que je dois louper quelque chose, mais j'ai beau lire et relire le ipsec howto, je vois pas quoi ?
Quelle tête a ton ipsec.conf ?
-- Arretez de lui répondre, mon clavier est inondé de café à chaque fois ! Vous croyez vraiment qu'un clavier de d'ordinateur portable ça se remplace aussi facilement que ça ? -+- RG in GNU-SE : Café affaire attenfion -+-
J1
Bonjour
Eric Belhomme wrote:
Pour résumer, si je comprends bien, le tunnel est monté à la demande.
Oui c'est bien ca, et un simple ping suffit a le monter. Dans mon cas ca prenait environ 2 secondes.
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 !
C'est qu'il doit y avoir un probleme dans la configuration d'ipsec. Le paquet n'aurait pas du sortir avec cette adresse mais avec l'adresse de la passerelle.
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 !
La ca devient un peu plus complique. D'apres ce que j'ai constate, aucune ligne n'est ajoutee a la table de routage, ce qui n'est vraiment pas pratique. Les informations situes dans le fichier ipsec-tools.conf sont utilisees, mais n'apparaissent pas dans la table de routage.
Etrangement, il ne faut pas s'attendre a ce qu'une nouvelle interface soit montee. Contrairement au fonctionnement d'openvpn, ou d'autres softs de tunneling, c'est l'interface qui sert pour la sortie qui est utilisee dans la table routage, il n'y a pas d'interface "tun".
J'en conclus que je dois louper quelque chose, mais j'ai beau lire et relire le ipsec howto, je vois pas quoi ?
J'avais effectue des tests avec environ la meme configuration, ca fonctionnait bien en production, avec quelques Mbits/sec la charge restait très basse, les temps de latence aussi, pas de paquets perdus, le bonheur.
Mais les incoherences dans les tables de routage rendaient difficiles le montage d'un systeme plus complexe, je suis donc passe sur un "bete" tunnel OpenVPN, qui permet entre autres de faire de la compression (utile si tu paies la BP), et pour lequel on trouve une abondance de documentation. La consommation CPU est un peu plus elevee (a debit egal), mais je ne constate pas plus de latence ni de perte de paquets. En cas de perturbation réseau entre les deux passerelles VPN je dirais meme qu'OpenVPN est plus pratique, car ses logs sont plus explicites a mon gout.
En bref, je te recommande de verifier dans ton fichier ipsec-tools.conf que les lignes decrivant les adresses a router par le tunnel sont coherentes entre elles, et qu'elles concordent bien avec les adresses definies dans racoon.conf.
Les quelques lignes de logs peuvent aussi t'aiguiller un peu. Surveille /var/log/syslog quand tu lances racoon et setkey.
J'essaierai de remettre la main sur les fichiers de configuration qui m'avaient servi a l'epoque.
Un petit coup de pouce sera le bienvenu :)
My 2 cents,
-- J1
Bonjour
Eric Belhomme wrote:
Pour résumer, si je comprends bien, le tunnel est monté à la demande.
Oui c'est bien ca, et un simple ping suffit a le monter. Dans mon cas
ca prenait environ 2 secondes.
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 !
C'est qu'il doit y avoir un probleme dans la configuration d'ipsec.
Le paquet n'aurait pas du sortir avec cette adresse mais avec
l'adresse de la passerelle.
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 !
La ca devient un peu plus complique.
D'apres ce que j'ai constate, aucune ligne n'est ajoutee a la
table de routage, ce qui n'est vraiment pas pratique.
Les informations situes dans le fichier ipsec-tools.conf sont
utilisees, mais n'apparaissent pas dans la table de routage.
Etrangement, il ne faut pas s'attendre a ce qu'une nouvelle interface
soit montee.
Contrairement au fonctionnement d'openvpn, ou d'autres softs de
tunneling, c'est l'interface qui sert pour la sortie qui est
utilisee dans la table routage, il n'y a pas d'interface "tun".
J'en conclus que je dois louper quelque chose, mais j'ai beau lire et
relire le ipsec howto, je vois pas quoi ?
J'avais effectue des tests avec environ la meme configuration,
ca fonctionnait bien en production, avec quelques Mbits/sec la charge
restait très basse, les temps de latence aussi, pas de paquets perdus,
le bonheur.
Mais les incoherences dans les tables de routage rendaient
difficiles le montage d'un systeme plus complexe, je suis donc
passe sur un "bete" tunnel OpenVPN, qui permet entre autres de faire
de la compression (utile si tu paies la BP), et pour lequel
on trouve une abondance de documentation.
La consommation CPU est un peu plus elevee (a debit egal), mais
je ne constate pas plus de latence ni de perte de paquets.
En cas de perturbation réseau entre les deux passerelles VPN je
dirais meme qu'OpenVPN est plus pratique, car ses logs sont plus
explicites a mon gout.
En bref, je te recommande de verifier dans ton fichier
ipsec-tools.conf que les lignes decrivant les adresses a router
par le tunnel sont coherentes entre elles, et qu'elles concordent
bien avec les adresses definies dans racoon.conf.
Les quelques lignes de logs peuvent aussi t'aiguiller un peu.
Surveille /var/log/syslog quand tu lances racoon et setkey.
J'essaierai de remettre la main sur les fichiers de configuration
qui m'avaient servi a l'epoque.
Pour résumer, si je comprends bien, le tunnel est monté à la demande.
Oui c'est bien ca, et un simple ping suffit a le monter. Dans mon cas ca prenait environ 2 secondes.
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 !
C'est qu'il doit y avoir un probleme dans la configuration d'ipsec. Le paquet n'aurait pas du sortir avec cette adresse mais avec l'adresse de la passerelle.
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 !
La ca devient un peu plus complique. D'apres ce que j'ai constate, aucune ligne n'est ajoutee a la table de routage, ce qui n'est vraiment pas pratique. Les informations situes dans le fichier ipsec-tools.conf sont utilisees, mais n'apparaissent pas dans la table de routage.
Etrangement, il ne faut pas s'attendre a ce qu'une nouvelle interface soit montee. Contrairement au fonctionnement d'openvpn, ou d'autres softs de tunneling, c'est l'interface qui sert pour la sortie qui est utilisee dans la table routage, il n'y a pas d'interface "tun".
J'en conclus que je dois louper quelque chose, mais j'ai beau lire et relire le ipsec howto, je vois pas quoi ?
J'avais effectue des tests avec environ la meme configuration, ca fonctionnait bien en production, avec quelques Mbits/sec la charge restait très basse, les temps de latence aussi, pas de paquets perdus, le bonheur.
Mais les incoherences dans les tables de routage rendaient difficiles le montage d'un systeme plus complexe, je suis donc passe sur un "bete" tunnel OpenVPN, qui permet entre autres de faire de la compression (utile si tu paies la BP), et pour lequel on trouve une abondance de documentation. La consommation CPU est un peu plus elevee (a debit egal), mais je ne constate pas plus de latence ni de perte de paquets. En cas de perturbation réseau entre les deux passerelles VPN je dirais meme qu'OpenVPN est plus pratique, car ses logs sont plus explicites a mon gout.
En bref, je te recommande de verifier dans ton fichier ipsec-tools.conf que les lignes decrivant les adresses a router par le tunnel sont coherentes entre elles, et qu'elles concordent bien avec les adresses definies dans racoon.conf.
Les quelques lignes de logs peuvent aussi t'aiguiller un peu. Surveille /var/log/syslog quand tu lances racoon et setkey.
J'essaierai de remettre la main sur les fichiers de configuration qui m'avaient servi a l'epoque.
Un petit coup de pouce sera le bienvenu :)
My 2 cents,
-- J1
F. Senault
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 :)
Sans plus d'infos sur ta config précise, ça risque d'être compliqué. Mais quand tu parles d'interface montée, je ne vois pas le rapport - le tunnel ipsec travaille sur une interface existante.
Tu peux rajouter ta route vers le réseau distant en indiquant l'IP de ton côté du tunnel et l'interface locale.
FWIW, je décris une config de A à Z de racoon ici (basée sur un cas tout à fait concret) :
Fred -- I know how to hurt I know how to kill I know what to show And what to conceal I know when to talk And I know when to touch No one ever died from wanting too much (Garbage, The World Is Not Enough)
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 :)
Sans plus d'infos sur ta config précise, ça risque d'être compliqué.
Mais quand tu parles d'interface montée, je ne vois pas le rapport - le
tunnel ipsec travaille sur une interface existante.
Tu peux rajouter ta route vers le réseau distant en indiquant l'IP de
ton côté du tunnel et l'interface locale.
FWIW, je décris une config de A à Z de racoon ici (basée sur un cas tout
à fait concret) :
Fred
--
I know how to hurt I know how to kill I know what to show
And what to conceal I know when to talk And I know when to touch
No one ever died from wanting too much
(Garbage, The World Is Not Enough)
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 :)
Sans plus d'infos sur ta config précise, ça risque d'être compliqué. Mais quand tu parles d'interface montée, je ne vois pas le rapport - le tunnel ipsec travaille sur une interface existante.
Tu peux rajouter ta route vers le réseau distant en indiquant l'IP de ton côté du tunnel et l'interface locale.
FWIW, je décris une config de A à Z de racoon ici (basée sur un cas tout à fait concret) :
Fred -- I know how to hurt I know how to kill I know what to show And what to conceal I know when to talk And I know when to touch No one ever died from wanting too much (Garbage, The World Is Not Enough)
Eric Masson
J1 writes:
'Lut,
D'apres ce que j'ai constate, aucune ligne n'est ajoutee a la table de routage, ce qui n'est vraiment pas pratique.
Nan, c'est complètement cohérent, comment est-ce que tu spécifies dans un table de routage que seuls les paquets de type ipip sont soumis à une transformation ipsec quelque soit la destination de ceux-ci ?
Les informations situes dans le fichier ipsec-tools.conf sont utilisees, mais n'apparaissent pas dans la table de routage.
Normal ce sont les spécifications des sélecteurs de politique de sécurité qui vont largement au delà de ce que permet de modéliser une table de routage.
Si tu veux une interface pour par exemple utiliser un protocole de routage dynamique, tu jettes un oeil du coté d'IIPTran, RFC3884.
-- ... moi je dis qu'une nouvelle version du 4004 est toujours un événement ;-) La seule chose vraiment intéressante est la taille du radiateur. Faut-il toujours 2 pentium III pour faire un moule à gaufres ? + EH in Guide du Macounet Pervers : À quoi rime ce ski corse à gaufre? +
J1 <ji1.NOJUNK@free.fr> writes:
'Lut,
D'apres ce que j'ai constate, aucune ligne n'est ajoutee a la
table de routage, ce qui n'est vraiment pas pratique.
Nan, c'est complètement cohérent, comment est-ce que tu spécifies dans
un table de routage que seuls les paquets de type ipip sont soumis à une
transformation ipsec quelque soit la destination de ceux-ci ?
Les informations situes dans le fichier ipsec-tools.conf sont
utilisees, mais n'apparaissent pas dans la table de routage.
Normal ce sont les spécifications des sélecteurs de politique de
sécurité qui vont largement au delà de ce que permet de modéliser une
table de routage.
Si tu veux une interface pour par exemple utiliser un protocole de
routage dynamique, tu jettes un oeil du coté d'IIPTran, RFC3884.
--
... moi je dis qu'une nouvelle version du 4004 est toujours un événement
;-) La seule chose vraiment intéressante est la taille du radiateur.
Faut-il toujours 2 pentium III pour faire un moule à gaufres ?
+ EH in Guide du Macounet Pervers : À quoi rime ce ski corse à gaufre? +
D'apres ce que j'ai constate, aucune ligne n'est ajoutee a la table de routage, ce qui n'est vraiment pas pratique.
Nan, c'est complètement cohérent, comment est-ce que tu spécifies dans un table de routage que seuls les paquets de type ipip sont soumis à une transformation ipsec quelque soit la destination de ceux-ci ?
Les informations situes dans le fichier ipsec-tools.conf sont utilisees, mais n'apparaissent pas dans la table de routage.
Normal ce sont les spécifications des sélecteurs de politique de sécurité qui vont largement au delà de ce que permet de modéliser une table de routage.
Si tu veux une interface pour par exemple utiliser un protocole de routage dynamique, tu jettes un oeil du coté d'IIPTran, RFC3884.
-- ... moi je dis qu'une nouvelle version du 4004 est toujours un événement ;-) La seule chose vraiment intéressante est la taille du radiateur. Faut-il toujours 2 pentium III pour faire un moule à gaufres ? + EH in Guide du Macounet Pervers : À quoi rime ce ski corse à gaufre? +
Eric Belhomme
Eric Masson wrote in news:79rl24-s87.ln1 @srvbsdnanssv.oursoides-associes.com:
Si tu utilises ipsec en mode tunnel c'est normal, tu peux voir les SP paramétrées via setkey -DP.
oui, je vois bien mes SP, mais pas de SA (normal, puisqu'il n'y a meme
pas de négociation IKE)
Quelle tête a ton ipsec.conf ?
euh... tu le sors d'où ce fichier ??? moi je ne configure qu'un fichier
pour les SP (/etc/ipsec-tools.conf sur Debian qui utilise setkey) et le fichier de conf de racoon (serveur IKE)
# cat /etc/ipsec-tools.conf #!/usr/sbin/setkey -f
flush; spdflush;
spdadd 192.168.51.0/24 192.168.50.0/24 any -P in ipsec esp/tunnel/x.x.x.a-x.x.x.b/require; spdadd 192.168.50.0/24 192.168.51.0/24 any -P out ipsec esp/tunnel/x.x.x.b-x.x.x.a/require;
sainfo address 192.168.50.0/24 any address 192.168.51.0/24 any { pfs_group modp768; encryption_algorithm 3des; authentication_algorithm hmac_md5; compression_algorithm deflate; }
# cat ./psk.txt x.x.x.a mon_secret
Voila toute l'histoire...
-- Rico
Eric Masson <emss@free.fr> wrote in news:79rl24-s87.ln1
@srvbsdnanssv.oursoides-associes.com:
Si tu utilises ipsec en mode tunnel c'est normal, tu peux voir les SP
paramétrées via setkey -DP.
oui, je vois bien mes SP, mais pas de SA (normal, puisqu'il n'y a meme
pas de négociation IKE)
Quelle tête a ton ipsec.conf ?
euh... tu le sors d'où ce fichier ??? moi je ne configure qu'un fichier
pour les SP (/etc/ipsec-tools.conf sur Debian qui utilise setkey) et le
fichier de conf de racoon (serveur IKE)
# cat /etc/ipsec-tools.conf
#!/usr/sbin/setkey -f
flush;
spdflush;
spdadd 192.168.51.0/24 192.168.50.0/24 any -P in ipsec
esp/tunnel/x.x.x.a-x.x.x.b/require;
spdadd 192.168.50.0/24 192.168.51.0/24 any -P out ipsec
esp/tunnel/x.x.x.b-x.x.x.a/require;
Eric Masson wrote in news:79rl24-s87.ln1 @srvbsdnanssv.oursoides-associes.com:
Si tu utilises ipsec en mode tunnel c'est normal, tu peux voir les SP paramétrées via setkey -DP.
oui, je vois bien mes SP, mais pas de SA (normal, puisqu'il n'y a meme
pas de négociation IKE)
Quelle tête a ton ipsec.conf ?
euh... tu le sors d'où ce fichier ??? moi je ne configure qu'un fichier
pour les SP (/etc/ipsec-tools.conf sur Debian qui utilise setkey) et le fichier de conf de racoon (serveur IKE)
# cat /etc/ipsec-tools.conf #!/usr/sbin/setkey -f
flush; spdflush;
spdadd 192.168.51.0/24 192.168.50.0/24 any -P in ipsec esp/tunnel/x.x.x.a-x.x.x.b/require; spdadd 192.168.50.0/24 192.168.51.0/24 any -P out ipsec esp/tunnel/x.x.x.b-x.x.x.a/require;
sainfo address 192.168.50.0/24 any address 192.168.51.0/24 any { pfs_group modp768; encryption_algorithm 3des; authentication_algorithm hmac_md5; compression_algorithm deflate; }
# cat ./psk.txt x.x.x.a mon_secret
Voila toute l'histoire...
-- Rico
Eric Masson
Eric Belhomme <{rico}+no/ writes:
oui, je vois bien mes SP, mais pas de SA (normal, puisqu'il n'y a meme pas de négociation IKE)
Effectivement.
C'est donc logiquement que le trafic que tu génères ne matche aucun des sélecteurs de la SPD.
euh... tu le sors d'où ce fichier ??? moi je ne configure qu'un fichier pour les SP (/etc/ipsec-tools.conf sur Debian qui utilise setkey)
C'est celui-là, dont le nom change en fonction de la distribution on dirait ;)
et le fichier de conf de racoon (serveur IKE)
<Snip fichiers de conf>
Rien de rédhibitoire à première vue.
Tu fais ton test de ping depuis la passerelle en elle même ? Vérifie que tu n'as pas une option permettant de spécifier l'adresse source du paquet de manière à ce que le paquet matche les sélecteurs de la SPD (nmdpcjsc)
-- Les conflits non résolus se règlent devant le juge, une personne qui n'est ni juge ni partie. -+- B in GNU : Parti de là, tu ne peux pas juger. -+-
Eric Belhomme <{rico}+no/spam@ricospirit.net> writes:
oui, je vois bien mes SP, mais pas de SA (normal, puisqu'il n'y a meme
pas de négociation IKE)
Effectivement.
C'est donc logiquement que le trafic que tu génères ne matche aucun des
sélecteurs de la SPD.
euh... tu le sors d'où ce fichier ??? moi je ne configure qu'un fichier
pour les SP (/etc/ipsec-tools.conf sur Debian qui utilise setkey)
C'est celui-là, dont le nom change en fonction de la distribution on
dirait ;)
et le fichier de conf de racoon (serveur IKE)
<Snip fichiers de conf>
Rien de rédhibitoire à première vue.
Tu fais ton test de ping depuis la passerelle en elle même ?
Vérifie que tu n'as pas une option permettant de spécifier l'adresse
source du paquet de manière à ce que le paquet matche les sélecteurs de
la SPD (nmdpcjsc)
--
Les conflits non résolus se règlent devant le juge, une personne qui
n'est ni juge ni partie.
-+- B in GNU : Parti de là, tu ne peux pas juger. -+-
oui, je vois bien mes SP, mais pas de SA (normal, puisqu'il n'y a meme pas de négociation IKE)
Effectivement.
C'est donc logiquement que le trafic que tu génères ne matche aucun des sélecteurs de la SPD.
euh... tu le sors d'où ce fichier ??? moi je ne configure qu'un fichier pour les SP (/etc/ipsec-tools.conf sur Debian qui utilise setkey)
C'est celui-là, dont le nom change en fonction de la distribution on dirait ;)
et le fichier de conf de racoon (serveur IKE)
<Snip fichiers de conf>
Rien de rédhibitoire à première vue.
Tu fais ton test de ping depuis la passerelle en elle même ? Vérifie que tu n'as pas une option permettant de spécifier l'adresse source du paquet de manière à ce que le paquet matche les sélecteurs de la SPD (nmdpcjsc)
-- Les conflits non résolus se règlent devant le juge, une personne qui n'est ni juge ni partie. -+- B in GNU : Parti de là, tu ne peux pas juger. -+-
Eric Belhomme
Eric Masson wrote in news:6vtl24-s87.ln1 @srvbsdnanssv.oursoides-associes.com:
Rien de rédhibitoire à première vue.
ca me semble conforme à ce que j'ai vu par ailleurs
Tu fais ton test de ping depuis la passerelle en elle même ? oui
# setkey -DP 192.168.51.0/24[any] 192.168.50.0/24[any] any in prio def ipsec esp/tunnel/x.x.x.b-x.x.x.a/require created: Nov 13 09:08:27 2006 lastused: lifetime: 0(s) validtime: 0(s) spid128 seq=2 pidv49 refcnt=1 192.168.50.0/24[any] 192.168.51.0/24[any] any out prio def ipsec esp/tunnel/x.x.x.a-x.x.x.b/require created: Nov 13 09:08:27 2006 lastused: lifetime: 0(s) validtime: 0(s) spid145 seq=1 pidv49 refcnt=1 192.168.51.0/24[any] 192.168.50.0/24[any] any fwd prio def ipsec esp/tunnel/x.x.x.b-x.x.x.a/require created: Nov 13 09:08:27 2006 lastused: lifetime: 0(s) validtime: 0(s) spid138 seq=0 pidv49 refcnt=1
Vérifie que tu n'as pas une option permettant de spécifier l'adresse source du paquet de manière à ce que le paquet matche les sélecteurs de la SPD (nmdpcjsc)
Can't grab 192.168.50.254:0 with bind : Cannot assign requested address
J'ai du mal à comprendre comme le tunnel peut fonctionner, si il n'y a pas d'interface virtuelle ni d'adresse sur la passerelle ?
-- Rico
Eric Masson <emss@free.fr> wrote in news:6vtl24-s87.ln1
@srvbsdnanssv.oursoides-associes.com:
Rien de rédhibitoire à première vue.
ca me semble conforme à ce que j'ai vu par ailleurs
Tu fais ton test de ping depuis la passerelle en elle même ?
oui
# setkey -DP
192.168.51.0/24[any] 192.168.50.0/24[any] any
in prio def ipsec
esp/tunnel/x.x.x.b-x.x.x.a/require
created: Nov 13 09:08:27 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid128 seq=2 pidv49
refcnt=1
192.168.50.0/24[any] 192.168.51.0/24[any] any
out prio def ipsec
esp/tunnel/x.x.x.a-x.x.x.b/require
created: Nov 13 09:08:27 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid145 seq=1 pidv49
refcnt=1
192.168.51.0/24[any] 192.168.50.0/24[any] any
fwd prio def ipsec
esp/tunnel/x.x.x.b-x.x.x.a/require
created: Nov 13 09:08:27 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid138 seq=0 pidv49
refcnt=1
Vérifie que tu n'as pas une option permettant de spécifier l'adresse
source du paquet de manière à ce que le paquet matche les sélecteurs de
la SPD (nmdpcjsc)
Eric Masson wrote in news:6vtl24-s87.ln1 @srvbsdnanssv.oursoides-associes.com:
Rien de rédhibitoire à première vue.
ca me semble conforme à ce que j'ai vu par ailleurs
Tu fais ton test de ping depuis la passerelle en elle même ? oui
# setkey -DP 192.168.51.0/24[any] 192.168.50.0/24[any] any in prio def ipsec esp/tunnel/x.x.x.b-x.x.x.a/require created: Nov 13 09:08:27 2006 lastused: lifetime: 0(s) validtime: 0(s) spid128 seq=2 pidv49 refcnt=1 192.168.50.0/24[any] 192.168.51.0/24[any] any out prio def ipsec esp/tunnel/x.x.x.a-x.x.x.b/require created: Nov 13 09:08:27 2006 lastused: lifetime: 0(s) validtime: 0(s) spid145 seq=1 pidv49 refcnt=1 192.168.51.0/24[any] 192.168.50.0/24[any] any fwd prio def ipsec esp/tunnel/x.x.x.b-x.x.x.a/require created: Nov 13 09:08:27 2006 lastused: lifetime: 0(s) validtime: 0(s) spid138 seq=0 pidv49 refcnt=1
Vérifie que tu n'as pas une option permettant de spécifier l'adresse source du paquet de manière à ce que le paquet matche les sélecteurs de la SPD (nmdpcjsc)
Can't grab 192.168.50.254:0 with bind : Cannot assign requested address
J'ai du mal à comprendre comme le tunnel peut fonctionner, si il n'y a pas d'interface virtuelle ni d'adresse sur la passerelle ?
-- Rico
J1
Eric Masson wrote:
'Lut,
Salut!
D'apres ce que j'ai constate, aucune ligne n'est ajoutee a la table de routage, ce qui n'est vraiment pas pratique.
Nan, c'est complètement cohérent,
N'ai pas parle d'incoherence, juste du cote pratique :)
comment est-ce que tu spécifies dans un table de routage que seuls les paquets de type ipip sont soumis à une transformation ipsec quelque soit la destination de ceux-ci ?
Effectivement, ces contraintes ne permettent pas l'ajout d'entrees dans la table de routage, nous sommes d'accord.
Les informations situes dans le fichier ipsec-tools.conf sont utilisees, mais n'apparaissent pas dans la table de routage.
Normal ce sont les spécifications des sélecteurs de politique de sécurité qui vont largement au delà de ce que permet de modéliser une table de routage.
Je n'ai pas pousse tres loin mon utilisation d'ipsec et des politiques de securite, mais dans le cas d'un systeme linux, quelles operations sont possibles avec les selecteurs de politiques que ne permettent pas les outils netfilter + iproute2 + tunnel ?
Si tu veux une interface pour par exemple utiliser un protocole de routage dynamique, tu jettes un oeil du coté d'IIPTran, RFC3884.
Merci pour l'information. Avec ce type de tunnel, redevient il possible d'utiliser les outils classiques de routage et de filtrage (si j'ai bien suivi, oui) ou faut il encore manipuler les tables de routage ET les selecteurs de politique de securite lors d'ajout de regles de routage?
Dans ce cas je rebasculerais bien mes VPN sur ipsec!
En tout cas merci pour ces precisions,
-- J1
Eric Masson wrote:
'Lut,
Salut!
D'apres ce que j'ai constate, aucune ligne n'est ajoutee a la
table de routage, ce qui n'est vraiment pas pratique.
Nan, c'est complètement cohérent,
N'ai pas parle d'incoherence, juste du cote pratique :)
comment est-ce que tu spécifies dans
un table de routage que seuls les paquets de type ipip sont soumis à une
transformation ipsec quelque soit la destination de ceux-ci ?
Effectivement, ces contraintes ne permettent pas l'ajout d'entrees dans
la table de routage, nous sommes d'accord.
Les informations situes dans le fichier ipsec-tools.conf sont
utilisees, mais n'apparaissent pas dans la table de routage.
Normal ce sont les spécifications des sélecteurs de politique de
sécurité qui vont largement au delà de ce que permet de modéliser une
table de routage.
Je n'ai pas pousse tres loin mon utilisation d'ipsec et des politiques
de securite, mais dans le cas d'un systeme linux, quelles operations
sont possibles avec les selecteurs de politiques que ne permettent pas
les outils netfilter + iproute2 + tunnel ?
Si tu veux une interface pour par exemple utiliser un protocole de
routage dynamique, tu jettes un oeil du coté d'IIPTran, RFC3884.
Merci pour l'information. Avec ce type de tunnel, redevient il possible
d'utiliser les outils classiques de routage et de filtrage (si j'ai bien
suivi, oui) ou faut il encore manipuler les tables de routage ET les
selecteurs de politique de securite lors d'ajout de regles de routage?
Dans ce cas je rebasculerais bien mes VPN sur ipsec!
D'apres ce que j'ai constate, aucune ligne n'est ajoutee a la table de routage, ce qui n'est vraiment pas pratique.
Nan, c'est complètement cohérent,
N'ai pas parle d'incoherence, juste du cote pratique :)
comment est-ce que tu spécifies dans un table de routage que seuls les paquets de type ipip sont soumis à une transformation ipsec quelque soit la destination de ceux-ci ?
Effectivement, ces contraintes ne permettent pas l'ajout d'entrees dans la table de routage, nous sommes d'accord.
Les informations situes dans le fichier ipsec-tools.conf sont utilisees, mais n'apparaissent pas dans la table de routage.
Normal ce sont les spécifications des sélecteurs de politique de sécurité qui vont largement au delà de ce que permet de modéliser une table de routage.
Je n'ai pas pousse tres loin mon utilisation d'ipsec et des politiques de securite, mais dans le cas d'un systeme linux, quelles operations sont possibles avec les selecteurs de politiques que ne permettent pas les outils netfilter + iproute2 + tunnel ?
Si tu veux une interface pour par exemple utiliser un protocole de routage dynamique, tu jettes un oeil du coté d'IIPTran, RFC3884.
Merci pour l'information. Avec ce type de tunnel, redevient il possible d'utiliser les outils classiques de routage et de filtrage (si j'ai bien suivi, oui) ou faut il encore manipuler les tables de routage ET les selecteurs de politique de securite lors d'ajout de regles de routage?
Dans ce cas je rebasculerais bien mes VPN sur ipsec!
Et un ping -S 192.168.50.254 192.168.51.254, ça donne quoi ? Si tu ne peux pas faire ce test, essaye de pinger depuis un autre hôte du lan vers une adresse située sur l'autre lan.
J'ai du mal à comprendre comme le tunnel peut fonctionner, si il n'y a pas d'interface virtuelle ni d'adresse sur la passerelle ?
La couche ipsec vérifie les paquets entrants par rapport à la SPD, si une règle est applicable alors le/les paquet(s) subi(ssen)t les transformations et il est/sont réinjecté(s) dans la pile.
-- C'est impossible que la majorité ait voté pour détruire le frjv sans créer un ou des autres NG. C'est incompréhensible... -+- AS in GNU : et pis d'abord les dinosaures y existent même pas -+-
Eric Belhomme <{rico}+no/spam@ricospirit.net> writes:
Et un ping -S 192.168.50.254 192.168.51.254, ça donne quoi ?
Si tu ne peux pas faire ce test, essaye de pinger depuis un autre hôte
du lan vers une adresse située sur l'autre lan.
J'ai du mal à comprendre comme le tunnel peut fonctionner, si il n'y a
pas d'interface virtuelle ni d'adresse sur la passerelle ?
La couche ipsec vérifie les paquets entrants par rapport à la SPD, si
une règle est applicable alors le/les paquet(s) subi(ssen)t les
transformations et il est/sont réinjecté(s) dans la pile.
--
C'est impossible que la majorité ait voté pour détruire le frjv sans
créer un ou des autres NG. C'est incompréhensible...
-+- AS in GNU : et pis d'abord les dinosaures y existent même pas -+-
Et un ping -S 192.168.50.254 192.168.51.254, ça donne quoi ? Si tu ne peux pas faire ce test, essaye de pinger depuis un autre hôte du lan vers une adresse située sur l'autre lan.
J'ai du mal à comprendre comme le tunnel peut fonctionner, si il n'y a pas d'interface virtuelle ni d'adresse sur la passerelle ?
La couche ipsec vérifie les paquets entrants par rapport à la SPD, si une règle est applicable alors le/les paquet(s) subi(ssen)t les transformations et il est/sont réinjecté(s) dans la pile.
-- C'est impossible que la majorité ait voté pour détruire le frjv sans créer un ou des autres NG. C'est incompréhensible... -+- AS in GNU : et pis d'abord les dinosaures y existent même pas -+-
Eric Belhomme
Eric Belhomme <{rico}+no/ wrote in news::
J'ai du mal à comprendre comme le tunnel peut fonctionner, si il n'y a pas d'interface virtuelle ni d'adresse sur la passerelle ?
je me réponds à moi même, et en profite pour vous donner quelques
précisions supplémentaires :
les réseaux 192.168.50.0/24 et 192.168.51.0/24 n'existent pas sur mes sites à joindre : ce sont des réseaux que j'ai mis là pour faire un routage intermédiaire entre les 2 passerelles ipsec, c'est par ca que je ne comprenait pas _comment_ IPsec pouvait router mes paquets...
Mais en lisant le document de Fred, j'ai vu qu'il rajoutait des routes dans les tables de routage de ces passerelles !
j'ai donc aliasé une adresse IP sur l'interface interne de de mes 2 passerelles :
# ip addr sh eth0 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:02:b3:28:8e:28 brd ff:ff:ff:ff:ff:ff inet 192.168.1.254/24 brd 192.168.1.255 scope global eth0 inet 192.168.50.254/24 brd 192.168.50.255 scope global eth0:1
Ce qui m'a permit de rajouter une route :
# ip route sh 192.168.51.0/24 via 192.168.50.254 dev eth0 192.168.50.0/24 dev eth0 proto kernel scope link src 192.168.50.254 default via x.x.x.a dev eth1
Du coup, racoon se montre beaucoup plus verbeux !
-- Rico
Eric Belhomme <{rico}+no/spam@ricospirit.net> wrote in
news:Xns987A76963F0AAericbelhommefreefr@212.27.60.38:
J'ai du mal à comprendre comme le tunnel peut fonctionner, si il n'y a
pas d'interface virtuelle ni d'adresse sur la passerelle ?
je me réponds à moi même, et en profite pour vous donner quelques
précisions supplémentaires :
les réseaux 192.168.50.0/24 et 192.168.51.0/24 n'existent pas sur mes
sites à joindre : ce sont des réseaux que j'ai mis là pour faire un
routage intermédiaire entre les 2 passerelles ipsec, c'est par ca que je
ne comprenait pas _comment_ IPsec pouvait router mes paquets...
Mais en lisant le document de Fred, j'ai vu qu'il rajoutait des routes
dans les tables de routage de ces passerelles !
j'ai donc aliasé une adresse IP sur l'interface interne de de mes 2
passerelles :
# ip addr sh eth0
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
1000
link/ether 00:02:b3:28:8e:28 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.254/24 brd 192.168.1.255 scope global eth0
inet 192.168.50.254/24 brd 192.168.50.255 scope global eth0:1
Ce qui m'a permit de rajouter une route :
# ip route sh
192.168.51.0/24 via 192.168.50.254 dev eth0
192.168.50.0/24 dev eth0 proto kernel scope link src 192.168.50.254
default via x.x.x.a dev eth1
J'ai du mal à comprendre comme le tunnel peut fonctionner, si il n'y a pas d'interface virtuelle ni d'adresse sur la passerelle ?
je me réponds à moi même, et en profite pour vous donner quelques
précisions supplémentaires :
les réseaux 192.168.50.0/24 et 192.168.51.0/24 n'existent pas sur mes sites à joindre : ce sont des réseaux que j'ai mis là pour faire un routage intermédiaire entre les 2 passerelles ipsec, c'est par ca que je ne comprenait pas _comment_ IPsec pouvait router mes paquets...
Mais en lisant le document de Fred, j'ai vu qu'il rajoutait des routes dans les tables de routage de ces passerelles !
j'ai donc aliasé une adresse IP sur l'interface interne de de mes 2 passerelles :
# ip addr sh eth0 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:02:b3:28:8e:28 brd ff:ff:ff:ff:ff:ff inet 192.168.1.254/24 brd 192.168.1.255 scope global eth0 inet 192.168.50.254/24 brd 192.168.50.255 scope global eth0:1
Ce qui m'a permit de rajouter une route :
# ip route sh 192.168.51.0/24 via 192.168.50.254 dev eth0 192.168.50.0/24 dev eth0 proto kernel scope link src 192.168.50.254 default via x.x.x.a dev eth1
