[Openswan dev] Disturbing development trend

[Paul Wouters]

On Wed, 1 Apr 2009, Jon wrote:

> I have noticed over the years that openswan has been on a disturbing
> trend toward becoming useless "nannyware" - software that thinks it
> knows better than you.

Not at all. It's always implemented a very strict RFC implementation, with
the only exception for not implementing yet another firewall in the code.

> An example:  the refusal of openswan to tear
> down routes associated with a tunnel (although workarounds exist), on
> the really weak justification that one might accidentally route packets
> intended to be encypted/secure over a different, insecure connection.

It's part of IPsec policies. If you load the policy "encrypt from here to
there", then that is what you get. If you don't want that, delete the
policy.

>  I
> also suspect this "nannyware" behaviour to be responsible for openswan
> refusing to honor more specific routes intended to override a portion of
> an existing tunnel definition (although I would appreciate confirmation
> of this assumption).

That is a "feature" of the NETKEY stack, not the KLIPS stack, and totally
out of our control. I fully agree with you here. It's the way NETKEY is
hacked into the networking stack that causes this.

> As for the first example I mentioned, if I needed that functionality, I
> would simply create a null route with a lower preference/metric such
> that if the tunnel failed, the null route would prevent any previously
> tunneled traffic from using any other links.  Unix software has
> traditionally been celebrated for allowing any crazy configuration or
> arguments, even if it destroys everything (ie rm -rf .*)

Those don't compare though. The norm is to prevent packets from leaking.
rm -rf * is not a routine operation at all.

> Can anyone explain this disturbing development trend in openswan?

To be honest, this sounds more like an unhappy guy who hit a feature or
bug they did not expect and is frustrated for losing a lot of time.

Paul