[strongSwan] trap not found, unable to acquire reqid
divya mohan
m.divya.mohan at zoho.com
Thu Dec 4 07:40:27 CET 2014
Hi,
I am facing an issue with charon (strongSwan 4.4.0) that, if SA
entries are flushed from responder side, further initiation of tunnel
from responder is not feasible.
The error I am getting on responder is "trap not found, unable to
acquire reqid".
I saw a related discussion here -
https://lists.strongswan.org/pipermail/dev/2013-May/000744.html
which was concluded with
"The narrowing use case is more hypothetical, and can be avoided by
adjusting the configuration. So I don't think it is that important."
Could you please elaborate on how the configuration needs to be adjusted.
Following is the test setup and configuration:
NODE-A ------ NODE-B
20.0.0.1 20.0.0.2
After starting ipsec on both nodes, follow below steps to reproduce the issue.
Step: 1 ) Start traffic from NODE-A.
CHILD_SAs are established.
NODE-A being the initiator, SA and SP have reqid as 1.
NODE-B is having reqid as 2.
NODE-A# ping 20.0.0.2 -c 2
PING 20.0.0.2 (20.0.0.2) 56(84) bytes of data.
10[IKE] initiating IKE_SA r1~v1[1] to 20.0.0.2
11[IKE] sending cert request for "C=de, ST=Bayern, L=Munich, O=Nokia
Siemens Networks, OU=RTP, CN=www.nokiasiemensnetworks.com,
E=gianluigi.ongaro at nsn.com"
11[IKE] authentication of '20.0.0.1' (myself) with pre-shared key
11[IKE] establishing CHILD_SA r1~v1{1}
12[IKE] authentication of '20.0.0.2' with pre-shared key successful
12[IKE] IKE_SA r1~v1[1] established between
20.0.0.1[20.0.0.1]...20.0.0.2[20.0.0.2]
12[IKE] scheduling rekeying in 6489s
12[IKE] maximum IKE_SA lifetime 6849s
12[IKE] CHILD_SA r1~v1{1} established with SPIs c3a15834_i c115694c_o
and TS 20.0.0.0/24[icmp] === 20.0.0.0/24[icmp]
64 bytes from 20.0.0.2: icmp_req=2 ttl=64 time=0.365 ms
--- 20.0.0.2 ping statistics ---
2 packets transmitted, 1 received, 50% packet loss, time 999ms
rtt min/avg/max/mdev = 0.365/0.365/0.365/0.000 ms
NODE-A#
NODE-A# ip xfrm state
src 20.0.0.1 dst 20.0.0.2
proto esp spi 0xc115694c reqid 1 mode tunnel
replay-window 64 flag af-unspec
auth-trunc hmac(md5) 0x76e0bb2adf423119acf543e92aa187db 96
enc cbc(des3_ede) 0x90dcfa0036f5e8b70351899e60186a064e583d33c8b17ac3
src 20.0.0.2 dst 20.0.0.1
proto esp spi 0xc3a15834 reqid 1 mode tunnel
replay-window 64 flag af-unspec
auth-trunc hmac(md5) 0x63f17c839b726d7b093e52878e6a84ff 96
enc cbc(des3_ede) 0xefeb1f7e4f820fba45390a3cb5b95bcd3c815b04e2231b59
NODE-A# ip xfrm policy
src 20.0.0.0/24 dst 20.0.0.0/24 proto icmp
dir fwd priority 1758
tmpl src 20.0.0.2 dst 20.0.0.1
proto esp reqid 1 mode tunnel
src 20.0.0.0/24 dst 20.0.0.0/24 proto icmp
dir in priority 1758
tmpl src 20.0.0.2 dst 20.0.0.1
proto esp reqid 1 mode tunnel
src 20.0.0.0/24 dst 20.0.0.0/24 proto icmp
dir out priority 1758
tmpl src 20.0.0.1 dst 20.0.0.2
proto esp reqid 1 mode tunnel
NODE-B# 11[IKE] 20.0.0.1 is initiating an IKE_SA
12[IKE] received cert request for unknown ca with keyid
5b:76:24:98:d4:25:33:cb:b2:13:32:28:cd:a0:86:f7:0f:40:59:a3
12[CFG] looking for peer configs matching 20.0.0.2[%any]...20.0.0.1[20.0.0.1]
12[CFG] selected peer config 'r1~v1'
12[IKE] authentication of '20.0.0.1' with pre-shared key successful
12[IKE] authentication of '20.0.0.2' (myself) with pre-shared key
12[IKE] IKE_SA r1~v1[1] established between
20.0.0.2[20.0.0.2]...20.0.0.1[20.0.0.1]
12[IKE] scheduling rekeying in 6509s
12[IKE] maximum IKE_SA lifetime 6869s
12[IKE] CHILD_SA r1~v1{2} established with SPIs c115694c_i c3a15834_o
and TS 20.0.0.0/24[icmp] === 20.0.0.0/24[icmp]
NODE-B# ip xfrm state
src 20.0.0.2 dst 20.0.0.1
proto esp spi 0xc3a15834 reqid 2 mode tunnel
replay-window 64 flag af-unspec
auth-trunc hmac(md5) 0x63f17c839b726d7b093e52878e6a84ff 96
enc cbc(des3_ede) 0xefeb1f7e4f820fba45390a3cb5b95bcd3c815b04e2231b59
src 20.0.0.1 dst 20.0.0.2
proto esp spi 0xc115694c reqid 2 mode tunnel
replay-window 64 flag af-unspec
auth-trunc hmac(md5) 0x76e0bb2adf423119acf543e92aa187db 96
enc cbc(des3_ede) 0x90dcfa0036f5e8b70351899e60186a064e583d33c8b17ac3
NODE-B# ip xfrm policy
src 20.0.0.0/24 dst 20.0.0.0/24 proto icmp
dir fwd priority 1758
tmpl src 20.0.0.1 dst 20.0.0.2
proto esp reqid 2 mode tunnel
src 20.0.0.0/24 dst 20.0.0.0/24 proto icmp
dir in priority 1758
tmpl src 20.0.0.1 dst 20.0.0.2
proto esp reqid 2 mode tunnel
src 20.0.0.0/24 dst 20.0.0.0/24 proto icmp
dir out priority 1758
tmpl src 20.0.0.2 dst 20.0.0.1
proto esp reqid 2 mode tunnel
Step 2) Flush the SAs from NODE-B (which was responder); and try to
initiate tunnel from NODE-B, by starting traffic.
This will fail.
NODE-B# ip xfrm state flush
NODE-B#
NODE-B# ip xfrm state
NODE-B# ping 20.0.0.1
PING 20.0.0.1 (20.0.0.1) 56(84) bytes of data.
14[CFG] trap not found, unable to acquire reqid 2
Configurations:
NODE-A# cat /etc/ipsec.conf
# ipsec.conf
config setup
charonstart=yes
plutostart=no
uniqueids=no
charondebug="knl 0,enc 0,net 0"
conn %default
auto=route
keyexchange=ikev2
reauth=no
conn r1~v1
rekeymargin=360
rekeyfuzz=100%
left=20.0.0.1
right=20.0.0.2
leftsubnet=20.0.0.0/24
rightsubnet=20.0.0.0/24
leftprotoport=1
rightprotoport=1
authby=secret
leftid=20.0.0.1
rightid=%any
ike=3des-md5-modp768!
esp=3des-md5!
type=tunnel
ikelifetime=7200s
keylife=3600s
mobike=no
auto=route
reauth=no
NODE-B# cat /etc/ipsec.conf
# ipsec.conf
config setup
charonstart=yes
plutostart=no
uniqueids=no
charondebug="knl 0,enc 0,net 0"
conn %default
auto=route
keyexchange=ikev2
reauth=no
conn r1~v1
rekeymargin=360
rekeyfuzz=100%
left=20.0.0.2
right=20.0.0.1
leftsubnet=20.0.0.0/24
rightsubnet=20.0.0.0/24
leftprotoport=1
rightprotoport=1
authby=secret
leftid=20.0.0.2
rightid=%any
ike=3des-md5-modp768!
esp=3des-md5!
type=tunnel
ikelifetime=7200s
keylife=3600s
mobike=no
auto=route
reauth=no
-- Divya
More information about the Users
mailing list