[strongSwan-dev] [PATCH] starter: cleanup SAs when deleting a connection

[Emeric POUPON]

I managed to solve this issue in that way:

--- src/libhydra/plugins/kernel_pfkey/kernel_pfkey_ipsec.c
+++ src/libhydra/plugins/kernel_pfkey/kernel_pfkey_ipsec.c
@@ -2524,6 +2524,13 @@ METHOD(kernel_ipsec_t, add_policy, status_t,
 	enumerator = policy->used_by->create_enumerator(policy->used_by);
 	while (enumerator->enumerate(enumerator, (void**)&current_sa))
 	{
+                if (!current_sa->sa->src->ip_equals(current_sa->sa->src, src)
+                        || !current_sa->sa->dst->ip_equals(current_sa->sa->dst, dst))
+                {
+                        DBG2(DBG_KNL, "policy %R === %R %N, src/dst mismatch, updating",
+					src_ts, dst_ts, policy_dir_names, direction);
+                        break;
+                }
 		if (current_sa->priority >= assigned_sa->priority)
 		{
 			break;

It forces the SP to be updated in the kernel if the installed one has a different src or dst IP address.
Since the "used_by" list now contains entries that have different IP adresses, I am not sure about side effects... It is probably more a hack than a fix.

Best Regards,

Emeric


----- Mail original -----
De: "Emeric POUPON" <emeric.poupon at stormshield.eu>
À: "Christophe Gouault" <christophe.gouault at 6wind.com>
Cc: dev at lists.strongswan.org
Envoyé: Mercredi 4 Mars 2015 14:45:11
Objet: Re: [strongSwan-dev] [PATCH] starter: cleanup SAs when deleting a connection

Hello,

>> @@ -390,7 +390,7 @@ METHOD(stroke_control_t, terminate, void,
>>         while (enumerator->enumerate(enumerator, &del))
>>         {
>>                 status = charon->controller->terminate_ike(charon->controller, del,
>> -                                                       (controller_cb_t)stroke_log, &info, this->timeout);
>> +                                                       msg->output_verbosity == -1 ? NULL : (controller_cb_t)stroke_log, &info, this->timeout);
>>                 report_terminate_status(this, status, out, del, FALSE);
>>         }
>>         enumerator->destroy(enumerator);
>>
>> I really don't know if it is the right fix, since it may raise other problems...
>>
>> What do you think?
>
>Well spotted!
>
>It seems that there was a will to support non blocking connection
>initiation/termination in 2013 (stroke up-nb and down-nb commands were
>added in commit 4182c86aed84933b3efa0367 "stroke: Add non-blocking
>versions of up and down"; they precisely use the output_verbosity),
>but only stroke up-nb works as expected: terminate does not take
>output_verbosity in account...
>
>Christophe
>

Unfortunately, I think this is not enough to solve this issue.
1- change the remote GW's IP address (from 172.16.0.3 to 172.16.2.3), keep the same left/right subnets
2- kill the remote host
3- SIGHUP the daemon.

The old connection is being destroyed in the background (since the DELETE are not acked), and the new connection is loaded.
Since the new connection has the same traffic selectors, the generated SP are the same.
Therefore I get things like that:

Feb 28 03:30:14 11[CFG] added configuration 'new_connection'
...
Feb 28 03:30:14 14[CFG] received stroke: route 'new_connection'
Feb 28 03:30:14 14[CFG] proposing traffic selectors for us:
Feb 28 03:30:14 14[CFG]  192.168.3.0/24
Feb 28 03:30:14 14[CFG] proposing traffic selectors for other:
Feb 28 03:30:14 14[CFG]  192.168.13.0/24
Feb 28 03:30:14 14[CFG] configured proposals: ESP:DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:DES_CBC/HMAC_MD5_96/NO_EXT_SEQ
Feb 28 03:30:14 14[KNL] policy 192.168.3.0/24 === 192.168.13.0/24 out already exists, increasing refcount
Feb 28 03:30:14 14[KNL] policy 192.168.13.0/24 === 192.168.3.0/24 in already exists, increasing refcount

The SP in the kernel still references the IP of the previous GW. The tunnel can never goes up again...

# setkey -DP
192.168.13.0/24[any] 192.168.3.0/24[any] 255
	in ipsec
	esp/tunnel/172.16.1.13-172.16.0.3/unique:1
	spid=1638 seq=2 pid=92527
	refcnt=1
192.168.3.0/24[any] 192.168.13.0/24[any] 255
	out ipsec
	esp/tunnel/172.16.0.3-172.16.1.13/unique:1
	spid=1637 seq=0 pid=92527
	refcnt=1

Maybe we would need to flush the SP first if the last connection that uses it is being deleted?

What do you think?

Emeric
_______________________________________________
Dev mailing list
Dev at lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/dev