[Openswan Users] Tunnel going down - local or remote?

[Peter McGill]

Anirudh,

Short answer: Not using DPD, but perhaps with monitoring scripts.
Long answer:

You can easily monitor ipsec auto --up/--down by providing a wrapper
script to record the intended up/down status.
Using KLIPS & DPD you can use ipsec eroute to determine actual status.
Should be a method for NETKEY too, but I still use KLIPS.
You can also scan the recent logs to determine why/who shut down the tunnel.
Although if the tunnel goes down via DPD timeout then I can't think of
any way to determine which end went down, only if one end disconnected
properly could you determine which end, via logs or by comparing intended
status to actual status using above described scripts.

If you want more specific help, try describing more what your trying to do.

Regarding DPD:

First, you need more than dpdtimeout to setup DPD.
	dpddelay=30
	dpdtimeout=120
	dpdaction=hold

>From doc/README.DPD:
> DPD works using a keepalive system, where when a tunnel is idle
> (established, but no traffic has traversed it for N period (dpddelay=N1)
> one or both sides send a "hello" messages (R_U_THERE) and the other
> replies with a acknowledge message (R_U_THERE_ACK).  If no response
> received, this continues until the DPD timeout value (dpdtimeout=N2)
> has elapsed.  If there still hasn't been any traffic or R_U_THERE_ACK
> packets received, the peer is declared to be dead, and the SA deleted,
> and related eroute removed from the table.
> 
> Note that both sides must have either dpddelay or dpdtimeout set for DPD
> to be proposed or accepted.  If one directive is set but not the other,
> the defaults are used (dpddelay=30, dpdtimeout=120).
> 
> The dpdaction parameter controls what we do when a peer is determined to
> be dead. If set to "hold" (the default) it will place the eroute into
> %hold status, and wait for the peer to return.  If set to "clear" it will
> remove the connection entirely, including both the SA and eroute.
> 
> We recommend that "hold" be used for statically defined tunnels, and
> "clear" be used for roadwarrior tunnels.

ipsec.conf manpage:
>       dpdaction
>              When a DPD enabled peer is declared dead, what action should  be
>              taken.  hold  (default)  means the eroute will be put into %hold
>              status, while clear  means  the  eroute  and  SA  with  both  be
>              cleared. dpdaction=clear is really only usefull on the server of
>              a Road Warrior config. The action restart  is  used  on  tunnels
>              that need to be permanently up, and have static IP addresses.

However, if the tunnel is disconnected intentionally by either end,
I do not believe DPD will restart it. DPD is for detecting unintended
loss of tunnel connection. When a tunnel is brought down it sends a
message to the other end terminating the connection, unless the other
end doesn't receive the message, I expect it will comply and destroy
the tunnel, regardless of DPD settings.

Also, if you run ipsec auto --delete on either side of the connection,
the connection will not be able to start again until the conn is re-added.
--down shut's down the tunnel, but --delete removes the conn description,
so the tunnel cannot even be brought back up.

Peter McGill
IT Systems Analyst
Gra Ham Energy Limited 

> -----Original Message-----
> From: users-bounces at openswan.org 
> [mailto:users-bounces at openswan.org] On Behalf Of Anirudh Kamatgi
> Sent: October 22, 2008 8:04 AM
> To: Users at openswan.org
> Subject: [Openswan Users] Tunnel going down - local or remote?
> 
> Hi,
> I am using Openswan with 2.6.21 kernel.
> When a tunnel goes down, I was wondering if it is possible to 
> determine which end of the tunnel goes down?
> 
> For ex. I have a gateway-gateway tunnel established and 
> turned on DPD with dpdtimeout=60.
> Now, if I manually bring down the tunnel on one gateway by 
> issuing 'ipsec auto --down <tunnel-name>' followed by 'ipsec 
> auto --delete <tunnel name>', can I figure out on the other 
> gateway that the remote end is down.
> 
> thanks in advance,
> -anirudh
> 
> 
>