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
_______________________________________________ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan