Re: Re: Support for L2TP/IPsec

[Paul Wouters]

OK, could you please double-check that your configuration works with
strongswan as well as openswan? I want to propose that we focus on one
IKE implementation and considering the features available in strongswan,
that it works with the most server implementations especially Windows
2003 and 2008 Server and that it supports smartcards the best make it a
lead contender. Dan, what do you think of deciding on an IKE? Something
like a bake-off?


There is no reason to pick one over the other.


Is strongswan a fork of openswan?  If so, was openswan upstream
reluctant to take certain patches and thus the strongswan fork?



There is a lot of material about strongswan and openswan's development
history in http://www.strongswan.org/docs/LinuxTag2008-strongSwan.pdf
Even a nice tree of the forks.


As the person who was the liason between John Gilmore of FreeS/WAN
and one of the founders of Openswan, I can tell you that "history"
is pretty wrong.


It seems that strongswan and openswan both split away from frees/wan for
different reasons: openswan was the branch that Xelerance developed for
their commercial network services and strongswan was community developed
to keep making a better linux IKEv1 and then v2 implementation.


That sounds pretty misleading

After talks with John Gilmore it was decided amicably to fork freeswan
to get rid of the "no americans can code for freeswan" reqirement of
freeswan. Andreas was invited to be part of the openswan fork, but
could not get over the fact that freeswan/openswan kept a Makefile.inc
style structure where you can disable/enable features. He felt his
code "should not be #ifdef'ed". Since a lot of people do not use or
need X.509 we wanted to keep the #ifdef's, just like we have those in
place for XAUTH, PAM, Opportunistic, etc. Andreas then decided to start
his own fork.

Xelerance was the company founded by freeswan volunteers and ex-employees
of the freeswan project to continue the GPL IPsec implementation and
to additionally offer commercial support. It has extended Openswan
functionality with contracts from companies like RedHat, Sony, HiFN,
Astaro, Ixia, etc. Xelerance has no "commercial network services".


Is there an intention to merge strongswan back into openswan in the
future?  That sort of thing.  Unfortunately the politics matter to
distros...


