[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

Tormod Macleod TMacleod at paywizard.com
Fri Mar 20 18:04:37 CET 2015


Hi Martin,
 
Thanks very much for getting back to me. I took your advice and set up individual CHILD_SAs. Everything is working well since.
 
I'll try my previous configuration once strongswan5.3.0 is available and see whether that changes anything just out of interest. However, I'm very happy with the current solution.
 
Thanks again for your help,
 
 
Tormod

>>> Martin Willi <martin at strongswan.org> 10/03/2015 13:49 >>>
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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



Please consider the environment before printing this email

*********************************************************************
  This e-mail and any attachments are confidential.  If it is not for you, please inform us and delete it immediately without disclosing, copying, or distributing it.  If the content is not about the business of PayWizard Group PLC or its clients, then it is neither from nor sanctioned by PayWizard Group PLC.  Use of this or any other PayWizard Group PLC e-mail facility signifies consent to interception by PayWizard Group PLC.  The views expressed in this email or any attachments may not reflect the views and opinions of PayWizard Group PLC.  This message has been scanned for viruses and dangerous content by MailScanner, but PayWizard Group PLC accepts no liability for any damage caused by the transmission of any viruses.  PayWizard Group PLC is a public limited company registered in Scotland (SC175703) with its registered office at Cluny Court, John Smith Business Park, Kirkcaldy, Fife, KY2 6QJ.  ********************************************************************

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150320/277d2d11/attachment-0001.html>


More information about the Users mailing list