[strongSwan] unable to install policy 192.168.0.0/16 === 10.176.0.0/13 in (mark 0/0x00000000) for reqid 2, the same policy for reqid 1 exists

Martin Willi martin at strongswan.org
Tue Mar 10 14:49:12 CET 2015


Hi,

Sorry for my previous mail, this time with some content:

> I have only started running into this since we started using more than
> one subnet in the left side of the connection.

> 	    leftsubnet=10.176.0.0/13,10.130.0.0/16
> 	    rightsubnet=192.168.0.0/16

>  Iona-VPN-FW[1]: IKEv2 SPIs: 550d0c34bc66ce4e_i* da285a283fb7a4d1_r, rekeying in 23 hours
>  Iona-VPN-FW{1}:  INSTALLED, TUNNEL, ESP in UDP SPIs: ccb6a085_i ad93852a_o
>  Iona-VPN-FW{1}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 360 bytes_o (9 pkts, 2965s ago), rekeying in 33 seconds
>  Iona-VPN-FW{1}:   10.176.0.0/13 === 192.168.0.0/16
>  Iona-VPN-FW{2}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c01ce92f_i 0a7d4641_o
>  Iona-VPN-FW{2}:  AES_CBC_128/HMAC_SHA1_96, 2479 bytes_i (17 pkts, 3272s ago), 4873 bytes_o (15 pkts, 3272s ago), rekeying in 2 seconds
>  Iona-VPN-FW{2}:   10.130.0.0/16 === 192.168.0.0/16

Actually, what you have configured and what got negotiated doesn't
really match. If you have multiple subnets in a connection, these should
get negotiated in a single CHILD_SA. However, you have multiple
CHILD_SAs, most likely because your peer prefers to negotiate that.

You may try to configure separate CHILD_SAs for your subnets. With
ipsec.conf, you'll have to define separate "conn" entries with the same
base settings, but different subnet configurations. charon automatically
merges such configurations to negotiate them under the same IKE_SA.

> Mar  4 16:58:14 ip-10-180-0-12 charon: 16[ENC] generating CREATE_CHILD_SA request 2 [ N(REKEY_SA) SA No TSi TSr ]
> Mar  4 16:58:14 ip-10-180-0-12 charon: 16[NET] sending packet: from 10.180.0.12[4500] to 2.2.2.2[4500] (332 bytes)
> Mar  4 16:58:14 ip-10-180-0-12 charon: 09[NET] received packet: from 2.2.2.2[4500] to 10.180.0.12[4500] (236 bytes)
> Mar  4 16:58:14 ip-10-180-0-12 charon: 09[ENC] parsed CREATE_CHILD_SA response 2 [ SA No TSi TSr ]
> Mar  4 16:58:14 ip-10-180-0-12 charon: 09[CFG] unable to install policy 10.176.0.0/13 === 192.168.0.0/16 out (mark 0/0x00000000) for reqid 2, the same policy for reqid 1 exists
> Mar  4 16:58:14 ip-10-180-0-12 charon: 09[CFG] unable to install policy 192.168.0.0/16 === 10.176.0.0/13 in (mark 0/0x00000000) for reqid 2, the same policy for reqid 1 exists
> Mar  4 16:58:14 ip-10-180-0-12 charon: 09[CFG] unable to install policy 192.168.0.0/16 === 10.176.0.0/13 fwd (mark 0/0x00000000) for reqid 2, the same policy for reqid 1 exists
> Mar  4 16:58:14 ip-10-180-0-12 charon: 09[CFG] unable to install policy 10.176.0.0/13 === 192.168.0.0/16 out (mark 0/0x00000000) for reqid 2, the same policy for reqid 1 exists
> Mar  4 16:58:14 ip-10-180-0-12 charon: 09[CFG] unable to install policy 192.168.0.0/16 === 10.176.0.0/13 in (mark 0/0x00000000) for reqid 2, the same policy for reqid 1 exists
> Mar  4 16:58:14 ip-10-180-0-12 charon: 09[CFG] unable to install policy 192.168.0.0/16 === 10.176.0.0/13 fwd (mark 0/0x00000000) for reqid 2, the same policy for reqid 1 exists
> Mar  4 16:58:14 ip-10-180-0-12 charon: 09[IKE] unable to install IPsec policies (SPD) in kernel
> Mar  4 16:58:14 ip-10-180-0-12 charon: 09[IKE] failed to establish CHILD_SA, keeping IKE_SA

Because of this mismatch between configuration and negotiated SAs, it
seems that when rekeying the selectors negotiated do not match the
previous CHILD_SA, but the other one separately negotiated.

I think you should change your configuration to use separate CHILD_SAs,
or try to negotiate all subnets under a single CHILD_SA on the Cisco
side. If that doesn't work, you may try a build from git sources; we
recently merged changes that avoid these policy conflicts. But most
likely you'll end up with the wrong selectors after rekeying the
CHILD_SA.

Regards
Martin



More information about the Users mailing list