From b76e96e2ef4d56c863b36c8d3c39e3c2efcf4a7c Mon Sep 17 00:00:00 2001 From: Martin Willi Date: Fri, 1 Nov 2013 11:28:53 +0100 Subject: [PATCH] ike: Don't immediately DPD after deferred DELETEs following IKE_SA rekeying Some peers seem to defer DELETEs a few seconds after rekeying the IKE_SA, which is perfectly valid. For short(er) DPD delays, this leads to the situation where we send a DPD request during set_state(), but the IKE_SA has no hosts set yet. Avoid that DPD by resetting the INBOUND timestamp during set_state(). --- src/libcharon/sa/ike_sa.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/libcharon/sa/ike_sa.c b/src/libcharon/sa/ike_sa.c index 0282087827..d482f8b49c 100644 --- a/src/libcharon/sa/ike_sa.c +++ b/src/libcharon/sa/ike_sa.c @@ -687,6 +687,14 @@ METHOD(ike_sa_t, set_state, void, DBG1(DBG_IKE, "maximum IKE_SA lifetime %ds", t); } trigger_dpd = this->peer_cfg->get_dpd(this->peer_cfg); + if (trigger_dpd) + { + /* Some peers delay the DELETE after rekeying an IKE_SA. + * If this delay is longer than our DPD delay, we would + * send a DPD request here. The IKE_SA is not ready to do + * so yet, so prevent that. */ + this->stats[STAT_INBOUND] = this->stats[STAT_ESTABLISHED]; + } } break; } -- 2.47.2