[Swan] Duplicate ip xfrm state entries, unconfigured ip xfrm state entries

[Craig Marker]

I’m debugging an issue where my server rebooted and the tunnel didn’t reestablish correctly, and I noticed strange entries in the server’s ip xfrm state table. Namely, a ton of duplicates for established connections. Is this something I should be worried about or something that has been seen before?

src 100.9.123.24 dst 51.179.82.210
proto esp spi 0x0ae2518b reqid 16405 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha256) 0x98164c3a7d85a3877bfdc16fd4749649af8c808bf9a9c1cd73fe1b6a05376c97 128
enc cbc(aes) 0x36af49e3f540bd78a3c9623c8744b0f2b46724df01f21382171f2d04f3180989
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x2f48, oseq 0x0, bitmap 0xffffffff
src 51.179.82.210 dst 100.9.123.24
proto esp spi 0xa1c9b948 reqid 16405 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha256) 0x5c68c11799d6b3cc12dcf40b41c9a63b674987bf3fcd5a0a4a6e0715872c19cf 128
enc cbc(aes) 0x12b1aaecbd2d061e83a2cc136a24544c3e5b86f4f70a3e226241d5c324f39d4a
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x2eb8, bitmap 0x00000000

src 100.9.123.24 dst 51.179.82.210
proto esp spi 0xd6b2b60a reqid 16405 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha256) 0x4d27f940de4f7a41dec27563ce74616e31dd8b4fe5f9873db72a2d757a48700e 128
enc cbc(aes) 0x49606320fc46a025a1d205990b065bfaf256d5b03c3a66d261fa1934a35a541a
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x545, oseq 0x0, bitmap 0xffffffff
src 51.179.82.210 dst 100.9.123.24
proto esp spi 0xeebdea84 reqid 16405 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha256) 0xaa667139b4d5c9cd4d3614631555bcf3b05ff00395b94d97d95fc6a45298a3c6 128
enc cbc(aes) 0xcfd05f1cb590732b6282d78345a44c226b25b809146d822cd00c1e99db5d89d1
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x52b, bitmap 0x00000000

--

I also noticed this strange entry that doesn’t correspond to any .conf file, except it has the src/dst mapping to the VTI Ip address for conn37. Though there is no configuration anywhere that connects conn37.conf and the VTI IP address endpoints (they are applied with ip addr after the connection has been established).

src 172.16.0.4 dst 172.16.0.5
proto esp spi 0x00000000 reqid 0 mode transport
replay-window 0
mark 0x25000000/0xff000000
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
sel src 172.16.0.4/32 dst 172.16.0.5/32 proto icmp type 8 code 0 dev conn37

This seems associated with a confusing messages in /var/log/secure… Is this expected behavior?

Sep  7 08:10:10 cq-use1f-1 pluto[8504]: initiate on demand from 172.16.0.4:8 to 172.16.0.5:0 proto=1 because: acquire

Here’s the associated conn37.conf, if that’s helpful.

conn conn37
left=70.240.163.43
leftid=“@left-70.240.163.43"
leftsubnet=0.0.0.0/0
left=70.240.163.43
right=51.179.82.210
rightid="%fromcert"
rightsubnet=0.0.0.0/0
rightcert=server
right=51.179.82.210
rightupdown=/usr/libexec/ipsec/inspeed_updown
rightcert=server
authby=rsasig
vti-routing=no
encapsulation=yes
keyingtries=0
mark=0x25000000/0xff000000
vti-interface=conn37
phase2alg=aes256-sha2_256
auto=ignore
type=tunnel
compress=no
pfs=yes
ikepad=yes
authby=rsasig
phase2=esp
ikev2=permit
ppk=no
esn=no

--
cm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20180907/62245616/attachment.html>