There is not much to merge. strongswan is using two seperate IKEv1
and IKEv2 daemons, while openswan has integrated IKEv2 fully into one
daemon. Openswan reguarly checks for fixes done by strongswan, and where
appropriate merged them in (with I should say, proper creditation,
something we unfortunately cannot say about strongswan's merging of
openswan's patches)

xl2tpd is a fork of l2tpd by Xelerance after that project seemed to be
dead for over a year, their domain squatted and their sourceforge.net
repository stale and not accepting any code. Jacco de Leeuw kept an
impressive patch set against l2tpd-0.69, and we finally forked to merge
in his patches, our patches and new features such as IPsec SAref support
to support overlapping IP's as shown in :

http://www.openswan.org/docs/ipsecsaref.png

We would gladly help network manager's integration for l2tp/ipsec based VPN's.
Please feel free to mail any questions or information to [EMAIL PROTECTED],
or hang around on the #openswan-dev channel on freenode.

Paul
--
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Support for L2TP/IPsec

[Dan Williams]

On Fri, 2008-06-27 at 21:55 +0200, Vincent Bernat wrote:
> OoO En ce  doux début de matinée  du samedi 24 mai 2008,  vers 08:44, je
> disais:
> 
> >> We might have to patch xl2tpd then; I understand why they did it, but
> >> passing files around is just broken.
> 
> > Hi Dan!
> 
> > I will propose a patch for xl2tpd to be able to do anything from command
> > line (for a  client only) and I  will try to push the  patch upstream. I
> > keep you in touch.
> 
> Hi Dan!
> 
> I have proposed a patch to  upstream that would allow to use xl2tpd just
> like pppd. I attach the patch  to this message. xl2tpd should be invoked
> like this:
>  xl2tpd --simple  
> 
> This  patch needs  more work.  For example,  if the  host  is incorrect,
> xl2tpd will  just wait forever but  I think this  is a good start  for a
> prototype.

It should probably exit with a specific return code if the host can't be
reached or can't be found via DNS.

But yes, looks like a good start.  This would be acceptable for NM to
use (as long as we don't need to pass secrets to it on the
command-line); even better would be reading the config from stdin like
vpnc.  But this patch certainly removes the need for non-trivial and
error-prone temporary config file creation and cleanup.

Thanks!
Dan

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Support for L2TP/IPsec

[Vincent Bernat]

OoO En ce  doux début de matinée  du samedi 24 mai 2008,  vers 08:44, je
disais:

>> We might have to patch xl2tpd then; I understand why they did it, but
>> passing files around is just broken.

> Hi Dan!

> I will propose a patch for xl2tpd to be able to do anything from command
> line (for a  client only) and I  will try to push the  patch upstream. I
> keep you in touch.

Hi Dan!

I have proposed a patch to  upstream that would allow to use xl2tpd just
like pppd. I attach the patch  to this message. xl2tpd should be invoked
like this:
 xl2tpd --simple  

This  patch needs  more work.  For example,  if the  host  is incorrect,
xl2tpd will  just wait forever but  I think this  is a good start  for a
prototype.

diff --git a/doc/xl2tpd.8 b/doc/xl2tpd.8
index fa86355..b2b8f47 100644
--- a/doc/xl2tpd.8
+++ b/doc/xl2tpd.8
@@ -40,6 +40,12 @@ Tells xl2tpd to use an alternate pid file.  Default is
 Tells xl2tpd to use an alternate control file.  Default is
 /var/run/xl2tpd/l2tp-control
 
+.TP 
+.B --simple host args
+Tells xl2tpd to connect to "host" and pass the given args to pppd.
+This mode prevents xl2tpd to daemonize itself. It is aimed at allowing
+LAC connection without any config file.
+
 
 .SH "FILES"
 
diff --git a/file.c b/file.c
index 3072022..b84183c 100644
--- a/file.c
+++ b/file.c
@@ -33,6 +33,9 @@ struct global gconfig;
 char filerr[STRLEN];
 
 int parse_config (FILE *);
+struct lac *new_lac ();
+int set_lns (char *word, char *value, int context, void *item);
+int set_autodial (char *word, char *value, int context, void *item);
 struct keyword words[];
 
 int init_config ()
@@ -51,6 +54,14 @@ int init_config ()
 laclist = NULL;
 deflac = (struct lac *) malloc (sizeof (struct lac));
 
+if (gconfig.simple)
+{
+laclist = new_lac();
+strncpy(laclist->entname, gconfig.host, sizeof(laclist->entname));
+set_lns("lns", gconfig.host, CONTEXT_LAC, laclist);
+set_autodial("autodial", "yes", CONTEXT_LAC, laclist);
+return 0;
+}
 f = fopen (gconfig.configfile, "r");
 if (!f) 
 {
diff --git a/file.h b/file.h
index f5488e5..06074a7 100644
--- a/file.h
+++ b/file.h
@@ -153,6 +153,10 @@ struct global
 int debug_tunnel;		/* Print tunnel debugging info? */
 int debug_state;		/* Print FSM debugging info? */
 int ipsecsaref;
+int simple; /* Simple LAC mode */
+char host[STRLEN];  /* Host to connect in simple LAC mode */
+char **pppdargs;/* Args for pppd */
+int pppdargs_c;
 };
 
 extern struct global gconfig;   /* Global configuration options */
diff --git a/xl2tpd.c b/xl2tpd.c
index a423101..a3aef34 100644
--- a/xl2tpd.c
+++ b/xl2tpd.c
@@ -295,6 +295,7 @@ int start_pppd (struct call *c, struct ppp_opts *opts)
 char tty[512];
 char *stropt[80];
 struct ppp_opts *p;
+char **q;
 #ifdef USE_KERNEL
 struct sockaddr_pppol2tp sax;
 int flags;
@@ -317,6 +318,18 @@ int start_pppd (struct call *c, struct ppp_opts *opts)
 pos++;
 p = p->next;
 }
