[Openswan dev] bug report (auto=add &auto=start)

[Paul Wouters]

On Tue, 19 Jun 2007, Alex wrote:

> > So for some reason the ipsec auto --up connname is failling, even though it
> > seems to be triggered enough to work later on.
>
> Many thanks for your reply... Can be fixed in the future openswan releases?

Once we know why it seems to fail for some people on the first go, while
succeeding on the second go, then yes. But until I have more information, I
do not know what is wrong. I cannot remove the error because it IS a real
error. It just "fixes itself".

> I loosed 2 days reading output from ipsec barf due to this stupid message ...
> trying to find an ERROR in my config ... which does not exist ...!!! This is
> just an WARNING, not an error ...

No. It is an error. It failed. It might have succeeded on the 2nd go, or because
the other end got triggered. Without knowing more we cannot say it is just a
warning. As far as we can tell we tried to start a connection and we failed.

> and is not documented anywhere and the
> output from my syslog, looks like ipsec has "encountered and error and give
> up suddenly"! I saw a lot of posts on the web complaining about this "error"
> and NO FIX/REPLY or EXPLANATION!

Because most people ignore things when things seem to work anyway.

> > Can you try issuing this on one end:
> >
>
> yes, see below:
>
> > ipsec auto --replace connname
> > ipsec auto --up --asynchronous connname
> > echo $?
> >
> on the left router:
>
> [root at dev13 ~]# /etc/rc.d/init.d/ipsec start
> ipsec_setup: Starting Openswan IPsec 2.4.8...
> [root at dev13 ~]# ./eroute.pl
>  in 10.0.100.0/24      -> 192.168.13.0/24    => tun0x176 at MY_RIGHT_IP
> out 10.0.100.0/24      -> 192.168.13.0/24    => tun0x169 at MY_RIGHT_IP
> fwd 10.0.100.0/24      -> 192.168.13.0/24    => tun0x186 at MY_RIGHT_IP
>
> In /var/log/messages appear:
> Jun 19 00:21:43 dev13 kernel: NET: Registered protocol family 15
> Jun 19 00:21:43 dev13 ipsec_setup: NETKEY on eth0 MY_LEFT_IP/255.255.255.0
> broadcast x.y.z.255
> Jun 19 00:21:43 dev13 ipsec_setup: ...Openswan IPsec started
> Jun 19 00:21:43 dev13 ipsec_setup: Starting Openswan IPsec 2.4.8...
> Jun 19 00:21:45 dev13 ipsec__plutorun: 104 "z1" #1: STATE_MAIN_I1: initiate
> Jun 19 00:21:45 dev13 ipsec__plutorun: ...could not start conn "z1"
>
> [root at dev13 ~]# ipsec auto --replace z1
> [root at dev13 ~]# ipsec auto --up --asynchronous z1
> 104 "z1" #5: STATE_MAIN_I1: initiate
> [root at dev13 ~]# echo $?
> 104

Interesting. The return code should not be non-zero, since your logs below
show that absolutely nothing went wrong. It is probably non-zero,
because the ipsec auto command returns before knowing if the connection
succeeded, because of the default --asynchronous flag. It does a "fire
and forget".

Michael: Should we change auto to return 0 for this? Or change _plutorun
to not care about the return code?

> Also, if i add on my left router, in my ipsec.conf:
> config setup
>     plutowait=yes
> and keep the rest intact, the message dissapear from my syslog:

Yes, so then it can return a proper return code, since the connection comes
up and it returns 0 for success.

> So, a quick fixto this problem is to add to /etc/ipsec.conf:
> config setup
>     plutowait=yes
> ^^^^^^^^^^^^^^^^

This is the wrong fix, because of you have dozens or hunderds of tunnels
you will now start them up one after the other, instead of parallel.

Paul