Project

General

Profile

Issue #2400

Is DPD supposed to detect dead tunnel, or dead IKE instance

Added by c c about 3 years ago. Updated over 1 year ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
documentation
Affected version:
5.5.0
Resolution:

Description

As per rfc3706, DPD mechanism is supposed to detect dead peer, I did not find clear explanation for the below scenario:
Two local connections configured:
conn1: left 10.10.10.2 <-> right 10.10.10.4, SA established and bi-directional ESP traffic continuously ongoing
conn2: left 10.10.10.3 <-> right 10.10.10.4, SA established and no ESP traffic ongoing

It is expected that there is no DPD messages between endpoints of conn1.
But what about conn2? Will 10.10.10.4 be regarded as alive by strongSwan so that no DPD message either?


Related issues

Related to Issue #2708: DPD behavior comformance with RFC7296Closed

History

#1 Updated by Noel Kuntze about 3 years ago

  • Category set to documentation
  • Status changed from New to Feedback
  • Assignee set to Noel Kuntze

Hi,

As the name implies, it detects if a peer is alive - or not.

In conn2, at least one peer will send DPD messages periodically.
A peer is considered alive, if charon gets an IKE packet from it or the kernel receives an ESP or AH packet from it.

#2 Updated by c c about 3 years ago

In the configuration above, the peer is the same(10.10.10.4) for conn1 and conn2.
Since DPD is to detect whether a peer is alive or not, and there is traffic from 10.10.10.4 in conn1.
It means 10.10.10.4 is alive, then there is no need for DPD messages in conn2?

#3 Updated by Tobias Brunner about 3 years ago

Since DPD is to detect whether a peer is alive or not, and there is traffic from 10.10.10.4 in conn1.
It means 10.10.10.4 is alive, then there is no need for DPD messages in conn2?

No, each IKE_SA (and its CHILD_SAs) is considered separately.

#4 Updated by c c about 3 years ago

Thanks for the info.
I am troubleshooting an issue, doubting that DPD message is not sent as expected.
But since there are multiple connections configured, it's not easy to figure out with which IKE SA the message is sent.

charon[8151]: 09[IKE] sending DPD request

As in the log entry above, there is no IKE SA info.
The work thread number 09 seems not helpful either, can you shed some light?

#5 Updated by Tobias Brunner about 3 years ago

As in the log entry above, there is no IKE SA info.
The work thread number 09 seems not helpful either, can you shed some light?

Either increase the log level for mgr to 2 so you see what IKE_SA that thread checked out before sending the DPD, or you enable the ike_name option for your logger (see LoggerConfiguration for details).

#6 Updated by c c about 3 years ago

It is confirmed that in the testing when multiple connections(with different peers) are configured, there is no expected DPD message initiated from strongSwan when the peer is disconnected.
ESP traffic is kept sending but DPD messages happened 10+ min later.(dpddelay=10, ikev2)

Any clue for further investigation?

#7 Updated by Tobias Brunner about 3 years ago

there is no expected DPD message initiated from strongSwan when the peer is disconnected.

What does disconnected mean? I guess there is no DELETE for the connection?

ESP traffic is kept sending but DPD messages happened 10+ min later.(dpddelay=10, ikev2)

What do you mean?

#8 Updated by c c about 3 years ago

What does disconnected mean? I guess there is no DELETE for the connection?

Yes there is no DELETE message, thus the local SA remains.

What do you mean?

It means that with local SA remaining and peer unreachable, DPD message should be sent after dpddelay.
But with dpdelay=10 in ipsec.conf. DPD message is seen only after 10+ min.
This issue was occasional. Not sure what went wrong.

#9 Updated by Tobias Brunner about 3 years ago

But with dpdelay=10 in ipsec.conf. DPD message is seen only after 10+ min.

What does "10+ min" mean? 10 minutes and x seconds? 15 minutes? 20 minutes?

Also, DPDs are only sent if dpdaction is also set (e.g to clear on a gateway for mobile clients). And if there is already an IKE exchange active (e.g. a rekeying), no DPDs will be sent either, the retransmission timings for that exchange will just apply.

#10 Updated by c c about 3 years ago

DPD message generated after around 15 minutes, while the setting is dpddelay=10 and dpdaction=clear.
There is no IKE exchange, only outbound ESP.
The issue is occasional. Need some means for further troubleshooting.

#11 Updated by c c about 3 years ago

It seems that strongSwan checks ingress traffic with SP use_time, instead of SA use_time.
It means that whenever there is incoming packet matching SPD, the use_time is updated, even though the packet may be mistakenly sent and is not ESP.
It makes more sense to check the DPD interval with the SA use_time, or IKE message received.

#12 Updated by Tobias Brunner about 3 years ago

It seems that strongSwan checks ingress traffic with SP use_time, instead of SA use_time.

