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.
  • Probably the PIX does not respond to our initiation attempts. Do you see any response whatsoever from it?

    It's deleting the ISAKMP SA without renegotiating a new one and ignoring the ASGs attempts. There's your problem.
  • Well, waiting for response from the other side regarding this. However, I suppose I can have some script or something automatically re-establish the link if it's down? Would V9 do this? I heard V9 should have the alerting if it's down (when is it coming?)

    But without V9, we got some script that I can run as cronjob or something?

    And it bugs me that Support claims that anytime you do anything out of the GUI, they don't support.. yet there so much the GUI does not yet handle that the system does that it's quite hard not to ever go outside of the GUI.
  • Probably the PIX does not respond to our initiation attempts. Do you see any response whatsoever from it?

    It's deleting the ISAKMP SA without renegotiating a new one and ignoring the ASGs attempts. There's your problem.


    BTW, if it was somehow ignoring it.. why would it work when initially setting up the connection?
  • Probably the PIX does not respond to our initiation attempts. Do you see any response whatsoever from it?

    It's deleting the ISAKMP SA without renegotiating a new one and ignoring the ASGs attempts. There's your problem.


    Scratch that. Got bad info. They are using a Fortigate firewall. They do NOT have DPD on! They have some Keep alive thing on. But they also have some "enable replay detection" thing on which they are going to turn off as they say it might be causing some issue.
  • RESOLVED. Problem apparently was that my FW was not allowing UDP port 500 to come in from the other public peer.

    It did not make sense to me to need that because my router was initiating the connection and I have a few other VPN tunnels, none of which I allow anything inbound to the router. But one day I was testing with a different cloud infrastructure where I actually could see the FW logs and I saw the same behavior and also saw the dropped UDP 500 packets. Allowing those packets fixed the issue there too.