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

[Paul Wouters]

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