Salut,
Voilà, J'ai configuré mon pc portable avec un client ssh sur windows (ssh
sentinel)
Sentinel n'est PAS un client ssh mais un client IPSEC !!!
afin de pouvoir me connecter chez moi sur mon réseau LAn en créant
un vpn de type roadwarrior.
roadwarrior n'est pas un type de VPN c'est un type d'extrémité dans un
Chez moi j'ai un poste qui fait office de firewall avec IPCOP 1.6, c'est lui
qui établie la liaison VPN depuis la maison.
côté maison !
Lorsque je suis chez des clients configurés avec une adresse LAN Privée
(172.$.X.X par exemple), la connexion vpn se réalise corectement.
Par contre lorsque je suis chez des clients avec une plage d'adresse LAN
pulic (128.138.X.X par ex) le VPN ne s'établit pas.
La connexion échoue à partir de la phase 2.
J'aimerais savoir techniquement pourquoi ca ne marche pas et quelle solution
appporté à la resolution du probleme.
Salut,
Voilà, J'ai configuré mon pc portable avec un client ssh sur windows (ssh
sentinel)
Sentinel n'est PAS un client ssh mais un client IPSEC !!!
afin de pouvoir me connecter chez moi sur mon réseau LAn en créant
un vpn de type roadwarrior.
roadwarrior n'est pas un type de VPN c'est un type d'extrémité dans un
Chez moi j'ai un poste qui fait office de firewall avec IPCOP 1.6, c'est lui
qui établie la liaison VPN depuis la maison.
côté maison !
Lorsque je suis chez des clients configurés avec une adresse LAN Privée
(172.$.X.X par exemple), la connexion vpn se réalise corectement.
Par contre lorsque je suis chez des clients avec une plage d'adresse LAN
pulic (128.138.X.X par ex) le VPN ne s'établit pas.
La connexion échoue à partir de la phase 2.
J'aimerais savoir techniquement pourquoi ca ne marche pas et quelle solution
appporté à la resolution du probleme.
Salut,
Voilà, J'ai configuré mon pc portable avec un client ssh sur windows (ssh
sentinel)
Sentinel n'est PAS un client ssh mais un client IPSEC !!!
afin de pouvoir me connecter chez moi sur mon réseau LAn en créant
un vpn de type roadwarrior.
roadwarrior n'est pas un type de VPN c'est un type d'extrémité dans un
Chez moi j'ai un poste qui fait office de firewall avec IPCOP 1.6, c'est lui
qui établie la liaison VPN depuis la maison.
côté maison !
Lorsque je suis chez des clients configurés avec une adresse LAN Privée
(172.$.X.X par exemple), la connexion vpn se réalise corectement.
Par contre lorsque je suis chez des clients avec une plage d'adresse LAN
pulic (128.138.X.X par ex) le VPN ne s'établit pas.
La connexion échoue à partir de la phase 2.
J'aimerais savoir techniquement pourquoi ca ne marche pas et quelle solution
appporté à la resolution du probleme.
Salut,
Voilà, J'ai configuré mon pc portable avec un client ssh sur windows
(ssh sentinel)
Sentinel n'est PAS un client ssh mais un client IPSEC !!!
C'est un produit de la société SSH ça c'est vrai mais c'est un client
IPSEC. Du reste je pensais que ce produit avait disparu. J'en ai
encore quelques exemplaires mais ils datent de 2002 et je n'en ai
trouvé aucune trace sur le site de SSH.
Effectivement, en fait j'ai passé toute la journée à configurer un tunnel
afin de pouvoir me connecter chez moi sur mon réseau LAn en créant
un vpn de type roadwarrior.
roadwarrior n'est pas un type de VPN c'est un type d'extrémité dans un
VPN de n'importe quel type du reste.
Cela désigne simplement un nomade et donc une extrêmité disposant
d'une adresse non permanente et dynamique.
ok, merci pour la précison, je ne ferai plus l'erreur.
Chez moi j'ai un poste qui fait office de firewall avec IPCOP 1.6,
c'est lui qui établie la liaison VPN depuis la maison.
côté maison !
Oui, c'est coté maison que se trouve le firewall linux.
Lorsque je suis chez des clients configurés avec une adresse LAN
Privée (172.$.X.X par exemple), la connexion vpn se réalise
corectement. Par contre lorsque je suis chez des clients avec une
plage d'adresse LAN pulic (128.138.X.X par ex) le VPN ne s'établit
pas. La connexion échoue à partir de la phase 2.
J'aimerais savoir techniquement pourquoi ca ne marche pas et quelle
solution appporté à la resolution du probleme.
Déjà il serait intéressant de disposer des journaux côté Linux (niveau
full) afin de savoir ce qui ne fonctionne pas car les causes peuvent
être multiples à ce niveau. IPSEC est riche il ne faut pas l'oublier.
Parmi les causes envisageables :
- pas de translation du protocole ESP du côté de l'entreprise
(en général c'est plutôt un souci que l'on rencontre avec des
plages d'adressage privées mais bon s'il ny' a pas de
translation cela concerne aussi bien les privées que les
publiques) ;
- pb d'ID,
- pb de certif X509.
Ainsi que d'autres qui m'échappent à l'instant.
En règle générale on commence par regarder la log du FreeS/WAN qui est
très bien détaillée (*) justement pour aider au diagnostic.
db
(*) J'ai résolu pas mal de soucis avec des clients ou des serveurs
différents de FreeS/WAN grâce à elle : Raptor Firewall, SoftPK,
Sentinel, Racoon et ISAKMP.
Salut,
Voilà, J'ai configuré mon pc portable avec un client ssh sur windows
(ssh sentinel)
Sentinel n'est PAS un client ssh mais un client IPSEC !!!
C'est un produit de la société SSH ça c'est vrai mais c'est un client
IPSEC. Du reste je pensais que ce produit avait disparu. J'en ai
encore quelques exemplaires mais ils datent de 2002 et je n'en ai
trouvé aucune trace sur le site de SSH.
Effectivement, en fait j'ai passé toute la journée à configurer un tunnel
afin de pouvoir me connecter chez moi sur mon réseau LAn en créant
un vpn de type roadwarrior.
roadwarrior n'est pas un type de VPN c'est un type d'extrémité dans un
VPN de n'importe quel type du reste.
Cela désigne simplement un nomade et donc une extrêmité disposant
d'une adresse non permanente et dynamique.
ok, merci pour la précison, je ne ferai plus l'erreur.
Chez moi j'ai un poste qui fait office de firewall avec IPCOP 1.6,
c'est lui qui établie la liaison VPN depuis la maison.
côté maison !
Oui, c'est coté maison que se trouve le firewall linux.
Lorsque je suis chez des clients configurés avec une adresse LAN
Privée (172.$.X.X par exemple), la connexion vpn se réalise
corectement. Par contre lorsque je suis chez des clients avec une
plage d'adresse LAN pulic (128.138.X.X par ex) le VPN ne s'établit
pas. La connexion échoue à partir de la phase 2.
J'aimerais savoir techniquement pourquoi ca ne marche pas et quelle
solution appporté à la resolution du probleme.
Déjà il serait intéressant de disposer des journaux côté Linux (niveau
full) afin de savoir ce qui ne fonctionne pas car les causes peuvent
être multiples à ce niveau. IPSEC est riche il ne faut pas l'oublier.
Parmi les causes envisageables :
- pas de translation du protocole ESP du côté de l'entreprise
(en général c'est plutôt un souci que l'on rencontre avec des
plages d'adressage privées mais bon s'il ny' a pas de
translation cela concerne aussi bien les privées que les
publiques) ;
- pb d'ID,
- pb de certif X509.
Ainsi que d'autres qui m'échappent à l'instant.
En règle générale on commence par regarder la log du FreeS/WAN qui est
très bien détaillée (*) justement pour aider au diagnostic.
db
(*) J'ai résolu pas mal de soucis avec des clients ou des serveurs
différents de FreeS/WAN grâce à elle : Raptor Firewall, SoftPK,
Sentinel, Racoon et ISAKMP.
Salut,
Voilà, J'ai configuré mon pc portable avec un client ssh sur windows
(ssh sentinel)
Sentinel n'est PAS un client ssh mais un client IPSEC !!!
C'est un produit de la société SSH ça c'est vrai mais c'est un client
IPSEC. Du reste je pensais que ce produit avait disparu. J'en ai
encore quelques exemplaires mais ils datent de 2002 et je n'en ai
trouvé aucune trace sur le site de SSH.
Effectivement, en fait j'ai passé toute la journée à configurer un tunnel
afin de pouvoir me connecter chez moi sur mon réseau LAn en créant
un vpn de type roadwarrior.
roadwarrior n'est pas un type de VPN c'est un type d'extrémité dans un
VPN de n'importe quel type du reste.
Cela désigne simplement un nomade et donc une extrêmité disposant
d'une adresse non permanente et dynamique.
ok, merci pour la précison, je ne ferai plus l'erreur.
Chez moi j'ai un poste qui fait office de firewall avec IPCOP 1.6,
c'est lui qui établie la liaison VPN depuis la maison.
côté maison !
Oui, c'est coté maison que se trouve le firewall linux.
Lorsque je suis chez des clients configurés avec une adresse LAN
Privée (172.$.X.X par exemple), la connexion vpn se réalise
corectement. Par contre lorsque je suis chez des clients avec une
plage d'adresse LAN pulic (128.138.X.X par ex) le VPN ne s'établit
pas. La connexion échoue à partir de la phase 2.
J'aimerais savoir techniquement pourquoi ca ne marche pas et quelle
solution appporté à la resolution du probleme.
Déjà il serait intéressant de disposer des journaux côté Linux (niveau
full) afin de savoir ce qui ne fonctionne pas car les causes peuvent
être multiples à ce niveau. IPSEC est riche il ne faut pas l'oublier.
Parmi les causes envisageables :
- pas de translation du protocole ESP du côté de l'entreprise
(en général c'est plutôt un souci que l'on rencontre avec des
plages d'adressage privées mais bon s'il ny' a pas de
translation cela concerne aussi bien les privées que les
publiques) ;
- pb d'ID,
- pb de certif X509.
Ainsi que d'autres qui m'échappent à l'instant.
En règle générale on commence par regarder la log du FreeS/WAN qui est
très bien détaillée (*) justement pour aider au diagnostic.
db
(*) J'ai résolu pas mal de soucis avec des clients ou des serveurs
différents de FreeS/WAN grâce à elle : Raptor Firewall, SoftPK,
Sentinel, Racoon et ISAKMP.
Effectivement, en fait j'ai passé toute la journée à configurer un tunnel
ssh pour passer du netbios depuis chez moi en dépannage, en plus du nom
du client vpn :-( du coup ca m'est rester :-) dsl.
Pour la version ssh sentinel j'utlise une version de 2002 (1.4) j'ai
d'ailleurs eu quelques difficulté -- le trouver.
Ben je crois que ça n'existe plus. Dommage, il avait un firewall intégré
Donc niveau log:
[...]
Oct 24 15:07:23 gwadabox pluto[17835]: "west"[8] 81.80.18.X #14699:
cannot
respond to IPsec SA request because no connection is known for
192.168.16.0/24==.234.X.X...81.80.18.X[128.128.16.16]== > 128.128.16.16/32
Oct 24 15:07:23 gwadabox pluto[17835]: "west"[8] 81.80.18.X #14699:
sending
encrypted notification INVALID_ID_INFORMATION to 81.80.18.X:500
La log est claire : pb d'ID. Observe ta configuration côté Linux : tu
Effectivement, en fait j'ai passé toute la journée à configurer un tunnel
ssh pour passer du netbios depuis chez moi en dépannage, en plus du nom
du client vpn :-( du coup ca m'est rester :-) dsl.
Pour la version ssh sentinel j'utlise une version de 2002 (1.4) j'ai
d'ailleurs eu quelques difficulté -- le trouver.
Ben je crois que ça n'existe plus. Dommage, il avait un firewall intégré
Donc niveau log:
[...]
Oct 24 15:07:23 gwadabox pluto[17835]: "west"[8] 81.80.18.X #14699:
cannot
respond to IPsec SA request because no connection is known for
192.168.16.0/24==.234.X.X...81.80.18.X[128.128.16.16]== > 128.128.16.16/32
Oct 24 15:07:23 gwadabox pluto[17835]: "west"[8] 81.80.18.X #14699:
sending
encrypted notification INVALID_ID_INFORMATION to 81.80.18.X:500
La log est claire : pb d'ID. Observe ta configuration côté Linux : tu
Effectivement, en fait j'ai passé toute la journée à configurer un tunnel
ssh pour passer du netbios depuis chez moi en dépannage, en plus du nom
du client vpn :-( du coup ca m'est rester :-) dsl.
Pour la version ssh sentinel j'utlise une version de 2002 (1.4) j'ai
d'ailleurs eu quelques difficulté -- le trouver.
Ben je crois que ça n'existe plus. Dommage, il avait un firewall intégré
Donc niveau log:
[...]
Oct 24 15:07:23 gwadabox pluto[17835]: "west"[8] 81.80.18.X #14699:
cannot
respond to IPsec SA request because no connection is known for
192.168.16.0/24==.234.X.X...81.80.18.X[128.128.16.16]== > 128.128.16.16/32
Oct 24 15:07:23 gwadabox pluto[17835]: "west"[8] 81.80.18.X #14699:
sending
encrypted notification INVALID_ID_INFORMATION to 81.80.18.X:500
La log est claire : pb d'ID. Observe ta configuration côté Linux : tu
[...]Effectivement, en fait j'ai passé toute la journée à configurer un
tunnel ssh pour passer du netbios depuis chez moi en dépannage, en
plus du nom du client vpn :-( du coup ca m'est rester :-) dsl.
Pour la version ssh sentinel j'utlise une version de 2002 (1.4) j'ai
d'ailleurs eu quelques difficulté -- le trouver.
Ben je crois que ça n'existe plus. Dommage, il avait un firewall
intégré ce truc ainsi que le DHCP over IPSEC.
[...]Donc niveau log:
[...]Oct 24 15:07:23 gwadabox pluto[17835]: "west"[8] 81.80.18.X #14699:
cannot
respond to IPsec SA request because no connection is known for
192.168.16.0/24==.234.X.X...81.80.18.X[128.128.16.16]== >> 128.128.16.16/32
Oct 24 15:07:23 gwadabox pluto[17835]: "west"[8] 81.80.18.X #14699:
sending
encrypted notification INVALID_ID_INFORMATION to 81.80.18.X:500
La log est claire : pb d'ID. Observe ta configuration côté Linux : tu
n'as aucune rubrique conn permettant de satisfaire la SA construite
comme ceci :
Linux <-> nomade
128.128.16.16 -- 81.80.18.X <-> 82.234.x.X --- 192.168.16.0/24
C'est uniquement un problème déclaratif. Du moins à ce niveau.
Commence simplement :
n'utilise qu'un secret partagé pour débuter ;
évite le DHCPoverIPSEC ;
J'avais déjà essayer ça, l'orsque j'enleve le dhcp pour choisir mon ip
contente-toi d'un simple roadwarrior (qui n'a donc qu'une
adresse publique et un plan d'adressage) en acceptant
82.234.0.0/16 par exemple dans la déclaration de SA et
128.128.0.0/16 comme plan d'adressage du RW ;
et, SRUTOUT, vérifie le sens !
Px tu me détailler ce que tu vx dire ici ? comment ca qu'une adresse
Exemple :
Bon j'utilise des certif. car je n'ai pas retrouvé
de config à base de secret partagé. Mais la principe
est le même.
conn machin
leftid=@vpn.trucmuche.com #ID sous la forme d'un DNS
leftcert=newcerts/trucmcmCert.pem
left=%defaultroute #On accepte tout le monde
leftsubnet2.168.2.0/24 #Plan d'adr. au-delà du RW
leftnexthop= #Peu-importe la passerelle.
rightcert=newcerts/lyomcmCert.pem
right!3.41.x.y #Adr. publique du serveur.
rightsubnet2.168.1.0/24 #Plan d'adr au-delà du
serveur. #right!2.157.w.z #Passerelle côté
serveur. autod
keyingtries=0
db
Je ne sais pas si tu t'es trompé mais j'ai plus le linux avec l'adresse
[...]
Effectivement, en fait j'ai passé toute la journée à configurer un
tunnel ssh pour passer du netbios depuis chez moi en dépannage, en
plus du nom du client vpn :-( du coup ca m'est rester :-) dsl.
Pour la version ssh sentinel j'utlise une version de 2002 (1.4) j'ai
d'ailleurs eu quelques difficulté -- le trouver.
Ben je crois que ça n'existe plus. Dommage, il avait un firewall
intégré ce truc ainsi que le DHCP over IPSEC.
[...]
Donc niveau log:
[...]
Oct 24 15:07:23 gwadabox pluto[17835]: "west"[8] 81.80.18.X #14699:
cannot
respond to IPsec SA request because no connection is known for
192.168.16.0/24==.234.X.X...81.80.18.X[128.128.16.16]== >> 128.128.16.16/32
Oct 24 15:07:23 gwadabox pluto[17835]: "west"[8] 81.80.18.X #14699:
sending
encrypted notification INVALID_ID_INFORMATION to 81.80.18.X:500
La log est claire : pb d'ID. Observe ta configuration côté Linux : tu
n'as aucune rubrique conn permettant de satisfaire la SA construite
comme ceci :
Linux <-> nomade
128.128.16.16 -- 81.80.18.X <-> 82.234.x.X --- 192.168.16.0/24
C'est uniquement un problème déclaratif. Du moins à ce niveau.
Commence simplement :
n'utilise qu'un secret partagé pour débuter ;
évite le DHCPoverIPSEC ;
J'avais déjà essayer ça, l'orsque j'enleve le dhcp pour choisir mon ip
contente-toi d'un simple roadwarrior (qui n'a donc qu'une
adresse publique et un plan d'adressage) en acceptant
82.234.0.0/16 par exemple dans la déclaration de SA et
128.128.0.0/16 comme plan d'adressage du RW ;
et, SRUTOUT, vérifie le sens !
Px tu me détailler ce que tu vx dire ici ? comment ca qu'une adresse
Exemple :
Bon j'utilise des certif. car je n'ai pas retrouvé
de config à base de secret partagé. Mais la principe
est le même.
conn machin
leftid=@vpn.trucmuche.com #ID sous la forme d'un DNS
leftcert=newcerts/trucmcmCert.pem
left=%defaultroute #On accepte tout le monde
leftsubnet2.168.2.0/24 #Plan d'adr. au-delà du RW
leftnexthop= #Peu-importe la passerelle.
rightcert=newcerts/lyomcmCert.pem
right!3.41.x.y #Adr. publique du serveur.
rightsubnet2.168.1.0/24 #Plan d'adr au-delà du
serveur. #right!2.157.w.z #Passerelle côté
serveur. autod
keyingtries=0
db
Je ne sais pas si tu t'es trompé mais j'ai plus le linux avec l'adresse
[...]Effectivement, en fait j'ai passé toute la journée à configurer un
tunnel ssh pour passer du netbios depuis chez moi en dépannage, en
plus du nom du client vpn :-( du coup ca m'est rester :-) dsl.
Pour la version ssh sentinel j'utlise une version de 2002 (1.4) j'ai
d'ailleurs eu quelques difficulté -- le trouver.
Ben je crois que ça n'existe plus. Dommage, il avait un firewall
intégré ce truc ainsi que le DHCP over IPSEC.
[...]Donc niveau log:
[...]Oct 24 15:07:23 gwadabox pluto[17835]: "west"[8] 81.80.18.X #14699:
cannot
respond to IPsec SA request because no connection is known for
192.168.16.0/24==.234.X.X...81.80.18.X[128.128.16.16]== >> 128.128.16.16/32
Oct 24 15:07:23 gwadabox pluto[17835]: "west"[8] 81.80.18.X #14699:
sending
encrypted notification INVALID_ID_INFORMATION to 81.80.18.X:500
La log est claire : pb d'ID. Observe ta configuration côté Linux : tu
n'as aucune rubrique conn permettant de satisfaire la SA construite
comme ceci :
Linux <-> nomade
128.128.16.16 -- 81.80.18.X <-> 82.234.x.X --- 192.168.16.0/24
C'est uniquement un problème déclaratif. Du moins à ce niveau.
Commence simplement :
n'utilise qu'un secret partagé pour débuter ;
évite le DHCPoverIPSEC ;
J'avais déjà essayer ça, l'orsque j'enleve le dhcp pour choisir mon ip
contente-toi d'un simple roadwarrior (qui n'a donc qu'une
adresse publique et un plan d'adressage) en acceptant
82.234.0.0/16 par exemple dans la déclaration de SA et
128.128.0.0/16 comme plan d'adressage du RW ;
et, SRUTOUT, vérifie le sens !
Px tu me détailler ce que tu vx dire ici ? comment ca qu'une adresse
Exemple :
Bon j'utilise des certif. car je n'ai pas retrouvé
de config à base de secret partagé. Mais la principe
est le même.
conn machin
leftid=@vpn.trucmuche.com #ID sous la forme d'un DNS
leftcert=newcerts/trucmcmCert.pem
left=%defaultroute #On accepte tout le monde
leftsubnet2.168.2.0/24 #Plan d'adr. au-delà du RW
leftnexthop= #Peu-importe la passerelle.
rightcert=newcerts/lyomcmCert.pem
right!3.41.x.y #Adr. publique du serveur.
rightsubnet2.168.1.0/24 #Plan d'adr au-delà du
serveur. #right!2.157.w.z #Passerelle côté
serveur. autod
keyingtries=0
db
Je ne sais pas si tu t'es trompé mais j'ai plus le linux avec l'adresse