[Openswan Users] Dead Peer Detection restart causes tunnel to be established, but afterwards cannot ping from either side
erich.titl at think.ch
Tue Oct 11 12:56:36 EDT 2011
on 11.10.2011 13:59, Geekman wrote:
> Hi All,
> Also, I should say thanks for your suggestion Erich. We have an
> existing Nagios infrastructure that we're planning on using to send
> pings down the tunnel to the remote peer, every 5 minutes as part of
> our VPN monitoring, so we'll get notified in the case of failures like
> this. But obviously, if it happens every hour or two (like the logs
> indicated) then that's a problem for us (and our users).
> Its interesting you say it works well for you - are the interruptions
We are considering putting in a cron to issue a --replace
> on a tunnel once it stops responding, to fix this issue. The problem
> is, the nature of the issue means that our OpenSwan box can't be the
> one to initiate - otherwise the tunnel doesn't work.
So your OpenVPN instance is the responder and whatever Cisco device is
So that would
> mean at random hourly intervals, the tunnel would stop for a few
> seconds till it times out on the other end who then re-initiates.
Unless you can force it to reconnect quicker.
> for people using RDP etc, I imagine this would be noticeable and
Yes it would.
> Would you say it happens that often for you? Or considerably less?
Our set up has OpenSwan on both sides of the connection it sits on a
Linux Firewall centrally and on small Firewalls at the remote locations.
The remotes scan scan the connectivity to the central location
independently and thus the load on them is very small.
And, mind you, my OpenSwan is nowhere near an actual version.
> wouldn't mind that work around so much if the chances of it occurring
> for each tunnel every few hours wasn't so high. Unfortunately for me,
> it may prove to be our last hope of getting it working at all with the
If your RV042s are the tunnel initiators I don't know if it is possible
to force them to do something similar. I guess you loaded them with the
latest firmware, so this should not be an issue neither. Maybe if you
set the DPD values very short, that might get you a similar behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2182 bytes
Desc: S/MIME Kryptografische Unterschrift
Url : http://lists.openswan.org/pipermail/users/attachments/20111011/a5b46fd7/attachment.bin
More information about the Users