ds une pme de 60 personnes, le reseau est protege par un firewall chekpoint
celui ci en place depuis 3 ans remplit parfaitement son role
il a ete mis a jour regulierement en gros rien a lui reprocher
(sous contrat aupres d'une SSII)
cette pme a ouvert une agence de deux personnes et celle ci veulent acceder
au reseau de la maison mere pour acceder a un logiciel de gestion propre a
l'activite de la societe
la solution est un vpn a priori
mais quels sont les pre requis en debit et les solutions possibles
A savoir, il faut qque chose de transparent pour les utilisateurs de
l'agence, de fiable (qui ne soit pas a reparametrer tlj) et bien sur pas
trop cher (on va eviter l'installation d'un checkpoint pour 2 personnes)
j'ai bien sur pose la question a la ssii prestataire mais j'aimerais avoir
un avis de tierces personnes
merci d'etre accessible ds vos reponses
Le Wed, 25 Aug 2004 17:04:46 +0000, Fabien SPAGNOLO a écrit :
- certaines personnes ont réussi, d'après ce que j'ai pu entendre, à monter un VPN CheckPoint - RouteurADSL/FW/VPN Bintec. Mais je ne sais pas ce que ça vaut ...
Si les produits utilisez sont IPSEC compliant, il n'y a pas de raison pour qu'ils ne puissent pas interopérer, qu'il s'agisse de CheckPoint, Bintec, NetScreen, Win2k/XP, Free/SWAN, Open/SWAN, Racoon ou que sais-je.
Oh que si, il y a des raisons !!!
D'abord, les RFCs 240x font parties des plus complexes et bordeliques que j'aie jamais lues (en particulier les 2407 - 2408 - 2409). A tel point que l'un des principaux objectifs de IKEv2 est de simplifier tout ca, en commencant par virer les DOIs, merveille theorique d'encapsulation generique, uzine a gaz inutile en pratique.
Ensuite parceque certaines implementations font des choix pas toujours judicieux, ou en tout cas qui ne facilitent pas toujours l'interoperabilite avec d'autres produits (typiquement, des options activees automatiquement, non parametrables, non desactivables).
Apres, bien sur, il y a les extensions a IKE..... La, ca devient un massacre !
Entre les drafts du NAT-T, ou on implemente la premiere serie (00-01), la seconde serie (02-04, qui fait du port floating), ou la 3eme serie (05-+, qui n'est pas censee etre implementee parcequ'elle utilise des numeros IANA qui auraient du lui etre attribues, mais qui ont ete attribues a d'autres extensions), le DPD, ou il existe une RFC (plutot bien faite, quoique elle ne pousse pas assez l'idee a mon gout) que pratiquement personne n'utilise puisque a peu pres tout le monde utilise ses propres bricolages a coups d'extension d'IKE, de pings "maison" ou autre, les implementations qui forcent l'utilisation d'xauth, etc....
Enfin, bien sur, parcequ'il y a des bugs qui trainent parfois sur une implementation ou sur une autre..... tout simplement !
Et je suis bien place pour te confirmer que tout le monde s'empresse de dire "on est compatibles IPSec", mais que tout le monde (sauf peut etre les 2-3 gros leaders, qui s'en foutent ?) maintient a cote de ca une liste des implementations avec lesquels des tests ont ete faits, et le commentaire n'est pas toujours "ca marche nickel du premier coup" !!!
Le Wed, 25 Aug 2004 17:04:46 +0000, Fabien SPAGNOLO a écrit :
- certaines personnes ont réussi, d'après ce que j'ai pu entendre, à
monter un VPN CheckPoint - RouteurADSL/FW/VPN Bintec. Mais je ne sais
pas ce que ça vaut ...
Si les produits utilisez sont IPSEC compliant, il n'y a pas de raison
pour qu'ils ne puissent pas interopérer, qu'il s'agisse de CheckPoint,
Bintec, NetScreen, Win2k/XP, Free/SWAN, Open/SWAN, Racoon ou que sais-je.
Oh que si, il y a des raisons !!!
D'abord, les RFCs 240x font parties des plus complexes et bordeliques
que j'aie jamais lues (en particulier les 2407 - 2408 - 2409). A tel
point que l'un des principaux objectifs de IKEv2 est de simplifier
tout ca, en commencant par virer les DOIs, merveille theorique
d'encapsulation generique, uzine a gaz inutile en pratique.
Ensuite parceque certaines implementations font des choix pas toujours
judicieux, ou en tout cas qui ne facilitent pas toujours
l'interoperabilite avec d'autres produits (typiquement, des options
activees automatiquement, non parametrables, non desactivables).
Apres, bien sur, il y a les extensions a IKE.....
La, ca devient un massacre !
Entre les drafts du NAT-T, ou on implemente la premiere serie (00-01),
la seconde serie (02-04, qui fait du port floating), ou la 3eme serie
(05-+, qui n'est pas censee etre implementee parcequ'elle utilise des
numeros IANA qui auraient du lui etre attribues, mais qui ont ete
attribues a d'autres extensions), le DPD, ou il existe une RFC (plutot
bien faite, quoique elle ne pousse pas assez l'idee a mon gout) que
pratiquement personne n'utilise puisque a peu pres tout le monde
utilise ses propres bricolages a coups d'extension d'IKE, de pings
"maison" ou autre, les implementations qui forcent l'utilisation
d'xauth, etc....
Enfin, bien sur, parcequ'il y a des bugs qui trainent parfois sur une
implementation ou sur une autre..... tout simplement !
Et je suis bien place pour te confirmer que tout le monde s'empresse
de dire "on est compatibles IPSec", mais que tout le monde (sauf peut
etre les 2-3 gros leaders, qui s'en foutent ?) maintient a cote de ca
une liste des implementations avec lesquels des tests ont ete faits,
et le commentaire n'est pas toujours "ca marche nickel du premier
coup" !!!
Le Wed, 25 Aug 2004 17:04:46 +0000, Fabien SPAGNOLO a écrit :
- certaines personnes ont réussi, d'après ce que j'ai pu entendre, à monter un VPN CheckPoint - RouteurADSL/FW/VPN Bintec. Mais je ne sais pas ce que ça vaut ...
Si les produits utilisez sont IPSEC compliant, il n'y a pas de raison pour qu'ils ne puissent pas interopérer, qu'il s'agisse de CheckPoint, Bintec, NetScreen, Win2k/XP, Free/SWAN, Open/SWAN, Racoon ou que sais-je.
Oh que si, il y a des raisons !!!
D'abord, les RFCs 240x font parties des plus complexes et bordeliques que j'aie jamais lues (en particulier les 2407 - 2408 - 2409). A tel point que l'un des principaux objectifs de IKEv2 est de simplifier tout ca, en commencant par virer les DOIs, merveille theorique d'encapsulation generique, uzine a gaz inutile en pratique.
Ensuite parceque certaines implementations font des choix pas toujours judicieux, ou en tout cas qui ne facilitent pas toujours l'interoperabilite avec d'autres produits (typiquement, des options activees automatiquement, non parametrables, non desactivables).
Apres, bien sur, il y a les extensions a IKE..... La, ca devient un massacre !
Entre les drafts du NAT-T, ou on implemente la premiere serie (00-01), la seconde serie (02-04, qui fait du port floating), ou la 3eme serie (05-+, qui n'est pas censee etre implementee parcequ'elle utilise des numeros IANA qui auraient du lui etre attribues, mais qui ont ete attribues a d'autres extensions), le DPD, ou il existe une RFC (plutot bien faite, quoique elle ne pousse pas assez l'idee a mon gout) que pratiquement personne n'utilise puisque a peu pres tout le monde utilise ses propres bricolages a coups d'extension d'IKE, de pings "maison" ou autre, les implementations qui forcent l'utilisation d'xauth, etc....
Enfin, bien sur, parcequ'il y a des bugs qui trainent parfois sur une implementation ou sur une autre..... tout simplement !
Et je suis bien place pour te confirmer que tout le monde s'empresse de dire "on est compatibles IPSec", mais que tout le monde (sauf peut etre les 2-3 gros leaders, qui s'en foutent ?) maintient a cote de ca une liste des implementations avec lesquels des tests ont ete faits, et le commentaire n'est pas toujours "ca marche nickel du premier coup" !!!
A +
VANHU.
Cedric Blancher
Le Thu, 26 Aug 2004 07:36:55 +0000, VANHULLEBUS Yvan a écrit :
Et je suis bien place pour te confirmer que tout le monde s'empresse de dire "on est compatibles IPSec", mais que tout le monde (sauf peut etre les 2-3 gros leaders, qui s'en foutent ?) maintient a cote de ca une liste des implementations avec lesquels des tests ont ete faits, et le commentaire n'est pas toujours "ca marche nickel du premier coup" !!!
Évidemment, c'est une remarque qui tient du "chez moi ça marche", mais pour monter un lien IPSEC en mode tunnel, authentification PSK, pas de AH, ESP 3DES/HMAC-MD5, ça ne marche certes pas toujours de premier coup, mais je n'y ai jamais passé la journée, et ce, sur pas mal d'implémentations différentes.
Maintenant, si tu commences à attaquer les rois de l'extension propriétaire (on taira les noms) ou des trucs archi-tordus genre XAuth, t'es effectivement pas sorti de l'auberge...
Comme on dit : Keep It Stupid Simple...
-- BOFH excuse #320:
You've been infected by the Telescoping Hubble virus.
Le Thu, 26 Aug 2004 07:36:55 +0000, VANHULLEBUS Yvan a écrit :
Et je suis bien place pour te confirmer que tout le monde s'empresse
de dire "on est compatibles IPSec", mais que tout le monde (sauf peut
etre les 2-3 gros leaders, qui s'en foutent ?) maintient a cote de ca
une liste des implementations avec lesquels des tests ont ete faits,
et le commentaire n'est pas toujours "ca marche nickel du premier
coup" !!!
Évidemment, c'est une remarque qui tient du "chez moi ça marche", mais
pour monter un lien IPSEC en mode tunnel, authentification PSK, pas de
AH, ESP 3DES/HMAC-MD5, ça ne marche certes pas toujours de premier coup,
mais je n'y ai jamais passé la journée, et ce, sur pas mal
d'implémentations différentes.
Maintenant, si tu commences à attaquer les rois de l'extension
propriétaire (on taira les noms) ou des trucs archi-tordus genre
XAuth, t'es effectivement pas sorti de l'auberge...
Comme on dit : Keep It Stupid Simple...
--
BOFH excuse #320:
You've been infected by the Telescoping Hubble virus.
Le Thu, 26 Aug 2004 07:36:55 +0000, VANHULLEBUS Yvan a écrit :
Et je suis bien place pour te confirmer que tout le monde s'empresse de dire "on est compatibles IPSec", mais que tout le monde (sauf peut etre les 2-3 gros leaders, qui s'en foutent ?) maintient a cote de ca une liste des implementations avec lesquels des tests ont ete faits, et le commentaire n'est pas toujours "ca marche nickel du premier coup" !!!
Évidemment, c'est une remarque qui tient du "chez moi ça marche", mais pour monter un lien IPSEC en mode tunnel, authentification PSK, pas de AH, ESP 3DES/HMAC-MD5, ça ne marche certes pas toujours de premier coup, mais je n'y ai jamais passé la journée, et ce, sur pas mal d'implémentations différentes.
Maintenant, si tu commences à attaquer les rois de l'extension propriétaire (on taira les noms) ou des trucs archi-tordus genre XAuth, t'es effectivement pas sorti de l'auberge...
Comme on dit : Keep It Stupid Simple...
-- BOFH excuse #320:
You've been infected by the Telescoping Hubble virus.
Rasta
"Rasta" a écrit dans le message de news:412ca4f3$0$18611$
Bonjour, ...
la solution est un vpn a priori ....
j'ai bien sur pose la question a la ssii prestataire mais j'aimerais avoir un avis de tierces personnes merci d'etre accessible ds vos reponses
Merci pour vos reponse
certaines m'ont paru deroutantes ds les histoires de ipsec compliant et de rfc la ssii m'avait presente le client secure remote mais je ne suis pas pour ce n'est pas transparent il me semble plus simple de mettre un routeur firewall l'utilisation sera un acces a une base de donnees via tse et des impressions distantes le boitier checkpoint VPN1 -edge appliance me semble la meilleur solution car meme fournisseur (moins de probleme de compatibilite) par contre le prix doit qd meme etre elevee avez vous une idee de prix ? desole pur les accros de linux, mais n'ayant aucune competence en la matiere, j'hesite afranchir le part
Rasta
"Rasta" <Rastabis@free.fr> a écrit dans le message de
news:412ca4f3$0$18611$626a14ce@news.free.fr...
Bonjour,
...
la solution est un vpn a priori
....
j'ai bien sur pose la question a la ssii prestataire mais j'aimerais avoir
un avis de tierces personnes
merci d'etre accessible ds vos reponses
Merci pour vos reponse
certaines m'ont paru deroutantes ds les histoires de ipsec compliant et de
rfc
la ssii m'avait presente le client secure remote mais je ne suis pas pour
ce n'est pas transparent
il me semble plus simple de mettre un routeur firewall
l'utilisation sera un acces a une base de donnees via tse et des impressions
distantes
le boitier checkpoint VPN1 -edge appliance me semble la meilleur solution
car meme fournisseur
(moins de probleme de compatibilite) par contre le prix doit qd meme etre
elevee
avez vous une idee de prix ?
desole pur les accros de linux, mais n'ayant aucune competence en la
matiere, j'hesite afranchir le part
"Rasta" a écrit dans le message de news:412ca4f3$0$18611$
Bonjour, ...
la solution est un vpn a priori ....
j'ai bien sur pose la question a la ssii prestataire mais j'aimerais avoir un avis de tierces personnes merci d'etre accessible ds vos reponses
Merci pour vos reponse
certaines m'ont paru deroutantes ds les histoires de ipsec compliant et de rfc la ssii m'avait presente le client secure remote mais je ne suis pas pour ce n'est pas transparent il me semble plus simple de mettre un routeur firewall l'utilisation sera un acces a une base de donnees via tse et des impressions distantes le boitier checkpoint VPN1 -edge appliance me semble la meilleur solution car meme fournisseur (moins de probleme de compatibilite) par contre le prix doit qd meme etre elevee avez vous une idee de prix ? desole pur les accros de linux, mais n'ayant aucune competence en la matiere, j'hesite afranchir le part
Rasta
manu
Rasta wrote:
j'ai bien sur pose la question a la ssii prestataire mais j'aimerais avoir un avis de tierces personnes
Mon avis, c'est que le monde des VPN est assez frustrant, beaucoup de produits plus ou moins interoperables, et tout le monde pretends etre bien sécurisé et en fait il reste des trous béants.
La solution VPN entre deux LAN dotés chacun d'une passerelle est assez bien rodée. En IPsec avec des certificats, ou en SSL avec des certificats, c'est une affaire qui marche et qui va être assez bien interoperable. Attention toutefois aux implémentations qui v dealident l'autorité de certification mais pas de l'identité du certificat, c'est hélàs un classique.
Le cas des VPN pour accès distant d'usagers est nettement moins agréable. En IPsec, si on est dans la position où on peut donner des certificats sur smartcard aux usagers, je vois la chose assez favorablement, sinon c'est plus dur. Il faut eviter comme la peste tout ce qui est mode de passe de groupe (avec L2TP/IPsec ou Xauth/IPsec), c'est un désastre coté sécurité.
En bref, il est extremement facile de se faire refiler une solution pas sûre du tout mais qui prétends l'être. Hélàs.
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Rasta <Rastabis@free.fr> wrote:
j'ai bien sur pose la question a la ssii prestataire mais j'aimerais avoir
un avis de tierces personnes
Mon avis, c'est que le monde des VPN est assez frustrant, beaucoup de
produits plus ou moins interoperables, et tout le monde pretends etre
bien sécurisé et en fait il reste des trous béants.
La solution VPN entre deux LAN dotés chacun d'une passerelle est assez
bien rodée. En IPsec avec des certificats, ou en SSL avec des
certificats, c'est une affaire qui marche et qui va être assez bien
interoperable. Attention toutefois aux implémentations qui v dealident
l'autorité de certification mais pas de l'identité du certificat, c'est
hélàs un classique.
Le cas des VPN pour accès distant d'usagers est nettement moins
agréable. En IPsec, si on est dans la position où on peut donner des
certificats sur smartcard aux usagers, je vois la chose assez
favorablement, sinon c'est plus dur. Il faut eviter comme la peste tout
ce qui est mode de passe de groupe (avec L2TP/IPsec ou Xauth/IPsec),
c'est un désastre coté sécurité.
En bref, il est extremement facile de se faire refiler une solution pas
sûre du tout mais qui prétends l'être. Hélàs.
--
Emmanuel Dreyfus
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
j'ai bien sur pose la question a la ssii prestataire mais j'aimerais avoir un avis de tierces personnes
Mon avis, c'est que le monde des VPN est assez frustrant, beaucoup de produits plus ou moins interoperables, et tout le monde pretends etre bien sécurisé et en fait il reste des trous béants.
La solution VPN entre deux LAN dotés chacun d'une passerelle est assez bien rodée. En IPsec avec des certificats, ou en SSL avec des certificats, c'est une affaire qui marche et qui va être assez bien interoperable. Attention toutefois aux implémentations qui v dealident l'autorité de certification mais pas de l'identité du certificat, c'est hélàs un classique.
Le cas des VPN pour accès distant d'usagers est nettement moins agréable. En IPsec, si on est dans la position où on peut donner des certificats sur smartcard aux usagers, je vois la chose assez favorablement, sinon c'est plus dur. Il faut eviter comme la peste tout ce qui est mode de passe de groupe (avec L2TP/IPsec ou Xauth/IPsec), c'est un désastre coté sécurité.
En bref, il est extremement facile de se faire refiler une solution pas sûre du tout mais qui prétends l'être. Hélàs.
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
VANHULLEBUS Yvan
(Xavier) writes:
Vincent Bernat wrote:
D'ailleurs, devant l'absence de client du même type pour Mac OS X,
Ah ? Etonnant. Il y a un client PPTP *et* L2TP (Racoon en fait)
??????
Euh, racoon est le demon de negociation isakmp (pour IPSec, donc) de MacOS X (de KAME, en fait, utilise entre autres par MacOS X), il ne *fait pas* de PPTP, et meme le L2TP ca me surprendrait (et ca serait un dev specifique d'Apple).
Maintenant, peut etre qu'il y a bien un "truc" pour faire du PPTP/L2TP sous MacOSX, mais c'est certainement pas racoon !!!
Qu'est-ce que le client (/Applications/Internet Connect.app) ne fait pas ?
C'est vrai que jusqu'ici je ne l'ai utilisé qu'avec le serveur L2TP/IPSec de MacOSX Serveur, mais absolument sans auxun souci
DOnc il y a un "truc" pour faire du L2TP/IPSec sous MacOS X ?
Interessant.....
A +
VANHU.
xavier@groumpf.org (Xavier) writes:
Vincent Bernat <vincent.bernat@raysa.org> wrote:
D'ailleurs, devant l'absence de client du même type pour Mac OS X,
Ah ? Etonnant. Il y a un client PPTP *et* L2TP (Racoon en fait)
??????
Euh, racoon est le demon de negociation isakmp (pour IPSec, donc) de
MacOS X (de KAME, en fait, utilise entre autres par MacOS X), il ne
*fait pas* de PPTP, et meme le L2TP ca me surprendrait (et ca serait
un dev specifique d'Apple).
Maintenant, peut etre qu'il y a bien un "truc" pour faire du PPTP/L2TP
sous MacOSX, mais c'est certainement pas racoon !!!
Qu'est-ce que le client (/Applications/Internet Connect.app) ne fait
pas ?
C'est vrai que jusqu'ici je ne l'ai utilisé qu'avec le serveur
L2TP/IPSec de MacOSX Serveur, mais absolument sans auxun souci
DOnc il y a un "truc" pour faire du L2TP/IPSec sous MacOS X ?
D'ailleurs, devant l'absence de client du même type pour Mac OS X,
Ah ? Etonnant. Il y a un client PPTP *et* L2TP (Racoon en fait)
??????
Euh, racoon est le demon de negociation isakmp (pour IPSec, donc) de MacOS X (de KAME, en fait, utilise entre autres par MacOS X), il ne *fait pas* de PPTP, et meme le L2TP ca me surprendrait (et ca serait un dev specifique d'Apple).
Maintenant, peut etre qu'il y a bien un "truc" pour faire du PPTP/L2TP sous MacOSX, mais c'est certainement pas racoon !!!
Qu'est-ce que le client (/Applications/Internet Connect.app) ne fait pas ?
C'est vrai que jusqu'ici je ne l'ai utilisé qu'avec le serveur L2TP/IPSec de MacOSX Serveur, mais absolument sans auxun souci
DOnc il y a un "truc" pour faire du L2TP/IPSec sous MacOS X ?
Interessant.....
A +
VANHU.
Vincent Bernat
OoO En cette nuit nuageuse du vendredi 27 août 2004, vers 00:03, (Xavier) disait:
D'ailleurs, devant l'absence de client du même type pour Mac OS X,
Ah ? Etonnant. Il y a un client PPTP *et* L2TP (Racoon en fait)
Qu'est-ce que le client (/Applications/Internet Connect.app) ne fait pas ?
De l'IP sec "pur". Et cela rajoute trois couches d'encapsulation (UDP, PPP, L2TP). -- Don't over-comment. - The Elements of Programming Style (Kernighan & Plaugher)
OoO En cette nuit nuageuse du vendredi 27 août 2004, vers 00:03,
xavier@groumpf.org (Xavier) disait:
D'ailleurs, devant l'absence de client du même type pour Mac OS X,
Ah ? Etonnant. Il y a un client PPTP *et* L2TP (Racoon en fait)
Qu'est-ce que le client (/Applications/Internet Connect.app) ne fait
pas ?
De l'IP sec "pur". Et cela rajoute trois couches d'encapsulation (UDP,
PPP, L2TP).
--
Don't over-comment.
- The Elements of Programming Style (Kernighan & Plaugher)
OoO En cette nuit nuageuse du vendredi 27 août 2004, vers 00:03, (Xavier) disait:
D'ailleurs, devant l'absence de client du même type pour Mac OS X,
Ah ? Etonnant. Il y a un client PPTP *et* L2TP (Racoon en fait)
Qu'est-ce que le client (/Applications/Internet Connect.app) ne fait pas ?
De l'IP sec "pur". Et cela rajoute trois couches d'encapsulation (UDP, PPP, L2TP). -- Don't over-comment. - The Elements of Programming Style (Kernighan & Plaugher)
Alain Thivillon
Euh, racoon est le demon de negociation isakmp (pour IPSec, donc) de MacOS X (de KAME, en fait, utilise entre autres par MacOS X), il ne *fait pas* de PPTP, et meme le L2TP ca me surprendrait (et ca serait un dev specifique d'Apple).
On mélange tout la.
Qu'est-ce que le client (/Applications/Internet Connect.app) ne fait pas ?
C'est vrai que jusqu'ici je ne l'ai utilisé qu'avec le serveur L2TP/IPSec de MacOSX Serveur, mais absolument sans auxun souci
DOnc il y a un "truc" pour faire du L2TP/IPSec sous MacOS X ?
Ben oui, c'est LT2P dans un tunnel IPSEC : racoon monte l'ipsec et ensuite L2TP cause dedans ...
C'est compatible avec les machins windows et quelques firewalls dont de tete PIX, Sonicwall et Checkpoint récents.
-- Nom d'un chat de nom d'un chat !
Euh, racoon est le demon de negociation isakmp (pour IPSec, donc) de
MacOS X (de KAME, en fait, utilise entre autres par MacOS X), il ne
*fait pas* de PPTP, et meme le L2TP ca me surprendrait (et ca serait
un dev specifique d'Apple).
On mélange tout la.
Qu'est-ce que le client (/Applications/Internet Connect.app) ne fait
pas ?
C'est vrai que jusqu'ici je ne l'ai utilisé qu'avec le serveur
L2TP/IPSec de MacOSX Serveur, mais absolument sans auxun souci
DOnc il y a un "truc" pour faire du L2TP/IPSec sous MacOS X ?
Ben oui, c'est LT2P dans un tunnel IPSEC : racoon monte l'ipsec
et ensuite L2TP cause dedans ...
C'est compatible avec les machins windows et quelques firewalls
dont de tete PIX, Sonicwall et Checkpoint récents.
Euh, racoon est le demon de negociation isakmp (pour IPSec, donc) de MacOS X (de KAME, en fait, utilise entre autres par MacOS X), il ne *fait pas* de PPTP, et meme le L2TP ca me surprendrait (et ca serait un dev specifique d'Apple).
On mélange tout la.
Qu'est-ce que le client (/Applications/Internet Connect.app) ne fait pas ?
C'est vrai que jusqu'ici je ne l'ai utilisé qu'avec le serveur L2TP/IPSec de MacOSX Serveur, mais absolument sans auxun souci
DOnc il y a un "truc" pour faire du L2TP/IPSec sous MacOS X ?
Ben oui, c'est LT2P dans un tunnel IPSEC : racoon monte l'ipsec et ensuite L2TP cause dedans ...
C'est compatible avec les machins windows et quelques firewalls dont de tete PIX, Sonicwall et Checkpoint récents.
-- Nom d'un chat de nom d'un chat !
Benjamin Pineau
Le 26 Aug 2004 08:59:10 GMT, Cedric Blancher écrivais:
Évidemment, c'est une remarque qui tient du "chez moi ça marche", mais pour monter un lien IPSEC en mode tunnel, authentification PSK, pas de AH, ESP 3DES/HMAC-MD5, ça ne marche certes pas toujours de premier coup, mais je n'y ai jamais passé la journée, et ce, sur pas mal d'implémentations différentes.
Maintenant, si tu commences à attaquer les rois de l'extension propriétaire (on taira les noms) ou des trucs archi-tordus genre XAuth, t'es effectivement pas sorti de l'auberge...
Malheureusement dÃs qu'il faut composer avec une forte hÃtÃrogÃnÃità les aspects les plus ÃlÃmentaires d'IPsec peuvent eux mÃme constituer une source de difficultÃs importante, du moins si l'on cherche une solution relativement simple ou generique (post initial) :(
Avec, par exemple, d'un cotà une implÃm microsoft qui n'encourage pas vraiment l'utilisation du mode tunnel et de l'autre des implÃms libres oùle mode transport n'est pas toujours parfaitement about, oà ¹les implems d'l2tp sont pour ainsi dire inutilisables (et d'ailleur, qui veut utiliser lt2p ;) ...
Le 26 Aug 2004 08:59:10 GMT,
Cedric Blancher <blancher@cartel-securite.fr> écrivais:
Évidemment, c'est une remarque qui tient du "chez moi ça marche", mais
pour monter un lien IPSEC en mode tunnel, authentification PSK, pas de
AH, ESP 3DES/HMAC-MD5, ça ne marche certes pas toujours de premier coup,
mais je n'y ai jamais passé la journée, et ce, sur pas mal
d'implémentations différentes.
Maintenant, si tu commences à attaquer les rois de l'extension
propriétaire (on taira les noms) ou des trucs archi-tordus genre
XAuth, t'es effectivement pas sorti de l'auberge...
Malheureusement dÃs qu'il faut composer avec une forte hÃtÃrogÃnÃitÃ
les aspects les plus ÃlÃmentaires d'IPsec peuvent eux mÃme constituer
une source de difficultÃs importante, du moins si l'on cherche une
solution relativement simple ou generique (post initial) :(
Avec, par exemple, d'un cotà une implÃm microsoft qui n'encourage pas
vraiment l'utilisation du mode tunnel et de l'autre des implÃms libres
oùle mode transport n'est pas toujours parfaitement about, oà ¹les
implems d'l2tp sont pour ainsi dire inutilisables (et d'ailleur, qui
veut utiliser lt2p ;) ...
Le 26 Aug 2004 08:59:10 GMT, Cedric Blancher écrivais:
Évidemment, c'est une remarque qui tient du "chez moi ça marche", mais pour monter un lien IPSEC en mode tunnel, authentification PSK, pas de AH, ESP 3DES/HMAC-MD5, ça ne marche certes pas toujours de premier coup, mais je n'y ai jamais passé la journée, et ce, sur pas mal d'implémentations différentes.
Maintenant, si tu commences à attaquer les rois de l'extension propriétaire (on taira les noms) ou des trucs archi-tordus genre XAuth, t'es effectivement pas sorti de l'auberge...
Malheureusement dÃs qu'il faut composer avec une forte hÃtÃrogÃnÃità les aspects les plus ÃlÃmentaires d'IPsec peuvent eux mÃme constituer une source de difficultÃs importante, du moins si l'on cherche une solution relativement simple ou generique (post initial) :(
Avec, par exemple, d'un cotà une implÃm microsoft qui n'encourage pas vraiment l'utilisation du mode tunnel et de l'autre des implÃms libres oùle mode transport n'est pas toujours parfaitement about, oà ¹les implems d'l2tp sont pour ainsi dire inutilisables (et d'ailleur, qui veut utiliser lt2p ;) ...
D'ailleurs, devant l'absence de client du même type pour Mac OS X,
Ah ? Etonnant. Il y a un client PPTP *et* L2TP (Racoon en fait)
Huh ? racoon est seulement un serveur de clefs ISAKMP ...
Benjamin Pineau
Le 27 Aug 2004 08:30:08 GMT, Alain Thivillon écrivais:
DOnc il y a un "truc" pour faire du L2TP/IPSec sous MacOS X ?
Ben oui, c'est LT2P dans un tunnel IPSEC : racoon monte l'ipsec et ensuite L2TP cause dedans ...
Tient, c'est plutot interessant ! Apple fournis aussi un serveur l2tp (et le bouzingue ppp/radius/.. qui va avec) ou seulement le client ? et si serveur, est-il opensource et portable hors MacOS (disont, au moins sur des plateformes posix) ?
Le 27 Aug 2004 08:30:08 GMT,
Alain Thivillon <at@rominet.net> écrivais:
DOnc il y a un "truc" pour faire du L2TP/IPSec sous MacOS X ?
Ben oui, c'est LT2P dans un tunnel IPSEC : racoon monte l'ipsec
et ensuite L2TP cause dedans ...
Tient, c'est plutot interessant !
Apple fournis aussi un serveur l2tp (et le bouzingue ppp/radius/..
qui va avec) ou seulement le client ?
et si serveur, est-il opensource et portable hors MacOS (disont, au moins
sur des plateformes posix) ?
Le 27 Aug 2004 08:30:08 GMT, Alain Thivillon écrivais:
DOnc il y a un "truc" pour faire du L2TP/IPSec sous MacOS X ?
Ben oui, c'est LT2P dans un tunnel IPSEC : racoon monte l'ipsec et ensuite L2TP cause dedans ...
Tient, c'est plutot interessant ! Apple fournis aussi un serveur l2tp (et le bouzingue ppp/radius/.. qui va avec) ou seulement le client ? et si serveur, est-il opensource et portable hors MacOS (disont, au moins sur des plateformes posix) ?
