Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DPD does not restart IPsec site-to-site connection

Wondering if this or similar issues resolved. I'm having this problem with only 1 of my VPN connections so far. The timing, however, used to be 1 hour, but is more like 4-8 hours inconsistently after changing lifetime of the IPSec SA. who knows.  But I found a StrongSWAN option that again, does not seem exposed in the Astaro GUI.


dpdaction     controls the use of  the  Dead  Peer  Detection  protocol
                     (DPD,  RFC  3706)  where  R_U_THERE notification messages
                     (IKEv1)  or  empty  INFORMATIONAL  messages  (IKEv2)  are
                     periodically sent in order to check the liveliness of the
                     IPsec peer. The  values  clear,  hold,  and  restart  all
                     activate DPD. If no activity is detected, all connections
                     with a dead peer are stopped and unrouted ( clear ),  put
                     in the hold state ( hold ) or restarted ( restart ).  For
                     IKEv1, the default is  none  which  disables  the  active
                     sending  of  R_U_THERE notifications.  Nevertheless pluto
                     will always send the DPD Vendor ID during connection  set
                     up in order to signal the readiness to act passively as a
                     responder if the peer wants to use DPD. For  IKEv2,  none
                     does’t  make sense, since all messages are used to detect
                     dead peers. If specified, it has the same meaning as  the
                     default ( clear ).

I would prefer to always set to RESTART for my things. But I'm betting that since Astaro might not be setting this, it's doing the CLEAR action. Further, the sad thing is that Dead Peer Detection is set at the entire router level in Astaro. However this option really is supposed to be at the connection level to be able to configure each one independently.

For now, I just turned off DPD for the entire router and going to see if that helps.


This thread was automatically locked due to age.

  • I would prefer to always set to RESTART for my things. But I'm betting that since Astaro might not be setting this, it's doing the CLEAR action.


    "restart" is the default dpdaction on every Astaro ever since. You must have overseen it:
    # grep dpdaction /var/chroot-ipsec/etc/ipsec.conf
    
            dpdaction="restart"



    For now, I just turned off DPD for the entire router and going to see if that helps.


    Why would you want to turn off DPD for a connection? IPsec is pretty useless without it.
  • "restart" is the default dpdaction on every Astaro ever since. You must have overseen it:
    # grep dpdaction /var/chroot-ipsec/etc/ipsec.conf
            dpdaction="restart"


    Oh shoot... I see that in mine.... so then...

    Why would you want to turn off DPD for a connection? IPsec is pretty useless without it.


    because after receiving this request, it just shuts the thing down. And All I do is come back when I notice it's down (cause no alerting on that yet) and then I just disable/enable it and it's back up for a while. I thought without acting on those DPD requests, it would stay up.

    DPD: Received old or duplicate R_U_THERE
    ...
    DPD: No response from peer - declaring peer dead

    Do you think this is the other side shutting it down? They can't seem to figure anything out why it would be doing that. Right now I'm on the AWS Astaro instance, but I think I will try on a non-AWS instance.
  • Do you think this is the other side shutting it down? They can't seem to figure anything out why it would be doing that. Right now I'm on the AWS Astaro instance, but I think I will try on a non-AWS instance.


    You probably have a respond only connection on the Astaro, right? These do not get restarted regardless of what you set as DPD action.

  • Why would you want to turn off DPD for a connection? IPsec is pretty useless without it.


    Why do you say that? The only thing it would not do, is automatically shut down (or restart) a tunnel.  So without it, the systems would simply try to send traffic and have it fail due to some comm error. Not much different from every day life with an IPSec tunnel even with DPD on because other issues can happen behind it.
  • You probably have a respond only connection on the Astaro, right? These do not get restarted regardless of what you set as DPD action.


    The fix for issue #19482 was released in 8.301. Please consider upgrading


    Every single remote gateway I configure is as "initiate connection" mode.
    I've been running 8.301 since it came out.
    All my IPSec VPN's are site-to-site.
  • Why do you say that? The only thing it would not do, is automatically shut down (or restart) a tunnel.  So without it, the systems would simply try to send traffic and have it fail due to some comm error. Not much different from every day life with an IPSec tunnel even with DPD on because other issues can happen behind it.


    DPD is useful in cases where peers do not or cannot notify the IKE daemon of deleted SAs. It prevents stale SAs and all the problems that come from them. In your case disabling it is just the workaround for a bug or misconfiguration. In general you want to have it.

    Every single remote gateway I configure is as "initiate connection" mode.


    Ok then, could you post the ipsec.log file for the time when the peer is detected dead and the connection is not reinitiated?


    I've been running 8.301 since it came out.
    All my IPSec VPN's are site-to-site.


    That info was for people with the L2TP problem from http://http://www.astaro.org/astaro-gateway-products/vpn-site-site-remote-access/38575-l2tp-vpn-disconnects-after-60-minutes.html only. It does not apply to your setup.
  • Sure.. here it is:

    Line 7132: 2012:03:21-21:42:46 *** pluto[5340]: "S_REF_IpsSit***_1" #59744: sent QI2, IPsec SA established {ESP=>0x3b31b655 0x3b31b657 
  • And another example with same tunnel but changing lifetime settings.. not sure it made a real difference.

    Line 5425: 2012:03:21-16:09:43 *** pluto[5340]: "S_REF_IpsSit***_0" #59275: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP to replace #59215 {using isakmp#59216}
    Line 5426: 2012:03:21-16:09:43 *** pluto[5340]: "S_REF_IpsSit***_0" #59275: sent QI2, IPsec SA established {ESP=>0x3b31b62f 0x3b31b630 
  • Pluto is initiating main mode after DPD. So all ok here. DPD happens because the peer deletes the ISAKMP SA 21:51:05. Without a phase1 SA no DPD is possible, thus the peer is declared dead. What kind of box is at the other end of the connection?
  • They have a Cisco PIX525.

    And the tunnel went down a few mins ago with DPD off, with this in the log:

    Line 3634: 2012:03:23-12:30:48 *** pluto[5340]: "S_REF_Ips***_0" #63304: IPsec SA established {ESP=>0x3b31b768 0x3b31b769