+if (gconfig.simple)
+{
+q = gconfig.pppdargs;
+while(gconfig.pppdargs_c)
+{
+stropt[pos] = (char *) malloc (strlen (*q) + 1);
+strncpy (stropt[pos], *q, strlen (*q) + 1);
+pos++;
+q++;
+gconfig.pppdargs_c--;
+}
+}
 stropt[pos] = NULL;
 if (c->pppd > 0)
 {
@@ -1027,7 +1040,7 @@ void do_control ()
 
 void usage(void) {
 printf("\nxl2tpd version:  %s\n",SERVER_VERSION);
-printf("Usage: xl2tpd [-c ] [-s ] [-p ]  \n [-C ] [-D]\n");
+printf("Usage: xl2tpd [--simple host args | [-c ] [-s ] [-p ]  \n [-C ] [-D]]\n");
 printf("\n");
 exit(1);
 }
@@ -1056,12 +1069,31 @@ void init_args(int argc, char *argv[])
 strncpy(gconfig.controlfile,CONTROL_PIPE,
 sizeof(gconfig.controlfile) - 1);
 gconfig.ipsecsaref = 0;
+gconfig.simple = 0;
+memset(gconfig.host,0,STRLEN);
+gconfig.pppdargs = NULL;
+gconfig.pppdargs_c = 0;
 
 for (i = 1; i < argc; i++) {
 if (! strncmp(argv[i],"--version",9)) {
 printf("\nxl2tpd version:  %s\n",SERVER_VERSION);
 exit(1);
 }
+if (! strncmp(argv[i],"--simple",6)) {
+if (i != 1)
+usage();
+else if (++i == argc)
+usage();
+else {
+strncpy(gconfig.host,argv[i],
+sizeof(gconfig.host) - 1);
+gconfig.pppdargs = &argv[++i];
+gconfig.pppdargs_c = argc-3;
+gconfig.daemon = 0;
+gconfig.simple = 1;
+break;
+}
+}
 
 if(! strncmp(argv[i],"-c",2)) {
 if(++i == argc)
-- 
Don't patch bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)
___
NetworkManager-list mailing list
NetworkMana

Re: Support for L2TP/IPsec

[Dan Williams]

On Mon, 2008-06-02 at 10:57 +0900, David Smith wrote:
> Dan Williams <[EMAIL PROTECTED]> writes:
> 
> > On Sun, 2008-05-25 at 20:19 +0900, David Smith wrote:
> >> Vincent Bernat <[EMAIL PROTECTED]> writes:
> >> 
> >> > OoO En cette  aube naissante du dimanche 25 mai  2008, vers 07:10, David
> >> > Smith <[EMAIL PROTECTED]> disait:
> >> >
> >> >> Vincent, in your setup is there a strong reason you are using openswan
> >> >> instead of strongswan? Please share.
> >> >
> >> > Hi David!
> >> >
> >> > I have not tried StrongSWAN, so I have no reason to use OpenSWAN instead
> >> > of StrongSWAN.
> >> 
> >> OK, could you please double-check that your configuration works with
> >> strongswan as well as openswan? I want to propose that we focus on one
> >> IKE implementation and considering the features available in strongswan,
> >> that it works with the most server implementations especially Windows
> >> 2003 and 2008 Server and that it supports smartcards the best make it a
> >> lead contender. Dan, what do you think of deciding on an IKE? Something
> >> like a bake-off?
> >
> > It mostly depends on what the various distros will be willing to
> > package.  I don't have a strong preference since I know next to nothing
> > about either of them.  But if we "bless" one then we have to have a
> > pretty convincing story as to why we chose one over the other, so that
> > we can tell that story to distros when they start asking why they need
> > to package something else that has roughly the same functionality as
> > something they already have.
> >
> > Is strongswan a fork of openswan?  If so, was openswan upstream
> > reluctant to take certain patches and thus the strongswan fork?
> 
> There is a lot of material about strongswan and openswan's development
> history in http://www.strongswan.org/docs/LinuxTag2008-strongSwan.pdf
> . Even a nice tree of the forks.
> 
> It seems that strongswan and openswan both split away from frees/wan for
> different reasons: openswan was the branch that Xelerance developed for
> their commercial network services and strongswan was community developed
> to keep making a better linux IKEv1 and then v2 implementation.
> 
> > Is there an intention to merge strongswan back into openswan in the
> > future?  That sort of thing.  Unfortunately the politics matter to
> > distros...
> 
> Nobody on either list has hinted at anything like that, though
> anything's possible.

If they can co-exist then we're probably OK, I guess.

Dan

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Support for L2TP/IPsec

[David Smith]

Dan Williams <[EMAIL PROTECTED]> writes:

> On Sun, 2008-05-25 at 20:19 +0900, David Smith wrote:
>> Vincent Bernat <[EMAIL PROTECTED]> writes:
>> 
>> > OoO En cette  aube naissante du dimanche 25 mai  2008, vers 07:10, David
>> > Smith <[EMAIL PROTECTED]> disait:
>> >
>> >> Vincent, in your setup is there a strong reason you are using openswan
>> >> instead of strongswan? Please share.
>> >
>> > Hi David!
>> >
>> > I have not tried StrongSWAN, so I have no reason to use OpenSWAN instead
>> > of StrongSWAN.
>> 
>> OK, could you please double-check that your configuration works with
>> strongswan as well as openswan? I want to propose that we focus on one
>> IKE implementation and considering the features available in strongswan,
>> that it works with the most server implementations especially Windows
>> 2003 and 2008 Server and that it supports smartcards the best make it a
>> lead contender. Dan, what do you think of deciding on an IKE? Something
>> like a bake-off?
>
> It mostly depends on what the various distros will be willing to
> package.  I don't have a strong preference since I know next to nothing
> about either of them.  But if we "bless" one then we have to have a
> pretty convincing story as to why we chose one over the other, so that
> we can tell that story to distros when they start asking why they need
> to package something else that has roughly the same functionality as
> something they already have.
>
> Is strongswan a fork of openswan?  If so, was openswan upstream
> reluctant to take certain patches and thus the strongswan fork?

There is a lot of material about strongswan and openswan's development
history in http://www.strongswan.org/docs/LinuxTag2008-strongSwan.pdf
. Even a nice tree of the forks.

It seems that strongswan and openswan both split away from frees/wan for
different reasons: openswan was the branch that Xelerance developed for
their commercial network services and strongswan was community developed
to keep making a better linux IKEv1 and then v2 implementation.

> Is there an intention to merge strongswan back into openswan in the
> future?  That sort of thing.  Unfortunately the politics matter to
> distros...

Nobody on either list has hinted at anything like that, though
anything's possible.

- dds



pgpeg3CIQmCUV.pgp
Description: PGP signature
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Support for L2TP/IPsec

[Vincent Bernat]

OoO Vers  la fin de l'après-midi du  mardi 27 mai 2008,  vers 16:03, Dan
Williams <[EMAIL PROTECTED]> disait:

> Is strongswan a fork of openswan?  If so, was openswan upstream
> reluctant to take certain patches and thus the strongswan fork?  Is
> there an intention to merge strongswan back into openswan in the future?
> That sort of thing.  Unfortunately the politics matter to distros...

I don't have  why strongswan exists along side  openswan. OpenSWAN has a
strong  tie to  L2TP  because  Xelerance (which  is  the company  behind
OpenSWAN) is  editing xl2tpd as  well and is  planning to publish  a new
version of  OpenSWAN able to  cooperate with OpenSWAN. However,  this is
only  important for running  a server.  On client  side, I  don't really
think this is important.
-- 
 /* Nobody will ever see this message :-) */
panic("Cannot initialize video hardware\n");
2.0.38 /usr/src/linux/arch/m68k/atari/atafb.c
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Support for L2TP/IPsec

[Vincent Bernat]

OoO Peu  avant le début  de l'après-midi du  dimanche 25 mai  2008, vers
13:19, David Smith <[EMAIL PROTECTED]> disait:

>> I have not tried StrongSWAN, so I have no reason to use OpenSWAN instead
>> of StrongSWAN.

> OK, could you please double-check that your configuration works with
> strongswan as well as openswan? I want to propose that we focus on one
> IKE implementation and considering the features available in strongswan,
> that it works with the most server implementations especially Windows
> 2003 and 2008 Server and that it supports smartcards the best make it a
> lead contender.

Hi David!

I have just  tested and the configuration that I  posted here works fine
with StrongSWAN (you just  need to comment nhelpers directive). However,
my VPN endpoint is OpenSWAN (which  works fine with Windows and Mac OS X
clients).   I   have  no  experience  with  Windows   2003/2008  as  VPN
server. And I cannot test smartcards stuff.

StrongSWAN disables transport mode:
 003  "XXX" #2:  NAT-Traversal: Transport  Mode not  allowed  due to
 security concerns -- using Tunnel mode

I  don't  think  that  is  something  that should  be  remarked  by  the
server. Therefore, there should be no problem.

If  you run  into  difficulties  with StrongSWAN,  here  is another  IKE
implementation that don't need configuration files:
 http://www.shrew.net/?page=software
However, I think that it won't support things like smartcards.
-- 
No fortunes found
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Support for L2TP/IPsec

[David Smith]

Vincent Bernat <[EMAIL PROTECTED]> writes:

> OoO En cette  aube naissante du dimanche 25 mai  2008, vers 07:10, David
> Smith <[EMAIL PROTECTED]> disait:
>
>> Vincent, in your setup is there a strong reason you are using openswan
>> instead of strongswan? Please share.
>
> Hi David!
>
> I have not tried StrongSWAN, so I have no reason to use OpenSWAN instead
> of StrongSWAN.

OK, could you please double-check that your configuration works with
strongswan as well as openswan? I want to propose that we focus on one
IKE implementation and considering the features available in strongswan,
that it works with the most server implementations especially Windows
2003 and 2008 Server and that it supports smartcards the best make it a
lead contender. Dan, what do you think of deciding on an IKE? Something
like a bake-off?

- dds

<#secure method=pgpmime mode=sign>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Support for L2TP/IPsec

[Vincent Bernat]

OoO En cette  aube naissante du dimanche 25 mai  2008, vers 07:10, David
Smith <[EMAIL PROTECTED]> disait:

> Vincent, in your setup is there a strong reason you are using openswan
> instead of strongswan? Please share.

Hi David!

I have not tried StrongSWAN, so I have no reason to use OpenSWAN instead
of StrongSWAN.
-- 
No fortunes found
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Support for L2TP/IPsec

[David Smith]

Dan Williams <[EMAIL PROTECTED]> writes:

> On Fri, 2008-05-23 at 21:29 +0200, Vincent Bernat wrote:
>> OoO  En ce  début de  soirée du  vendredi 23  mai 2008,  vers  21:23, je
>> disais:
>> 
>> > Well, this would be a bit difficult. There others IKE daemon that may be
>> > configured this way:
>> >  - isakmpd from OpenBSD accepts  to be enterily configured using a named
>> >pipe
>> >  - iked from  Shrew Soft VPN client has an IKE  daemon that also accepts
>> >to be configured in a similar way
>> 
>> Another thing to  know about those IKE daemons is that  only one can run
>> on the system.  Therefore, contrary to PPTP, we cannot  just spawn a new
>> one  for each  connection. The  same IKE  daemon can  handle  many IPsec
>> tunnels.
>
> That gets interesting, and that means that we need to be able to talk to
> the IKE daemon directly using a socket or something so we can have it
> bring the tunnels up or down, and so that we can get status when a
> tunnel dies or whatever.  The last one is pretty critical, so that we
> can notify the user that something has happened and that's why their VPN
> is no longer working.

I have been working on adding enough support to configure an L2TP/IPsec
connection remotely against a running strongswan pluto IKE daemon using
strongswan's whack utility. It doesn't work quite yet and I'm debating,
instead, to implement dbus support directly in pluto to support dynamic
configuration.

But this is an important time to say that if we were to have an openswan
vs. strongswan debate, strongswan supports pkcs#11 API smartcards which
means it can be used with OpenSC supported smartcards as well as
gnome-keyring and openCryptoki (i.e. TPM chip). On the other hand,
openswan only supports OpenSC supported smartcards which is a very
strong limitation going forward. Dan, this is another part of
networkmanager where in the future it will be important to support
smartcards instead of certificates and keys on disk.

Vincent, in your setup is there a strong reason you are using openswan
instead of strongswan? Please share.

Cheers,
dds

>
>
> ___
> NetworkManager-list mailing list
> NetworkManager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
<#secure method=pgpmime mode=sign>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Support for L2TP/IPsec

[Vincent Bernat]

OoO La  nuit ayant  déjà recouvert  d'encre ce jour  du vendredi  23 mai
2008, vers 23:25, Dan Williams <[EMAIL PROTECTED]> disait:

> We might have to patch xl2tpd then; I understand why they did it, but
> passing files around is just broken.

Hi Dan!

I will propose a patch for xl2tpd to be able to do anything from command
line (for a  client only) and I  will try to push the  patch upstream. I
keep you in touch.
-- 
Use the good features of a language; avoid the bad ones.
- The Elements of Programming Style (Kernighan & Plauger)
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Support for L2TP/IPsec

[Dan Williams]

On Fri, 2008-05-23 at 21:23 +0200, Vincent Bernat wrote:
> OoO En  cette nuit  nuageuse du  vendredi 23 mai  2008, vers  00:20, Dan
> Williams <[EMAIL PROTECTED]> disait:
> 
> >> LT2P/IPsec becomes a popular choice for setting up VPN. Security is greater
> >> than PPTP solutions and clients are included in Windows and Mac OS X.
> >> Unfortunately, this is quite difficult to setup on Linux. Having a plugin
> >> for network-manager will be great.
> 
> > So we need a few things from openswan.  The first is to either accept
> > command-line arguments for configuration, or to accept configuration
> > from stdin and not from a file.  There's quite a few reasons why we
> > shouldn't be writing out a config file, and there's more reasons why we
> > shouldn't be pointing openswan at an existing config file.
> 
> Well, this would be a bit difficult. There others IKE daemon that may be
> configured this way:
>  - isakmpd from OpenBSD accepts  to be enterily configured using a named
>pipe
>  - iked from  Shrew Soft VPN client has an IKE  daemon that also accepts
>to be configured in a similar way
> 
> I will test  if one of them  is able to establish a  proper IPsec tunnel
> suitable for L2TP/IPsec.
> 
> >> - setup L2TP part with xl2tpd (which needs ppp)
> 
> > Hmm, we'll need to control xl2tpd then too, but we'll need to be able to
> > tell it what options to pass to pppd, not give it a config file.  We
> > also need to be able to feed secrets to it over stdin or via a plugin if
> > possible.  This is what's done for pppd, since pppd allows plugins to
> > handle the authentication.
> 
> xl2tpd can either use a plugin for pppd and do the authentication itself
> or just  let pppd do the  authentication. So the actual  plugin for pppd
> will do the trick.  Concerning pppd options, unfortunately, xl2tpd seems
> to have no other options than to pass a file to pppd.

We might have to patch xl2tpd then; I understand why they did it, but
passing files around is just broken.

> > The problem with config files is that we'd be writing them out every
> > time we launch the daemon, because the VPN settings come from a variety
> > of sources.  They are pulled from the user's session store (GConf on
> > Gnome) or from system settings, they don't get stored in the native
> > daemons config files.
> 
> Can't we write temporary files? xl2tpd accepts to take any configuration
> file.

We _could_, but it's ugly.  You simply can't clean them up with any
certainty.  If you've every had to deal with .pid files, you know what I
mean.  You want to tie the configuration to the lifetime of the process
that's actually using that configuration, and have that configuration go
away when the process that's using it dies or quits.  If you write temp
files, you don't have that guarantee, and you end up with stale temp
files if something doesn't work right.  At least wit pppd, all the
options we care about can be passed on the pppd command line, so it
wouldn't be that hard to have xl2tpd handle those on it's command line
too.

Another issue with config files is password leakage.  If you write out a
config file that must contain the password (like a session-specific chap
secrets file), and something happens and NM or the process that's
responsible for cleaning that file up quits or segfaults without
cleaning it up, then you've got your password sitting around on the
disk.  Not cool.  Using stdin for config is the best way to handle this
because secrets don't get written out anywhere.

Dan


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Support for L2TP/IPsec

[Dan Williams]

On Fri, 2008-05-23 at 21:29 +0200, Vincent Bernat wrote:
> OoO  En ce  début de  soirée du  vendredi 23  mai 2008,  vers  21:23, je
> disais:
> 
> > Well, this would be a bit difficult. There others IKE daemon that may be
> > configured this way:
> >  - isakmpd from OpenBSD accepts  to be enterily configured using a named
> >pipe
> >  - iked from  Shrew Soft VPN client has an IKE  daemon that also accepts
> >to be configured in a similar way
> 
> Another thing to  know about those IKE daemons is that  only one can run
> on the system.  Therefore, contrary to PPTP, we cannot  just spawn a new
> one  for each  connection. The  same IKE  daemon can  handle  many IPsec
> tunnels.

That gets interesting, and that means that we need to be able to talk to
the IKE daemon directly using a socket or something so we can have it
bring the tunnels up or down, and so that we can get status when a
tunnel dies or whatever.  The last one is pretty critical, so that we
can notify the user that something has happened and that's why their VPN
is no longer working.

Dan


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Support for L2TP/IPsec

[Dan Williams]

On Fri, 2008-05-23 at 21:32 +0200, Vincent Bernat wrote:
> OoO  En ce  début de  soirée du  vendredi 23  mai 2008,  vers  21:29, je
> disais:
> 
> >> Well, this would be a bit difficult. There others IKE daemon that may be
> >> configured this way:
> >> - isakmpd from OpenBSD accepts  to be enterily configured using a named
> >> pipe
> >> - iked from  Shrew Soft VPN client has an IKE  daemon that also accepts
> >> to be configured in a similar way
> 
> > Another thing to  know about those IKE daemons is that  only one can run
> > on the system.  Therefore, contrary to PPTP, we cannot  just spawn a new
> > one  for each  connection. The  same IKE  daemon can  handle  many IPsec
> > tunnels.
> 
> Oh, and this  is the same problem for xl2tpd: UDP  packets are from port
> 1701 to port 1701. So, only one daemon for the whole system.

That's just evil.  But, since we only support one VPN connection anyway
right now, not that big of a deal.  I'd like to change that in the
future though...

Dan

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Support for L2TP/IPsec

[Vincent Bernat]

OoO  En ce  début de  soirée du  vendredi 23  mai 2008,  vers  21:29, je
disais:

>> Well, this would be a bit difficult. There others IKE daemon that may be
>> configured this way:
>> - isakmpd from OpenBSD accepts  to be enterily configured using a named
>> pipe
>> - iked from  Shrew Soft VPN client has an IKE  daemon that also accepts
>> to be configured in a similar way

> Another thing to  know about those IKE daemons is that  only one can run
> on the system.  Therefore, contrary to PPTP, we cannot  just spawn a new
> one  for each  connection. The  same IKE  daemon can  handle  many IPsec
> tunnels.

Oh, and this  is the same problem for xl2tpd: UDP  packets are from port
1701 to port 1701. So, only one daemon for the whole system.
-- 
BOFH excuse #198:
Post-it Note Sludge leaked into the monitor.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Support for L2TP/IPsec

[Vincent Bernat]

OoO  En ce  début de  soirée du  vendredi 23  mai 2008,  vers  21:23, je
disais:

> Well, this would be a bit difficult. There others IKE daemon that may be
> configured this way:
>  - isakmpd from OpenBSD accepts  to be enterily configured using a named
>pipe
>  - iked from  Shrew Soft VPN client has an IKE  daemon that also accepts
>to be configured in a similar way

Another thing to  know about those IKE daemons is that  only one can run
on the system.  Therefore, contrary to PPTP, we cannot  just spawn a new
one  for each  connection. The  same IKE  daemon can  handle  many IPsec
tunnels.
-- 
BOFH excuse #9:
doppler effect
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Support for L2TP/IPsec

[Vincent Bernat]

OoO En  cette nuit  nuageuse du  vendredi 23 mai  2008, vers  00:20, Dan
Williams <[EMAIL PROTECTED]> disait:

>> LT2P/IPsec becomes a popular choice for setting up VPN. Security is greater
>> than PPTP solutions and clients are included in Windows and Mac OS X.
>> Unfortunately, this is quite difficult to setup on Linux. Having a plugin
>> for network-manager will be great.

> So we need a few things from openswan.  The first is to either accept
> command-line arguments for configuration, or to accept configuration
> from stdin and not from a file.  There's quite a few reasons why we
> shouldn't be writing out a config file, and there's more reasons why we
> shouldn't be pointing openswan at an existing config file.

Well, this would be a bit difficult. There others IKE daemon that may be
configured this way:
 - isakmpd from OpenBSD accepts  to be enterily configured using a named
   pipe
 - iked from  Shrew Soft VPN client has an IKE  daemon that also accepts
   to be configured in a similar way

I will test  if one of them  is able to establish a  proper IPsec tunnel
suitable for L2TP/IPsec.

>> - setup L2TP part with xl2tpd (which needs ppp)

> Hmm, we'll need to control xl2tpd then too, but we'll need to be able to
> tell it what options to pass to pppd, not give it a config file.  We
> also need to be able to feed secrets to it over stdin or via a plugin if
> possible.  This is what's done for pppd, since pppd allows plugins to
> handle the authentication.

xl2tpd can either use a plugin for pppd and do the authentication itself
or just  let pppd do the  authentication. So the actual  plugin for pppd
will do the trick.  Concerning pppd options, unfortunately, xl2tpd seems
to have no other options than to pass a file to pppd.

> The problem with config files is that we'd be writing them out every
> time we launch the daemon, because the VPN settings come from a variety
> of sources.  They are pulled from the user's session store (GConf on
> Gnome) or from system settings, they don't get stored in the native
> daemons config files.

Can't we write temporary files? xl2tpd accepts to take any configuration
file.

Thanks for your insight!
-- 
BOFH excuse #63:
not properly grounded, please bury computer
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Support for L2TP/IPsec

[Dan Williams]

On Thu, 2008-05-22 at 13:37 +0200, Vincent Bernat wrote:
> Hi!
> 
> LT2P/IPsec becomes a popular choice for setting up VPN. Security is greater
> than PPTP solutions and clients are included in Windows and Mac OS X.
> Unfortunately, this is quite difficult to setup on Linux. Having a plugin
> for network-manager will be great.

So we need a few things from openswan.  The first is to either accept
command-line arguments for configuration, or to accept configuration
from stdin and not from a file.  There's quite a few reasons why we
shouldn't be writing out a config file, and there's more reasons why we
shouldn't be pointing openswan at an existing config file.

> Here are the steps to configure an L2TP/IPsec connections (with OpenSWAN
> rather than racoon, implementation of OpenSWAN is easier):
>  - setup OpenSWAN for IPsec transport mode
> 
> version   2.0
> config setup
>   nat_traversal=yes
>   nhelpers=0
> conn L2TP
>right="roadwarrior.example.com"
>[EMAIL PROTECTED]
>authby=rsasig
>pfs=no
>rekey=yes
>keyingtries=3
>type=transport
>left=%defaultroute
>leftcert=XX.pem
>leftrsasigkey=%cert
>leftprotoport=17/1701
>leftnexthop=%defaultroute
>rightrsasigkey=%cert
>rightca=%same
>rightprotoport=17/1701
>dpddelay=30
>dpdtimeout=120
>dpdaction=clear
> include /etc/ipsec.d/examples/no_oe.conf
> 
> To avoid to modify /etc/ipsec.conf, NetworkManager could require that you
> include /etc/ipsec.d/networkmanager which would be a symlink to some file
> generated by NetworkManager. The example above is for authentication with
> certificates. You should also setup private key with /etc/ipsec.secrets. I
> am not sure if it is possible to tell OpenSWAN to use another file.

We shouldn't be pointing it at config files; and authentication needs to
be interactive or one-shot using provided secrets, not a config file
like /etc/ipsec.secrets...

>  - enable IPsec tunnel with ipsec auto --up L2TP (this command returns on
> success)
>  - setup L2TP part with xl2tpd (which needs ppp)

Hmm, we'll need to control xl2tpd then too, but we'll need to be able to
tell it what options to pass to pppd, not give it a config file.  We
also need to be able to feed secrets to it over stdin or via a plugin if
possible.  This is what's done for pppd, since pppd allows plugins to
handle the authentication.

The problem with config files is that we'd be writing them out every
time we launch the daemon, because the VPN settings come from a variety
of sources.  They are pulled from the user's session store (GConf on
Gnome) or from system settings, they don't get stored in the native
daemons config files.