Correct, because the use_time on the SA is the first use, not the last use.

It means that whenever there is incoming packet matching SPD, the use_time is updated, even though the packet may be mistakenly sent and is not ESP.

What do you mean? What else could it be? And you realize there are policies in both directions, right?

#13 Updated by c c about 3 years ago

I mean if there is a mistakenly send packet that matches SPD_IN, the SP use_time is updated.
As DPD interval is checked against SP use_time, DPD message is skipped while it should be sent due to no IKE or ingress ESP.

#14 Updated by Tobias Brunner about 3 years ago

I mean if there is a mistakenly send packet that matches SPD_IN, the SP use_time is updated.

When would that happen? And I'd assume the packet is dropped if it didn't come from an IPsec SA and that should not cause the use_time to get updated.

#15 Updated by c c about 3 years ago

When would that happen? And I'd assume the packet is dropped if it didn't come from an IPsec SA and that should not cause the use_time to get updated.

This is kernel behavior in stead of strongswan,I will try to confirm that.

#16 Updated by c c about 3 years ago

I've tested on Linux 2.6.32, it turns out that the packet is dropped due to XfrmInTmplMismatch, but it does cause the use_time of IN policy to get updated.
Please check below, I was tesing with ping that sent 1 clear packet per second and matched the IN policy.

[root@PC-067 ~]# cat /proc/net/xfrm_stat | grep XfrmInTmplMismatch; ip -s x p | grep use
*XfrmInTmplMismatch              518*
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:55:41 use -
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:55:41 use -
          expire use: soft 0(sec), hard 0(sec)
          *add 2017-09-05 15:55:41 use 2017-09-05 16:04:47*
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:55:41 use 2017-09-05 15:58:27
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use -
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use -
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use 2017-09-05 15:58:03
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use 2017-09-05 15:58:03
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use -
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use -
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use -
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use -
[root@PC-067 ~]# cat /proc/net/xfrm_stat | grep XfrmInTmplMismatch; ip -s x p | grep use
*XfrmInTmplMismatch              519*
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:55:41 use -
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:55:41 use -
          expire use: soft 0(sec), hard 0(sec)
          *add 2017-09-05 15:55:41 use 2017-09-05 16:04:48*
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:55:41 use 2017-09-05 15:58:27
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use -
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use -
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use 2017-09-05 15:58:03
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use 2017-09-05 15:58:03
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use -
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use -
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use -
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use -
[root@PC-067 ~]# cat /proc/net/xfrm_stat | grep XfrmInTmplMismatch; ip -s x p | grep use
*XfrmInTmplMismatch              520*
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:55:41 use -
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:55:41 use -
          expire use: soft 0(sec), hard 0(sec)
          *add 2017-09-05 15:55:41 use 2017-09-05 16:04:49*
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:55:41 use 2017-09-05 15:58:27
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use -
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use -
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use 2017-09-05 15:58:03
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use 2017-09-05 15:58:03
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use -
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use -
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use -
          expire use: soft 0(sec), hard 0(sec)
          add 2017-09-05 15:40:15 use -

#17 Updated by c c about 3 years ago

Linux 4.8.0 works the same way.
Apparently this is not consistent with strongSwan expectation.

If linux kernel does not change the way policy use_time is updated, maybe strongSwan can provide an option to disable checking inbound traffic while sending DPD.

#18 Updated by Tobias Brunner about 3 years ago

I've tested on Linux 2.6.32, it turns out that the packet is dropped due to XfrmInTmplMismatch, but it does cause the use_time of IN policy to get updated.

Is that something that occurs regularly in your setup? I guess from the kernel's perspective the policy is used, even just to reject packets. Maybe you can use firewall rules to reject cleartext packets that don't come from an IPsec tunnel (i.e. set INPUT/FORWARD to DROP and use leftfirewall=yes).

strongSwan can provide an option to disable checking inbound traffic while sending DPD.

I guess so.

#19 Updated by c c about 3 years ago

This is not something that occurs regularly but an error case that is trying to find security flaws.

As to your suggestion that "set INPUT/FORWARD to DROP and use leftfirewall=yes", IMO with this setting the illegal packet will be accepted by iptable rules but dropped due to IPsec policy checking, so the policy is still updated with new use_time.

#20 Updated by Tobias Brunner about 3 years ago

IMO with this setting the illegal packet will be accepted by iptable rules but dropped due to IPsec policy checking, so the policy is still updated with new use_time.

Yes, it seems such packets hit the policy before hitting the firewall rules.

#21 Updated by Tobias Brunner about 2 years ago

  • Related to Issue #2708: DPD behavior comformance with RFC7296 added

#22 Updated by Noel Kuntze over 1 year ago

  • Assignee deleted (Noel Kuntze)

Also available in: Atom PDF