[Openswan dev] Re: thoughts on openswan initscripts

[Bill Nottingham]

Paul Wouters (paul at xelerance.com) said: 
> But then it gets tricky. The ideal situation is that one only needs to
> change IPSEC_USERLAND to change implementations, but this means that
> both implementations needs to use the same variables, at least for those
> where they overlap, in the ifcfg- files. This proved to be a much bigger
> problem then I thought at first, because the variables that have been
> chosen now by RedHat are basicly the variables as passed to one very
> specific userland implementation, basicly the arguments to setkey. I
> found myself making a translations of all the openswan ipsec.conf options
> into shell variables.  Some are different (SRC versus left, SRCNET versus
> leftsubnet)

This is only different in nomenclature, though, if I'm understanding
you right. The semantics are pretty much the same, yes? (i.e., it's
one end of the connection)

> It began to make less and
> less sense to me. Especially because the overlap between racoon and 
> openswan is not that great, and switching userland with one variable
> is not very likely going to work to begin with.

That's entirely possible, though. It's hard to write a generic
infrastructure when only looking at one alternative at the time...

> In short, what the
> current ifup-ipsec.racoon does is fling the ifcfg- contents with some
> setkey glue in a file in /etc/racoon/$DST.conf and -HUP the racoon daemon.
> (as a side note, when I tried to do this with initscipts-7.46-1 this
> didn't work. The /etc/racoon/$DST.conf file could not be parsed by racoon)

Hm, haven't seen that in bugzilla (ducks).

> Likely what i really wanted by RedHat is
> configuration via the redhat-config-network tool. But redhat-config-network
> could just as easily get its configuration from /etc/ipsec.d/conns/$CONN.conf 
> or /etc/racoon/$CONN.conf 

Basically, it's simpler to just deal with the parameters that the
network tool needs abstracted from the config file. This is especially
true with something that can be manually configured to a much greater
extent than what the config tool supports, such as IPSEC.

> So, what it boils down to I guess is this. Why don't racoon and openswan
> just keep their tunnel configurations in their seperate files, in their
> own syntax, in their own directory structure?

It's writing two backends for the network config tool, neither of
which is there at the moment. Aside from that, it sounds fine. ;)

> The only other argument
> in favour of the ifcfg- files is simplicity for the enduser. Frankly,
> if John Enduser looks at the supported variables in the ifup scripts,
> especially if it has both racoon's and openswan's options, he'll run
> away screaming to his Microsoft MMC snapin.

Heh. The setkey stuff for manual keying is a ridiculous mess, yes.

> There are other problems as well. PSK's are stored in the ifcfg-
> files, unless one starts to use PSK=`cat /etc/foobar`, which is also
> far from user friendly.

Actually, they can be kept in a separate non-world-readable file, but
the rest of your comment does apply.

> For Openswan, this construct also brings other problems. Our "conn
> default" cannot be used anymore. Our also= construct can also not be
> used anymore.  This means that if for instance your IP changes, you need
> to go change them in all tunnel ifcfg- files.

One of the features of the way it's written now is that the source
address is computed automatically 99% of the time, so that shouldn't
be a problem.

Bill