<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi colleagues,</p>
<p>struggling with the following problem: it seems, that
make_before_break do not process, first closing an existing SA and
then negotiating new one:</p>
<p>Responder side logs:<br>
</p>
<pre>charon-systemd[64387]: closing CHILD_SA pskv2-gagarin-child{17} with SPIs c9c1dc8e_i (76 bytes) c18d0c57_o (0 bytes) and TS 0.0.0.0/0 === 0.0.0.0/0
charon-systemd[64387]: looking for a child config for 0.0.0.0/0 === 0.0.0.0/0
charon-systemd[64387]: proposing traffic selectors for us:
charon-systemd[64387]: 0.0.0.0/0
charon-systemd[64387]: proposing traffic selectors for other:
charon-systemd[64387]: 0.0.0.0/0
charon-systemd[64387]: candidate "pskv2-gagarin-child" with prio 5+5
charon-systemd[64387]: found matching child config "pskv2-gagarin-child" with prio 10
charon-systemd[64387]: selecting proposal:
charon-systemd[64387]: no acceptable ENCRYPTION_ALGORITHM found
charon-systemd[64387]: selecting proposal:
charon-systemd[64387]: proposal matches
charon-systemd[64387]: received proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
charon-systemd[64387]: configured proposals: ESP:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_256/AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ
charon-systemd[64387]: selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
charon-systemd[64387]: selecting traffic selectors for us:
charon-systemd[64387]: config: 0.0.0.0/0, received: 0.0.0.0/0 => match: 0.0.0.0/0
charon-systemd[64387]: selecting traffic selectors for other:
charon-systemd[64387]: config: 0.0.0.0/0, received: 0.0.0.0/0 => match: 0.0.0.0/0
charon-systemd[64387]: CHILD_SA pskv2-gagarin-child{18} established with SPIs cc453b50_i c90dfc6a_o and TS 0.0.0.0/0 === 0.0.0.0/0
</pre>
<p>Caller side logs:</p>
<pre>daemon.info : 13[IKE] closing expired CHILD_SA rc{64} with SPIs ca657ea2_i c31bd2d9_o and TS 0.0.0.0/0 === 0.0.0.0/0
daemon.info : 13[IKE] sending DELETE for ESP CHILD_SA with SPI ca657ea2
daemon.info : 13[IKE] scheduling CHILD_SA recreate after hard expire
daemon.info : 12[IKE] received DELETE for ESP CHILD_SA with SPI c31bd2d9
daemon.info : 12[IKE] CHILD_SA closed
daemon.info : 11[IKE] establishing CHILD_SA rc{65}
daemon.info : 06[IKE] CHILD_SA rc{65} established with SPIs cbe0669e_i c2e841a2_o and TS 0.0.0.0/0 === 0.0.0.0/0
</pre>
<p>there are two strongSwans which configured in the following way:</p>
<p>Responder (swanctl):</p>
<p>charon.make_before_break = yes</p>
<p>swanctl.conf:<br>
</p>
<pre>conn-defaults {
version = 2
proposals = [ ... ]
local_addrs = [ ... ]
encap = yes
fragmentation = yes
mobike = no
send_certreq = yes
send_cert = always
rekey_time = 3h
}
child-defaults {
ah_proposals =
local_ts = 0.0.0.0/0
rekey_time = 2h
mode = tunnel
dpd_action = clear
ipcomp = no
tfc_padding = 256
}
child-cipher-pfs {
esp_proposals = aes128gcm16-aes192gcm16-aes256gcm16-modp2048, aes128-aes192-aes256-sha256-modp2048
}
pskv2-gagarin: conn-defaults {
remote_addrs = %any
unique = never
local {
auth = psk
id = fqdn:gagarin
}
remote {
auth = psk
id = fqdn:gagarin
}
children {
pskv2-gagarin-child: child-defaults, child-cipher-pfs {
remote_ts = 0.0.0.0/0
if_id_in = 3
if_id_out = 3
updown = /etc/swanctl/bin/xfrm-updown
}
}
}
</pre>
<p><br>
</p>
<p>Caller (ipsec):</p>
<p>charon.make_before_break = yes</p>
<p>ipsec.conf:</p>
<pre>conn rc
keyexchange = ikev2
auto = add
closeaction = restart
dpdaction = restart
dpddelay = 15s
keyingtries = %forever
compress = no
forceencaps = yes
fragmentation = yes
esp = aes256-sha256-modp2048!
ike = aes256-sha256-modp2048!
type = tunnel
mark = 1
# 1m just for debugging purposes
lifetime = 1m
reauth = no
# we are
left = %defaultroute
leftauth = psk
leftid = gagarin
leftsubnet = 0.0.0.0/0
leftupdown = /etc/ipsec.updown
# server
right = [ ... ]
rightauth = psk
rightid = gagarin
rightsubnet = 0.0.0.0/0
</pre>
<p>Two questions:</p>
<p>- what is wrong with make_before_break, why it (according to
logs) closes and then creates new SA?<br>
- what does it mean "no acceptable ENCRYPTION_ALGORITHM found" on
responder side during SA renegotiation?<br>
</p>
<p>Thank you.<br>
</p>
<pre class="moz-signature" cols="72">--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison</pre>
</body>
</html>