that' s not a solution but a work-around (as a dear fellow poster pointed out here some time ago).
DPD works like this:
some sort of ' ping packets' are sent out over the tunnel and are answered by the remote FG. As soon as multiple pings are not answered, the sending FG knows that the tunnel is down. And the remote FG knows (from not receiving requests) that the tunnel is down as well. DPD then discards the SAs involved and tears the tunnel down. From this ' virgin' situation the tunnel can be re-negotiated immediately, either automatically or when receiving the first data packet(s).
Now you have noticed that disabling DPD keeps the tunnel up. I conclude from this that the DPD ' pings' (' R-U-there' packets) either don' t come through or some are lost during the transmission. Plus some failure to invoke the automatic tear down and re-negotiation of the tunnel.
And this failure has a reason which still is unknown. It could be that apparently DPD is configured on both sides BUT one side didn' t ' take' it, that is, DPD is not active on one side. Then the whole DPD mechanism will fail.
Without DPD I cannot imagine that tunnel re-negotiation will be quicker or smoother than with DPD. What do you observe when the tunnel is down now?
Ede Kernel panic: Aiee, killing interrupt handler!