Project

General

Profile

Issue #1338

problem with changing esp algorithm in strongswan

Added by Mina Jafari over 4 years ago. Updated over 4 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Affected version:
5.3.5
Resolution:

Description

I have a perfectly working site-to-site IPsec config. The problem occurs when I change "esp" algorithm in config file of both side. My previous esp config was "aes128-md5!". Then, I changed it to "aes192-md5!". IPsec child sa will not Installed by entering following commands: "ipsec down CONN_NAME{CHILD_ID}", "ipsec update" and "ipsec up CONN_NAME". I can reestablish tunnels by bringing SA down and up or by restarting ipsec strongswan. I was wondering if there is a way to establish child sa without restarting engine.

ipsec.conf.sun.first.txt (915 Bytes) ipsec.conf.sun.first.txt first conf file of sun gateway Mina Jafari, 09.03.2016 15:16
ipsec.conf.moon.first.txt (908 Bytes) ipsec.conf.moon.first.txt first conf file of moon gateway Mina Jafari, 09.03.2016 15:16
log1.txt (9.96 KB) log1.txt log file when everything is ok Mina Jafari, 09.03.2016 15:17
ipsec.conf.sun.second.txt (915 Bytes) ipsec.conf.sun.second.txt second conf file of sun gateway Mina Jafari, 09.03.2016 15:21
ipsec.conf.moon.second.txt (908 Bytes) ipsec.conf.moon.second.txt second conf file of moon gateway Mina Jafari, 09.03.2016 15:22
console_output.sun.txt (3.43 KB) console_output.sun.txt console output of sun gateway Mina Jafari, 09.03.2016 15:26
log2.txt (3.2 KB) log2.txt log file when one of tunnels is not established Mina Jafari, 09.03.2016 15:27

Related issues

Related to Feature #129: Relations between ike/child/peer_cfgAssigned13.05.2011

History

#1 Updated by Tobias Brunner over 4 years ago

  • Status changed from New to Feedback

IPsec child sa will not Installed by entering following commands: "ipsec down CONN_NAME{CHILD_ID}", "ipsec update" and "ipsec up CONN_NAME".

Why not? What happens instead? Please post the logs.

I can reestablish tunnels by bringing SA down and up

You just said above that this doesn't work. Or are you referring to the IKE_SA?

#2 Updated by Mina Jafari over 4 years ago

I can reestablish tunnels by bringing SA down and up

You just said above that this doesn't work. Or are you referring to the IKE_SA?

Thanks for your answer. Yes, I mean IKE_SA. I have attached my config and log files. I have a site-to-site VPN between sun and moon gateways. "ipsec.conf.sun.first.txt" and "ipsec.conf.moon.first.txt" consists both sun and moon gateways ipsec.conf file respectively. In this state everithing is ok. "log1.txt" is log file of this state.

After that, I changed ipsec.conf file of sun and moon gateways into "ipsec.conf.sun.second.txt" and "ipsec.conf.moon.second.txt" respectively. In this state, "esp" option of "sample_3" connection is changed to "aes192-md5!". Then, I entered following commands in moon and sun gateways respectively: "ipsec down sample_3{CHILD_ID}", "ipsec update", "ipsec up sample_3" and "ipsec statusall".
Console output of sun gateway is in "console_output.sun.txt". "sample_3 child_SA" in not installed. In "log2.txt", log file of not installed child_SA situation exists.

#3 Updated by Tobias Brunner over 4 years ago

Console output of sun gateway is in "console_output.sun.txt". "sample_3 child_SA" in not installed. In "log2.txt", log file of not installed child_SA situation exists.

This is due to a long-standing issue (#129). The configs passed to the stroke plugin via starter, which parses ipsec.conf, are split into several objects for IKE_SA and CHILD_SA specific data. Equal IKE_SA configs are merged and additional CHILD_SA configs are just added to the same object. All these objects are ref counted, so when an SA is established it will have pointers to the config objects that were created when the original config was loaded.

The problem is that ipsec update first completely removes changed configs and then adds the new ones. Deleting a config means that all CHILD_SA config objects with that config's name are removed from all IKE_SA config objects. As mentioned do established IKE_SAs have pointers to the modified objects, so these CHILD_SA config objects are actually removed from the live IKE_SA config objects. And because the stroke plugin removes IKE_SA config objects without any CHILD_SA config objects after deleting a config (in your sample_3 has only one CHILD_SA), the config added by ipsec update later on will create a new IKE_SA config object with new CHILD_SA config objects. But the established IKE_SA has still a pointer to the old IKE_SA config object that now has no CHILD_SA configs and it does not know about the new config.

This wouldn't be an issue if the IKE_SA config object had more than one CHILD_SA config object assigned and only one of them was deleted/updated, because that would not have cause the IKE_SA config object to get deleted and CHILD_SAs would have been added to the existing IKE_SA config object. And as you noticed it also works if you terminate and restart the IKE_SA as the new SAs will be based on the new config objects.

You might want to try configuring the daemon via swanctl/vici, which handles such CHILD_SA config updates better.

#4 Updated by Tobias Brunner over 4 years ago

  • Related to Feature #129: Relations between ike/child/peer_cfg added

Also available in: Atom PDF