[Openswan Users] DPD and ERROR: netlink response for Add SA esp.xxxxxxxx at y.y.y.y included errno 17: File exists

[Paul Wouters]

On Tue, 19 Jul 2011, L Felgr wrote:

> Q: If the powercycled unit comes back on, and reconnects to the other unit, the IPsec SA should be re-established
> and the older SA on the unit that did not get power cycled should get replaced. Are you not seeing that
> happening?
>  
> R: I am not sure. If I select appropriate lines from syslog listing from Dev1 then I can see this:
> ****************************************
> Action: Dev2 - power on
> ****************************************
> 2011-07-18 11:43:10 pluto[431]: "ipsec1" #9: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=0x0b056df3 0x17354389
> xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=enabled}
> ****************************************
> Action: Dev2 - reboot
> ****************************************
> 2011-07-18 11:47:59 pluto[431]: "ipsec1" #12: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=0xf05a1802
> 0x32e9fe4f xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=enabled}
> ****************************************
> Action: Dev2 - another reboot
> ****************************************
> 2011-07-18 11:59:07 pluto[431]: "ipsec1" #17: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
> 2011-07-18 11:59:07 pluto[431]: "ipsec1" #17: ERROR: netlink response for Add SA esp.b056df3 at 10.0.3.114 included errno
> 17: File exists

My answer would be "that kernel did not actually reboot". SPIs are not serially numbered, so rebooting
a device should give totally different SPI numbers. Try using "ip xfrm pol" and "ip xfrm state" before
starting openswan. It should be totally empty. If not, there is some weird kernel state saving happening
somewhere when you think the unit is rebooting.

> Do you think I should use one of --debug-* options? Would it help to solve the problem?

I doubt it. NETKEY has no debugging facilities. This is already the most you can get the kernel to tell you.

Paul