But this overview is good, thanks for posting it!  It does give me a
better idea about how to work things.

Dan

> xl2tpd.conf is like this :
> 
> [lac l2tp]
> lns = roadwarrior.example.com
> require chap = yes
> autodial = yes
> pppoptfile = /etc/ppp/options.roadwarrior.l2tpd
> length bit = yes
> name = XX
> 
> /etc/ppp/options.roadwarrior.l2tpd is like this:
> 
> ipcp-accept-local
> ipcp-accept-remote
> idle 1800
> debug
> mtu 1410
> mru 1410
> nodefaultroute
> require-mschap-v2
> refuse-chap
> refuse-mschap
> refuse-eap
> refuse-pap
> noccp
> noauth
> 
> And you need to setup /etc/ppp/chap-secrets (again, don't know if ppp is
> able to use another file)
> 
>  - launch xl2tpd -D -c config-file
>  - setup routes
> 
> The tricky part comparing with PPTP is that we need to handle two daemons
> (one for IPsec, one for L2TP).
> 
> Does somebody already work on implementing this kind of VPN in
> NetworkManager?
> 
> Thanks.
> 
> ___
> NetworkManager-list mailing list
> NetworkManager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Support for L2TP/IPsec

[Vincent Bernat]

Hi!

LT2P/IPsec becomes a popular choice for setting up VPN. Security is greater
than PPTP solutions and clients are included in Windows and Mac OS X.
Unfortunately, this is quite difficult to setup on Linux. Having a plugin
for network-manager will be great.

Here are the steps to configure an L2TP/IPsec connections (with OpenSWAN
rather than racoon, implementation of OpenSWAN is easier):
 - setup OpenSWAN for IPsec transport mode

version 2.0
config setup
nat_traversal=yes
nhelpers=0
conn L2TP
   right="roadwarrior.example.com"
   [EMAIL PROTECTED]
   authby=rsasig
   pfs=no
   rekey=yes
   keyingtries=3
   type=transport
   left=%defaultroute
   leftcert=XX.pem
   leftrsasigkey=%cert
   leftprotoport=17/1701
   leftnexthop=%defaultroute
   rightrsasigkey=%cert
   rightca=%same
   rightprotoport=17/1701
   dpddelay=30
   dpdtimeout=120
   dpdaction=clear
include /etc/ipsec.d/examples/no_oe.conf

To avoid to modify /etc/ipsec.conf, NetworkManager could require that you
include /etc/ipsec.d/networkmanager which would be a symlink to some file
generated by NetworkManager. The example above is for authentication with
certificates. You should also setup private key with /etc/ipsec.secrets. I
am not sure if it is possible to tell OpenSWAN to use another file.

 - enable IPsec tunnel with ipsec auto --up L2TP (this command returns on
success)
 - setup L2TP part with xl2tpd (which needs ppp)

xl2tpd.conf is like this :

[lac l2tp]
lns = roadwarrior.example.com
require chap = yes
autodial = yes
pppoptfile = /etc/ppp/options.roadwarrior.l2tpd
length bit = yes
name = XX

/etc/ppp/options.roadwarrior.l2tpd is like this:

ipcp-accept-local
ipcp-accept-remote
idle 1800
debug
mtu 1410
mru 1410
nodefaultroute
require-mschap-v2
refuse-chap
refuse-mschap
refuse-eap
refuse-pap
noccp
noauth

And you need to setup /etc/ppp/chap-secrets (again, don't know if ppp is
able to use another file)

 - launch xl2tpd -D -c config-file
 - setup routes

The tricky part comparing with PPTP is that we need to handle two daemons
(one for IPsec, one for L2TP).

Does somebody already work on implementing this kind of VPN in
NetworkManager?

Thanks.

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list