Bug 1136076
| Summary: | After IKE rekeying Pluto sends DPD even if there is active SA | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jaroslav Aster <jaster> |
| Component: | libreswan | Assignee: | Paul Wouters <pwouters> |
| Status: | CLOSED ERRATA | QA Contact: | Ondrej Moriš <omoris> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.5 | CC: | jaster, lmiksik, mthacker, omoris, pwouters |
| Target Milestone: | rc | ||
| Target Release: | 7.5 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | libreswan-3.23-1.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-04-10 17:22:34 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I am confused here. An active tunnel is not a "tunnel that is up" but a "tunnel that has traffic flow right now". So a DPD should be suppressed when there are ESP packets already going in both directions (or really incoming) It has nothing to do with rekeying or waiting an hour. DPD is only meant to see the difference between a completely silent tunnel with no traffic flow on it and a tunnel endpoint that has vanished. So either this description of this bug is wrong, or this is not a bug. Hi Paul, as I wrote in description of the bug, there is a active connection between two hosts - ping. One host sends icmp echo request packet and second host replies icmp echo reply packet. So there is a traffic, libreswan sees that both hosts are alived, because they are communicated to each other, so there is no reason to send DPD (R_U_THERE). I can confirm that issue is only reproducible when using ikev1, with ikev2 there is no DPD communication during ongoing traffic.
Configuration for ikev1 case is as follows:
client
------
config setup
protostack=netkey
plutodebug=all
plutostderrlog=/var/log/pluto.log
conn test
left=<CLIENT>
right=<SERVER>
authby=secret
auto=add
ikev2=no
config setup
protostack=netkey
plutodebug=all
plutostderrlog=/var/log/pluto.log
server
------
conn test
left=<SERVER>
right=<CLIENT>
authby=secret
auto=add
dpddelay=30s
dpdtimeout=180s
dpdaction=clear
ikelifetime=5m
salifetime=8h
ikev2=no
Client --up connection and then starts continuously pinging server for 3 minutes and copying client pluto log file during that period. Then we stop log file copying, then we stop pinging and check copied portion of log file for R_U_THERE messages:
ping <SERVER> 2>&1 &
ping_pid=$!
tail -f -n0 /var/log/pluto.log >>pluto_ping.log &
tail_pid=$!
sleep 180
kill $tail_pid
kill $ping_pid
grep 'R_U_THERE' pluto_ping.log
rm -f pluto_ping.log
Double-check with --trafficstatus whack option confirm communication:
# ipsec whack --trafficstatus
006 #2: "test", type=ESP, add_time=1516702713, inBytes=16044, outBytes=16044, id='<SERVER>'
With ikev2, no such messages. With ikev1, R_U_THERE message every 30 seconds (as configured):
Jan 23 11:19:33.904492: | Notify Message Type: R_U_THERE (0x8d28)
Jan 23 11:19:33.904506: | processing informational R_U_THERE (36136)
Jan 23 11:19:33.904511: | DPD: received R_U_THERE seq:24819 monotime:10148.194 (state=#3 name="test")
Jan 23 11:19:33.904567: | Notify Message Type: R_U_THERE_ACK (0x8d29)
Jan 23 11:20:03.922556: | Notify Message Type: R_U_THERE (0x8d28)
Jan 23 11:20:03.922567: | processing informational R_U_THERE (36136)
Jan 23 11:20:03.922573: | DPD: received R_U_THERE seq:31889 monotime:10178.212 (state=#4 name="test")
Jan 23 11:20:03.922633: | Notify Message Type: R_U_THERE_ACK (0x8d29)
Jan 23 11:20:33.938597: | Notify Message Type: R_U_THERE (0x8d28)
Jan 23 11:20:33.938608: | processing informational R_U_THERE (36136)
Jan 23 11:20:33.938613: | DPD: received R_U_THERE seq:5560 monotime:10208.228 (state=#5 name="test")
Jan 23 11:20:33.938704: | Notify Message Type: R_U_THERE_ACK (0x8d29)
Jan 23 11:21:03.958298: | Notify Message Type: R_U_THERE (0x8d28)
Jan 23 11:21:03.958320: | processing informational R_U_THERE (36136)
Jan 23 11:21:03.958342: | DPD: received R_U_THERE seq:3312 monotime:10238.248 (state=#6 name="test")
Jan 23 11:21:03.958473: | Notify Message Type: R_U_THERE_ACK (0x8d29)
Jan 23 11:21:33.977331: | Notify Message Type: R_U_THERE (0x8d28)
Jan 23 11:21:33.977341: | processing informational R_U_THERE (36136)
Jan 23 11:21:33.977346: | DPD: received R_U_THERE seq:16380 monotime:10268.267 (state=#7 name="test")
Jan 23 11:21:33.977401: | Notify Message Type: R_U_THERE_ACK (0x8d29)
I attached complete pluto logs (debug=all) from both server and client.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0932 |
Description of problem: After IKE rekeying Pluto sends DPD even if there is active SA. It can be considered as wrong because it is not needed to send DPD if active SA exists. Version-Release number of selected component (if applicable): openswan-2.6.32-34 How reproducible: Always. Steps to Reproduce: 1. Configure and start ipsec on INITIATOR and RESPONDER site. /etc/ipsec.secrets on both site: # cat /etc/ipsec.secrets : PSK "RedHatEnterpriseLinux" /etc/ipsec.conf on INITIATOR site: # cat /etc/ipsec.conf config setup protostack=netkey plutodebug=all conn test left=<I> right=<R> authby=secret auto=add dpddelay=5 dpdtimeout=30 dpdaction=clear ikelifetime=1h salifetime=8h /etc/ipsec.conf on RESPONDER site: # cat /etc/ipsec.conf config setup protostack=netkey plutodebug=all conn test left=<I> right=<R> authby=secret auto=add I: service ipsec start R: service ipsec start 2. Up test, set up active SA (ping) and wait at least one hour (ikelifetime). R: ping INITIATOR (active SA) I: ipsec auto --up test wait 1h 3. Check RESPONDER site if there is DPD (R_U_THERE) from INITIATOR R: grep 'R_U_THERE' /var/log/secure Actual results: There is 'R_U_THERE' in /var/log/secure. Expected results: No DPD on RESPONDER. Additional info: Be sure you establish active SA before up connection, otherwise grep result could be false positive.