[strongSwan] Odd behaviour of a simple tunnel: policy already exists, try to update it

[Michael Schwartzkopff]

Hi,


we have an odd problem with a simple VPN tunnel. We want to connect to a 
remote network. That seems to work.

For availability reasons, we have an additional process that monitors 
the connectivity via the application. If the application says that the 
connection is not working any more, it triggers a "swanctl --load-all".


So when the connection is reloaded, the logs read like:

IKE] initiating IKE_SA connection[1] to x.x.x.x

(...)

[IKE] IKE_SA connction[1] established between 
x.x.x.x[x.x.x.x]...y.y.y.y[y.y.y.y]
[IKE] scheduling rekeying in 14397s
[IKE] maximum IKE_SA lifetime 15837s
[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
[CFG] selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
[KNL] policy already exists, try to update it
[KNL] policy already exists, try to update it
[KNL] policy already exists, try to update it
[IKE] CHILD_SA net-net{1} established with SPIs c2319a61_i 900ab257_o 
and TS x.x.x.x/32 === z.z.z.z/24
initiate completed successfully


What does the KNL message "policy already exist" really mean? Is there 
an existing XFRM policy in the kernel, that will not be updated for the 
new child? Or is it updated with the new SPIs?


Why does the application loose it connection always after one hour 
(rekey_time) minus some rand_time minutes.


Can it be that the XFRM sets are not updated through the swanctl 
--load-all, expire after one hour and the application looses the 
connection and restarts the connection?


How to improve the situation? Delete the policy before "--load-all"? Any 
other suggestions?


Can DPD help?



Mit freundlichen Grüßen,

-- 

[*] sys4 AG
  
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
  
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein