[Openswan Users] use of multiple ike and esp algorithms

[Paul Wouters]

On Wed, 6 Sep 2006, Joachim Schwender wrote:

> When you use openswan to connect to different peers with different alg
> capabilities, the configuration of ike and esp in connection section
> causes problems.

I don't see why? Every conn can have their own ike/esp settings. And they
do not need to be set. Not setting any of them will cause openswan to accept
any combination of aes/3des with md5/sha1 with dh2/5.

> If peer1 uses aes, and peer2 uses 3des, the configuration on the central
> peer must allow minimum both algorithms for both connections.

If you talk about connections that instantiate (right=%any) for roadwarriors,
then yes. By not specifying it, it will work for both. You could specify
things to use only those two as well, eg: ike=aes,3des or ike=3des-sha1,aes-sha1

> If you
> specify strictly ike=aes for peer1 and ike=3des for peer2, you will see
> connection drops.

So here you must be talking about either the client side, or two different
connections on the openswan server end. If the server has no ike/esp line,
and you have two clients to the same roadwarrior connection, one can use
ike=3des and the other ike=aes without any problem. If you use two seperate
conns, of course everything is configurable to be independant.

> The reason is that when the second connection is
> initiated, openswan uses the peer1 connection in phase 1 and refuses
> 3des, because peer1 must use aes. If you don't specify any ike= and esp=
> openswan uses defaults only, and it may not work.

What you might be seeing is a phase 1 that is the same for two different
conns. When a client for conn2 comes in, and the phase1 matches both
conn1 and conn2, then the logs might show it to you as conn1 (openswan
at this point has no idea which of the two conns will be the right one).
When phase2 proposals are sent, openswan picks the proper conn, and it
should switch to conn2.

> documentation should clearly state that parameters ike= and esp= should
> only be used in conn %default section. Does anybody know a possibility
> to restrict algorithms to connections?

That's just not true. Perhaps you should show us your entire configuration
and logerrors about what is really happening.

Paul
-- 
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155