On Fri, 7 Sep 2018, Craig Marker wrote:
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?
Usually that means the two endpoints keep renegotiating for some reason, and libreswan is keeping the old ones for a bit before cleaning them up.
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 is an ACQUIRE in larval state. It happens during on-demand tunnels. It means the kernel send the ACQUIRE to the IKE daemon, and now the IKE daemon is expected to replace this with a tunnel IPsec SA. I think this is just a side effect of the many re-establishing you are seeing.
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
Yeah that is the 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
If you want this to go up at boot, you should put in auto=start
type=tunnel compress=no pfs=yes ikepad=yes authby=rsasig phase2=esp ikev2=permit ppk=no esn=no
I guess the reason for why it keeps restarting the tunnel should be in the logs on one of the endpoints? Paul _______________________________________________ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
