[Openswan dev] Why does pluto need ipsec and whack?
hno at marasystems.com
Wed Aug 3 15:51:36 CEST 2005
On Thu, 14 Jul 2005, Daniel Djamaludin wrote:
> Does anyone know the background as to why pluto needs to have the
> configuation read by the ipsec configurator and then passed onto whack
> which then prods pluto?
That way no config file is really needed, just pluto and whack and a few
other small glue pieces.
> I'm curious as to why pluto wasn't designed to
> just read the configuration files for itself and any changes to the
> files to be updated with a SIGHUP signal.
Pluto is designed to be online controlled by whack alone.
Implementing a good "SIGHUP" is far from trivial as you must then
carefully compare what has changed and take appropriate actions. With the
design taken bu pluto + whack the implementation in pluto is greatly
simplified by infact instead asking the administrator to indicate what
parts have changed.
In addition, a "SIGHUP" based design makes it very hard to make dynamic
updates as the whole configuration needs to be reloaded on each and every
> Is there something fundamental to the behaviour of pluto that I'm
> missing here?
It's a design of clean layers. Makes the whole system very easy to
costomize and a great power imho.
* Kernel IPSec for handling established SAs.
* Pluto running IKE and controlling the kernel SAs. Also uses glue scripts
to manage routing etc as desired when installing/removing the SAs. By
default using routing scripts from the configuration scripts package, but
these may be replaced if needed.
* whack controlling Pluto.
* configuration scripts automating the whack calls, and some related glue
for starting/stopping pluto etc.
* configuration file acting as a data source for the configuration scripts
In our IPSec design based on Open-S/WAN 1.x we decided not to use the
configuration scripts or configuration file at all. Instead the
configuration part is dynamically driven by our system configuration
database, and pluto is dynamically reconfigured as needed. Due to the
"appliance" nature routing is also done quite differently than what you
would do on a normal system and thanks to the up/down scripts design used
by pluto it was very easy to fit. There was some minor tweaks we had to do
to make the startup of pluto behave nicely without too gross race windows,
but nothing major. More information can be found in the archives from
"Super-FreeS/WAN" time or http://marasystems.com/download/freeswan/
We are now planning to upgrade our integration to the current OpenS/WAN
2.x, and it will be interesting to see see what falls out from that
More information about the Dev