IPSEC natif sous Linux 2.6 (non respect longest-match)
5 réponses
db
Bonsoir,
Quelqu'un utilise-t-il régulièrement l'ipsec natif sous Linux 2.6 (avec ou
sans racoon et/ou isakmpd) ?
Hormis le fait que le tunnel n'apparaisse pas dans la table de routage (bon,
soit c'est pénible mas, à la rigueur, c'est un choix de conception) je
rencontre un pb bien plus grave : le non-respect de l'algorithme de longest
match !
En clair si j'ai le routage suivant :
10.1.0.0/16 sur eth0,
10.2.0.0/16 sur eth2,
10.3.0.0/16 sur eth3
et 10.10.10.0/24 sur eth1 (le plan d'adressage du réseau local distant à
l'extrémité du tunnel)
et que j'ajoute
10.0.0.0/8 sur eth1 (interface de sortie qui est donc l'interface VPN
également),
le noyau << oublie >> les autres entrées de la table et tout le monde
emprunte le tunnel.
C'est un peu gênant tout de même.
Je n'ai pas publié ceci sur une quelconque liste kernel car, d'une part, je
n'y suis pas abonné et d'autre part elles sont plutôt volumineuses et donc,
cela me semble disproportionné pour une telle remarque.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Patrick_91
db wrote:
Bonsoir,
Quelqu'un utilise-t-il régulièrement l'ipsec natif sous Linux 2.6 (avec ou sans racoon et/ou isakmpd) ?
Hormis le fait que le tunnel n'apparaisse pas dans la table de routage (bon, soit c'est pénible mas, à la rigueur, c'est un choix de conception) je rencontre un pb bien plus grave : le non-respect de l'algorithme de longest match !
En clair si j'ai le routage suivant : 10.1.0.0/16 sur eth0, 10.2.0.0/16 sur eth2, 10.3.0.0/16 sur eth3 et 10.10.10.0/24 sur eth1 (le plan d'adressage du réseau local distant à l'extrémité du tunnel)
et que j'ajoute 10.0.0.0/8 sur eth1 (interface de sortie qui est donc l'interface VPN également),
le noyau << oublie >> les autres entrées de la table et tout le monde emprunte le tunnel.
C'est un peu gênant tout de même.
Je n'ai pas publié ceci sur une quelconque liste kernel car, d'une part, je n'y suis pas abonné et d'autre part elles sont plutôt volumineuses et donc, cela me semble disproportionné pour une telle remarque.
db
Bonjour, Oui , que ce soit genant c'est sur, meme pire c'est annormal (the longest match) , mais le fait que l'interface VPN n'aparaisse pas dans la table de routage est une piste ... ca veut dire que l'algorithme de routage n'est pas invoqué et que tous les packets pour 10.0.0.0/8 sont routes via le vpn ? curieux !! ./.. Ca sent le bug en effet ... Amicalement
db wrote:
Bonsoir,
Quelqu'un utilise-t-il régulièrement l'ipsec natif sous Linux 2.6 (avec ou
sans racoon et/ou isakmpd) ?
Hormis le fait que le tunnel n'apparaisse pas dans la table de routage
(bon, soit c'est pénible mas, à la rigueur, c'est un choix de conception)
je rencontre un pb bien plus grave : le non-respect de l'algorithme de
longest match !
En clair si j'ai le routage suivant :
10.1.0.0/16 sur eth0,
10.2.0.0/16 sur eth2,
10.3.0.0/16 sur eth3
et 10.10.10.0/24 sur eth1 (le plan d'adressage du réseau local
distant à
l'extrémité du tunnel)
et que j'ajoute
10.0.0.0/8 sur eth1 (interface de sortie qui est donc l'interface
VPN
également),
le noyau << oublie >> les autres entrées de la table et tout le monde
emprunte le tunnel.
C'est un peu gênant tout de même.
Je n'ai pas publié ceci sur une quelconque liste kernel car, d'une part,
je n'y suis pas abonné et d'autre part elles sont plutôt volumineuses et
donc, cela me semble disproportionné pour une telle remarque.
db
Bonjour,
Oui , que ce soit genant c'est sur, meme pire c'est annormal (the longest
match) , mais le fait que l'interface VPN n'aparaisse pas dans la table de
routage est une piste ... ca veut dire que l'algorithme de routage n'est
pas invoqué et que tous les packets pour 10.0.0.0/8 sont routes via le
vpn ? curieux !! ./..
Ca sent le bug en effet ...
Amicalement
Quelqu'un utilise-t-il régulièrement l'ipsec natif sous Linux 2.6 (avec ou sans racoon et/ou isakmpd) ?
Hormis le fait que le tunnel n'apparaisse pas dans la table de routage (bon, soit c'est pénible mas, à la rigueur, c'est un choix de conception) je rencontre un pb bien plus grave : le non-respect de l'algorithme de longest match !
En clair si j'ai le routage suivant : 10.1.0.0/16 sur eth0, 10.2.0.0/16 sur eth2, 10.3.0.0/16 sur eth3 et 10.10.10.0/24 sur eth1 (le plan d'adressage du réseau local distant à l'extrémité du tunnel)
et que j'ajoute 10.0.0.0/8 sur eth1 (interface de sortie qui est donc l'interface VPN également),
le noyau << oublie >> les autres entrées de la table et tout le monde emprunte le tunnel.
C'est un peu gênant tout de même.
Je n'ai pas publié ceci sur une quelconque liste kernel car, d'une part, je n'y suis pas abonné et d'autre part elles sont plutôt volumineuses et donc, cela me semble disproportionné pour une telle remarque.
db
Bonjour, Oui , que ce soit genant c'est sur, meme pire c'est annormal (the longest match) , mais le fait que l'interface VPN n'aparaisse pas dans la table de routage est une piste ... ca veut dire que l'algorithme de routage n'est pas invoqué et que tous les packets pour 10.0.0.0/8 sont routes via le vpn ? curieux !! ./.. Ca sent le bug en effet ... Amicalement
j3CubL4H
salut, essaye malgré tout de faire remonter cette info... c'est important... JM.
"Patrick_91" a écrit dans le message de news: c8n2if$mdp$
db wrote:
Bonsoir,
Quelqu'un utilise-t-il régulièrement l'ipsec natif sous Linux 2.6 (avec ou
sans racoon et/ou isakmpd) ?
Hormis le fait que le tunnel n'apparaisse pas dans la table de routage (bon, soit c'est pénible mas, à la rigueur, c'est un choix de conception)
je rencontre un pb bien plus grave : le non-respect de l'algorithme de longest match !
En clair si j'ai le routage suivant : 10.1.0.0/16 sur eth0, 10.2.0.0/16 sur eth2, 10.3.0.0/16 sur eth3 et 10.10.10.0/24 sur eth1 (le plan d'adressage du réseau local distant à l'extrémité du tunnel)
et que j'ajoute 10.0.0.0/8 sur eth1 (interface de sortie qui est donc l'interface
VPN également),
le noyau << oublie >> les autres entrées de la table et tout le monde emprunte le tunnel.
C'est un peu gênant tout de même.
Je n'ai pas publié ceci sur une quelconque liste kernel car, d'une part, je n'y suis pas abonné et d'autre part elles sont plutôt volumineuses et donc, cela me semble disproportionné pour une telle remarque.
db
Bonjour, Oui , que ce soit genant c'est sur, meme pire c'est annormal (the longest match) , mais le fait que l'interface VPN n'aparaisse pas dans la table de routage est une piste ... ca veut dire que l'algorithme de routage n'est pas invoqué et que tous les packets pour 10.0.0.0/8 sont routes via le vpn ? curieux !! ./.. Ca sent le bug en effet ... Amicalement
salut, essaye malgré tout de faire remonter cette info...
c'est important...
JM.
"Patrick_91" <patrick_91@nospam.com> a écrit dans le message de news:
c8n2if$mdp$1@news-reader5.wanadoo.fr...
db wrote:
Bonsoir,
Quelqu'un utilise-t-il régulièrement l'ipsec natif sous Linux 2.6 (avec
ou
sans racoon et/ou isakmpd) ?
Hormis le fait que le tunnel n'apparaisse pas dans la table de routage
(bon, soit c'est pénible mas, à la rigueur, c'est un choix de
conception)
je rencontre un pb bien plus grave : le non-respect de l'algorithme de
longest match !
En clair si j'ai le routage suivant :
10.1.0.0/16 sur eth0,
10.2.0.0/16 sur eth2,
10.3.0.0/16 sur eth3
et 10.10.10.0/24 sur eth1 (le plan d'adressage du réseau local
distant à
l'extrémité du tunnel)
et que j'ajoute
10.0.0.0/8 sur eth1 (interface de sortie qui est donc
l'interface
VPN
également),
le noyau << oublie >> les autres entrées de la table et tout le monde
emprunte le tunnel.
C'est un peu gênant tout de même.
Je n'ai pas publié ceci sur une quelconque liste kernel car, d'une part,
je n'y suis pas abonné et d'autre part elles sont plutôt volumineuses et
donc, cela me semble disproportionné pour une telle remarque.
db
Bonjour,
Oui , que ce soit genant c'est sur, meme pire c'est annormal (the longest
match) , mais le fait que l'interface VPN n'aparaisse pas dans la table de
routage est une piste ... ca veut dire que l'algorithme de routage n'est
pas invoqué et que tous les packets pour 10.0.0.0/8 sont routes via le
vpn ? curieux !! ./..
Ca sent le bug en effet ...
Amicalement
salut, essaye malgré tout de faire remonter cette info... c'est important... JM.
"Patrick_91" a écrit dans le message de news: c8n2if$mdp$
db wrote:
Bonsoir,
Quelqu'un utilise-t-il régulièrement l'ipsec natif sous Linux 2.6 (avec ou
sans racoon et/ou isakmpd) ?
Hormis le fait que le tunnel n'apparaisse pas dans la table de routage (bon, soit c'est pénible mas, à la rigueur, c'est un choix de conception)
je rencontre un pb bien plus grave : le non-respect de l'algorithme de longest match !
En clair si j'ai le routage suivant : 10.1.0.0/16 sur eth0, 10.2.0.0/16 sur eth2, 10.3.0.0/16 sur eth3 et 10.10.10.0/24 sur eth1 (le plan d'adressage du réseau local distant à l'extrémité du tunnel)
et que j'ajoute 10.0.0.0/8 sur eth1 (interface de sortie qui est donc l'interface
VPN également),
le noyau << oublie >> les autres entrées de la table et tout le monde emprunte le tunnel.
C'est un peu gênant tout de même.
Je n'ai pas publié ceci sur une quelconque liste kernel car, d'une part, je n'y suis pas abonné et d'autre part elles sont plutôt volumineuses et donc, cela me semble disproportionné pour une telle remarque.
db
Bonjour, Oui , que ce soit genant c'est sur, meme pire c'est annormal (the longest match) , mais le fait que l'interface VPN n'aparaisse pas dans la table de routage est une piste ... ca veut dire que l'algorithme de routage n'est pas invoqué et que tous les packets pour 10.0.0.0/8 sont routes via le vpn ? curieux !! ./.. Ca sent le bug en effet ... Amicalement
T0t0
"db" wrote in message news:40aea468$0$21559$
En clair si j'ai le routage suivant : 10.1.0.0/16 sur eth0, 10.2.0.0/16 sur eth2, 10.3.0.0/16 sur eth3 et 10.10.10.0/24 sur eth1 (le plan d'adressage du réseau local distant à l'extrémité du tunnel) et que j'ajoute 10.0.0.0/8 sur eth1 (interface de sortie qui est donc l'interface VPN également),
Et que donne "ip rule list" ? Et après "ip route list table xxx" ? xxx étant les tables qui ont été listées dans la première commande
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"db" <nospam@spam.int> wrote in message
news:40aea468$0$21559$626a14ce@news.free.fr
En clair si j'ai le routage suivant :
10.1.0.0/16 sur eth0,
10.2.0.0/16 sur eth2,
10.3.0.0/16 sur eth3
et 10.10.10.0/24 sur eth1 (le plan d'adressage du réseau local distant à
l'extrémité du tunnel)
et que j'ajoute
10.0.0.0/8 sur eth1 (interface de sortie qui est donc l'interface VPN
également),
Et que donne "ip rule list" ?
Et après "ip route list table xxx" ? xxx étant les tables qui ont été
listées dans la première commande
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
En clair si j'ai le routage suivant : 10.1.0.0/16 sur eth0, 10.2.0.0/16 sur eth2, 10.3.0.0/16 sur eth3 et 10.10.10.0/24 sur eth1 (le plan d'adressage du réseau local distant à l'extrémité du tunnel) et que j'ajoute 10.0.0.0/8 sur eth1 (interface de sortie qui est donc l'interface VPN également),
Et que donne "ip rule list" ? Et après "ip route list table xxx" ? xxx étant les tables qui ont été listées dans la première commande
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
db
db wrote:
Je me réponds finalement à moi-même pour confirmer que ce comportement est normal en IPSEC natif sous 2.6. Sous KLIPS pour 2.6 qui sort actuellement (prebeta de Nate) le comportement reste traditionnel (longest match). En IPSEC natif sous 2.6 la règle du longest match n'est pas mise à la poubelle. Simplement il y a cette histoire de politique IPSEC distinte de la politique de routage. Et donc, le fait d'ajouter une politique IPSEC qui précise que la route du tunnel est 10.0.0.0/8 signifie que tout ce qui est à destination de 10.0.0.0/8 est encapsulé IPSEC (on n'a pas touché pas à la table de routage là) donc forcément les machines du réseau local n'apprécient pas trop de recevoir de l'IPSEC sans y être convier et personne ne répond donc. La solution consiste à écrire une règle d'exclusion précisant que l'on ne désire pas d'IPSEC pour le plan d'adressage local. Et là ça tourne. Ce que j'écris là est évident mais bon fallait que ça déclenche là-haut ...
A noter que openswan 2 manipule désormais (depuis la 2.1.x) les politiques SPD directement. Ainsi un seul fichier de configuration suffit (ipsec.conf) au lieu de 2 sous racoon ou isakmpd (setkey et racoon.conf).
db
Bonsoir,
Quelqu'un utilise-t-il régulièrement l'ipsec natif sous Linux 2.6 (avec ou sans racoon et/ou isakmpd) ?
Hormis le fait que le tunnel n'apparaisse pas dans la table de routage (bon, soit c'est pénible mas, à la rigueur, c'est un choix de conception) je rencontre un pb bien plus grave : le non-respect de l'algorithme de longest match !
En clair si j'ai le routage suivant : 10.1.0.0/16 sur eth0, 10.2.0.0/16 sur eth2, 10.3.0.0/16 sur eth3 et 10.10.10.0/24 sur eth1 (le plan d'adressage du réseau local distant à l'extrémité du tunnel)
et que j'ajoute 10.0.0.0/8 sur eth1 (interface de sortie qui est donc l'interface VPN également),
le noyau << oublie >> les autres entrées de la table et tout le monde emprunte le tunnel.
C'est un peu gênant tout de même.
Je n'ai pas publié ceci sur une quelconque liste kernel car, d'une part, je n'y suis pas abonné et d'autre part elles sont plutôt volumineuses et donc, cela me semble disproportionné pour une telle remarque.
db
-- email : usenet blas net
db wrote:
Je me réponds finalement à moi-même pour confirmer que ce comportement est
normal en IPSEC natif sous 2.6.
Sous KLIPS pour 2.6 qui sort actuellement (prebeta de Nate) le comportement
reste traditionnel (longest match).
En IPSEC natif sous 2.6 la règle du longest match n'est pas mise à la
poubelle. Simplement il y a cette histoire de politique IPSEC distinte de
la politique de routage.
Et donc, le fait d'ajouter une politique IPSEC qui précise que la route du
tunnel est 10.0.0.0/8 signifie que tout ce qui est à destination de
10.0.0.0/8 est encapsulé IPSEC (on n'a pas touché pas à la table de routage
là) donc forcément les machines du réseau local n'apprécient pas trop de
recevoir de l'IPSEC sans y être convier et personne ne répond donc.
La solution consiste à écrire une règle d'exclusion précisant que l'on ne
désire pas d'IPSEC pour le plan d'adressage local.
Et là ça tourne.
Ce que j'écris là est évident mais bon fallait que ça déclenche là-haut ...
A noter que openswan 2 manipule désormais (depuis la 2.1.x) les politiques
SPD directement.
Ainsi un seul fichier de configuration suffit (ipsec.conf) au lieu de 2
sous racoon ou isakmpd (setkey et racoon.conf).
db
Bonsoir,
Quelqu'un utilise-t-il régulièrement l'ipsec natif sous Linux 2.6 (avec ou
sans racoon et/ou isakmpd) ?
Hormis le fait que le tunnel n'apparaisse pas dans la table de routage
(bon, soit c'est pénible mas, à la rigueur, c'est un choix de conception)
je rencontre un pb bien plus grave : le non-respect de l'algorithme de
longest match !
En clair si j'ai le routage suivant :
10.1.0.0/16 sur eth0,
10.2.0.0/16 sur eth2,
10.3.0.0/16 sur eth3
et 10.10.10.0/24 sur eth1 (le plan d'adressage du réseau local
distant à
l'extrémité du tunnel)
et que j'ajoute
10.0.0.0/8 sur eth1 (interface de sortie qui est donc l'interface
VPN
également),
le noyau << oublie >> les autres entrées de la table et tout le monde
emprunte le tunnel.
C'est un peu gênant tout de même.
Je n'ai pas publié ceci sur une quelconque liste kernel car, d'une part,
je n'y suis pas abonné et d'autre part elles sont plutôt volumineuses et
donc, cela me semble disproportionné pour une telle remarque.
Je me réponds finalement à moi-même pour confirmer que ce comportement est normal en IPSEC natif sous 2.6. Sous KLIPS pour 2.6 qui sort actuellement (prebeta de Nate) le comportement reste traditionnel (longest match). En IPSEC natif sous 2.6 la règle du longest match n'est pas mise à la poubelle. Simplement il y a cette histoire de politique IPSEC distinte de la politique de routage. Et donc, le fait d'ajouter une politique IPSEC qui précise que la route du tunnel est 10.0.0.0/8 signifie que tout ce qui est à destination de 10.0.0.0/8 est encapsulé IPSEC (on n'a pas touché pas à la table de routage là) donc forcément les machines du réseau local n'apprécient pas trop de recevoir de l'IPSEC sans y être convier et personne ne répond donc. La solution consiste à écrire une règle d'exclusion précisant que l'on ne désire pas d'IPSEC pour le plan d'adressage local. Et là ça tourne. Ce que j'écris là est évident mais bon fallait que ça déclenche là-haut ...
A noter que openswan 2 manipule désormais (depuis la 2.1.x) les politiques SPD directement. Ainsi un seul fichier de configuration suffit (ipsec.conf) au lieu de 2 sous racoon ou isakmpd (setkey et racoon.conf).
db
Bonsoir,
Quelqu'un utilise-t-il régulièrement l'ipsec natif sous Linux 2.6 (avec ou sans racoon et/ou isakmpd) ?
Hormis le fait que le tunnel n'apparaisse pas dans la table de routage (bon, soit c'est pénible mas, à la rigueur, c'est un choix de conception) je rencontre un pb bien plus grave : le non-respect de l'algorithme de longest match !
En clair si j'ai le routage suivant : 10.1.0.0/16 sur eth0, 10.2.0.0/16 sur eth2, 10.3.0.0/16 sur eth3 et 10.10.10.0/24 sur eth1 (le plan d'adressage du réseau local distant à l'extrémité du tunnel)
et que j'ajoute 10.0.0.0/8 sur eth1 (interface de sortie qui est donc l'interface VPN également),
le noyau << oublie >> les autres entrées de la table et tout le monde emprunte le tunnel.
C'est un peu gênant tout de même.
Je n'ai pas publié ceci sur une quelconque liste kernel car, d'une part, je n'y suis pas abonné et d'autre part elles sont plutôt volumineuses et donc, cela me semble disproportionné pour une telle remarque.
db
-- email : usenet blas net
T0t0
"db" wrote in message news:40aea468$0$21559$
En clair si j'ai le routage suivant : 10.1.0.0/16 sur eth0, 10.2.0.0/16 sur eth2, 10.3.0.0/16 sur eth3 et 10.10.10.0/24 sur eth1 (le plan d'adressage du réseau local distant à l'extrémité du tunnel) et que j'ajoute 10.0.0.0/8 sur eth1 (interface de sortie qui est donc l'interface VPN également), le noyau << oublie >> les autres entrées de la table et tout le monde emprunte le tunnel.
Et que donnent les commandes: ip rule list ip route list
PS: Je suis obligé de mettre du bla bla en plus sinon le message n'est pas approuvé par mailgate car le ratio texte ajouté/texte d'origine est trop faible... voilà :-)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"db" <nospam@spam.int> wrote in message
news:40aea468$0$21559$626a14ce@news.free.fr
En clair si j'ai le routage suivant :
10.1.0.0/16 sur eth0,
10.2.0.0/16 sur eth2,
10.3.0.0/16 sur eth3
et 10.10.10.0/24 sur eth1 (le plan d'adressage du réseau local distant à
l'extrémité du tunnel)
et que j'ajoute
10.0.0.0/8 sur eth1 (interface de sortie qui est donc l'interface VPN
également), le noyau << oublie >> les autres entrées de la table et tout le monde
emprunte le tunnel.
Et que donnent les commandes:
ip rule list
ip route list
PS: Je suis obligé de mettre du bla bla en plus sinon le message n'est
pas approuvé par mailgate car le ratio texte ajouté/texte d'origine est
trop faible... voilà :-)
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
En clair si j'ai le routage suivant : 10.1.0.0/16 sur eth0, 10.2.0.0/16 sur eth2, 10.3.0.0/16 sur eth3 et 10.10.10.0/24 sur eth1 (le plan d'adressage du réseau local distant à l'extrémité du tunnel) et que j'ajoute 10.0.0.0/8 sur eth1 (interface de sortie qui est donc l'interface VPN également), le noyau << oublie >> les autres entrées de la table et tout le monde emprunte le tunnel.
Et que donnent les commandes: ip rule list ip route list
PS: Je suis obligé de mettre du bla bla en plus sinon le message n'est pas approuvé par mailgate car le ratio texte ajouté/texte d'origine est trop faible... voilà :-)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
