[strongSwan] FW: Traffic dropped when IKE initiation happen between two nodes simultaneously.

Emeric POUPON emeric.poupon at stormshield.eu
Tue Apr 7 13:10:46 CEST 2015


Hello,

I may have a similar, or at least related issue here.
Here is the configuration:

172.16.X.0/24 - 172.16.255.254 GW1 10.0.0.1 <----> 10.0.0.2 GW2 172.17.255.254 - 172.17.X.0/24

The goal is to connect subnets 172.16.X.0/24 and 172.17.X.0/24
X is ranging from 0 to 200, we have 200 connections defined in each configuration.
(172.16.0.0/24 <=> 172.17.0.0/24, 172.16.1.0/24 <=> 172.17.1.0/24, ...)

I send traffic from both sides and from all subnets "simultaneously".

If "uniqueids" is set to yes, we end up with very questionable situations:
- I get at least 4 or 5 IKE SA on each GW.
  -> each IKE SA is responsible for some CHILD SA. They do not seem to be duplicated.
  -> this is strange since they are supposed to be unique
- the number of ESTABLISHED IKE SA on each GW is not always the same at a same time (!)
  -> the CHILD SA negotiated from the extra remaining IKE SA are not usable, therefore traffic is getting dropped until DPD detects the IKE SA is dead

Setting uniqueids to "never" seems to correct the problem, but I not sure about side effects (still working on this)

What do you think?

Best Regards,
Emeric

----- Mail original -----
De: "Krishna G, Suhas (NSN - IN/Bangalore)" <suhas.krishna_g at nsn.com>
À: "ext Noel Kuntze" <noel at familie-kuntze.de>, users at lists.strongswan.org
Envoyé: Vendredi 13 Février 2015 08:14:16
Objet: Re: [strongSwan] FW: Traffic dropped when IKE initiation happen between two nodes simultaneously.

Hi, 
Can anyone please comment on this. I tested this with the new strongswan version 5.2 and noticed the same behavior. 
Regards 
Suhas 
-----Original Message----- 
From: users-bounces at lists.strongswan.org [ mailto:users-bounces at lists.strongswan.org ] On Behalf Of ext Krishna G, Suhas (NSN - IN/Bangalore) 
Sent: Monday, February 09, 2015 2:24 PM 
To: ext Noel Kuntze; users at lists.strongswan.org 
Subject: Re: [strongSwan] FW: Traffic dropped when IKE initiation happen between two nodes simultaneously. 
Hi Noel, 
One more observation with respect to the below query. With "uniqueids=yes", as you mentioned only one pair of SA is formed but I found a limitation w.r.t this. I configured IPSec(same setup as I had mentioned in previous mail) between two nodes(peer1-------peer2) with the uniqueids=yes option in the ipsec.conf file on both ends. Apparently, no SAs are duplicated when I do "ipsec up" multiple times from one end. Old SAs are being replaced by new ones. But when I do "ipsec up" for the first time from the other end , though SAs are already established, another set of SA is initiated. So two set of SAs get established. But no further SAs are duplicated even after "ipsec up" multiple times from either ends. So, there can exist max two set of SAs between the same end points with the "uniqueids=yes" option. First set of SA initiated from peer1 and the second set initiated by peer2 . So, I think there is no actual check for SA being established but there is only a check for the number of times "ipsec up" is done from one end which is a drawback. Is this the same behavior in the new version of strongswan? 
Regards 
Suhas 
-----Original Message----- 
From: users-bounces at lists.strongswan.org [ mailto:users-bounces at lists.strongswan.org ] On Behalf Of ext Krishna G, Suhas (NSN - IN/Bangalore) 
Sent: Friday, February 06, 2015 12:12 PM 
To: ext Noel Kuntze; users at lists.strongswan.org 
Subject: Re: [strongSwan] FW: Traffic dropped when IKE initiation happen between two nodes simultaneously. 
Hi Noel, 
I had forgot to ask one thing. Does any configuration in strongswan.conf file affect this. How exactly does this uniqueid stuff work? 
My strongsan.conf file for reference just in case: 
# strongswan.conf 
charon { 
reuse_ikesa=no 
install_routes=no 
block_threshold=50 
cookie_threshold=100 
} 
-----Original Message----- 
From: ext Noel Kuntze [ mailto:noel at familie-kuntze.de ] 
Sent: Thursday, February 05, 2015 12:07 AM 
To: Krishna G, Suhas (NSN - IN/Bangalore); users at lists.strongswan.org 
Subject: Re: [strongSwan] FW: Traffic dropped when IKE initiation happen between two nodes simultaneously. 
-----BEGIN PGP SIGNED MESSAGE----- 
Hash: SHA256 
Hello Krishna, 
Yes, that is relevant. I have a net-to-net setup here with the newest strongSwan 
version and PSK authentication, that does not show this bad behaviour. 
You might want to try a newer version. 
Mit freundlichen Grüßen/Regards, 
Noel Kuntze 
GPG Key ID: 0x63EC6658 
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 
Am 04.02.2015 um 11:07 schrieb Krishna G, Suhas (NSN - IN/Bangalore): 
> Hi Noel, 
> 
> Thanks for the quick response. I tested with the combination of changes you suggested but am still facing the same issue. I found a thread relating to this: http://permalink.gmane.org/gmane.network.vpn.strongswan.devel/671 
> Is this of any relevance? The charon does not check for duplicate SAs and delete them? The duplicate SAs persist even after rekeying. 
> 
> Regards 
> Suhas Krishna 
> 
> -----Original Message----- 
> From: users-bounces at lists.strongswan.org [ mailto:users-bounces at lists.strongswan.org ] On Behalf Of ext Noel Kuntze 
> Sent: Wednesday, February 04, 2015 1:23 AM 
> To: users at lists.strongswan.org 
> Subject: Re: [strongSwan] FW: Traffic dropped when IKE initiation happen between two nodes simultaneously. 
> 
> 
> Hello Kirshna, 
> 
> You set "uniqueids=no". That causes that behaviour. 
> Use "uniqueids=yes", "uniqueids=keep" or "uniqueids=replace". 
> 
> Mit freundlichen Grüßen/Regards, 
> Noel Kuntze 
> 
> GPG Key ID: 0x63EC6658 
> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 
> 
> Am 03.02.2015 um 11:05 schrieb Krishna G, Suhas (NSN - IN/Bangalore): 
> > Hi, 
> 
> > I am testing a simple scenario using ikev2. The setup is as follows: 
> 
> > (Traffic generator2)30.0.0.1-------(30.0.0.2)node2(20.0.0.1)----------(20.0.0.2)node1(40.0.0.1)------------40.0.0.2(Traffic generator1) 
> > eth2 eth3 eth2 
> > (vlan201) 
> 
> > Node1: 
> > # ipsec.conf 
> 
> > config setup 
> > charonstart=yes 
> > plutostart=no 
> > uniqueids=no 
> > charondebug="knl 0,enc 0,net 0" 
> > conn %default 
> > auto=route 
> > keyexchange=ikev2 
> > reauth=no 
> > conn r2~v2 
> > rekeymargin=150 
> > rekeyfuzz=100% 
> > left=20.0.0.2 
> > right=20.0.0.1 
> > leftsubnet=40.0.0.2/32 
> > rightsubnet=30.0.0.1/32 
> > authby=secret 
> > leftid=20.0.0.2 
> > rightid=%any 
> > ike=aes128-sha1-modp1024! 
> > esp=aes128-sha1! 
> > type=tunnel 
> > ikelifetime=2000s 
> > keylife=1500s 
> > mobike=no 
> > auto=route 
> > reauth=no 
> 
> > addresses configured: 
> > 1. vlan201 at eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
> > link/ether 00:30:64:26:2f:5f brd ff:ff:ff:ff:ff:ff 
> > inet 20.0.0.2/24 brd 20.0.0.255 scope global vlan201 
> > inet6 fe80::30:6400:a26:2f5f/64 scope link 
> > valid_lft forever preferred_lft forever 
> 
> > 2. eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 
> > link/ether 00:30:64:26:2f:5e brd ff:ff:ff:ff:ff:ff 
> > inet 40.0.0.1/24 brd 40.0.0.255 scope global eth2 
> > inet6 fe80::30:6400:426:2f5e/64 scope link 
> > valid_lft forever preferred_lft forever 
> 
> 
> > routes: 
> > 40.0.0.0/24 dev eth2 proto kernel scope link src 40.0.0.1 
> > 20.0.0.0/24 dev vlan201 proto kernel scope link src 20.0.0.2 
> > 30.0.0.0/24 via 20.0.0.1 dev vlan201 proto gated 
> 
> 
> 
> > Node2 : 
> > # ipsec.conf 
> 
> > config setup 
> > charonstart=yes 
> > plutostart=no 
> > uniqueids=no 
> > charondebug="knl 0,enc 0,net 0" 
> > conn %default 
> > auto=route 
> > keyexchange=ikev2 
> > reauth=no 
> > conn r2~v2 
> > rekeymargin=150 
> > rekeyfuzz=100% 
> > left=20.0.0.1 
> > right=20.0.0.2 
> > leftsubnet=30.0.0.1/32 
> > rightsubnet=40.0.0.2/32 
> > authby=secret 
> > leftid=20.0.0.1 
> > rightid=%any 
> > ike=aes128-sha1-modp1024! 
> > esp=aes128-sha1! 
> > type=tunnel 
> > ikelifetime=2000s 
> > keylife=1500s 
> > dpdaction=clear 
> > dpddelay=20 
> > mobike=no 
> > auto=route 
> > reauth=no 
> 
> 
> > addresses configured: 
> > 1. vlan201 at eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
> > link/ether 00:30:64:26:32:02 brd ff:ff:ff:ff:ff:ff 
> > inet 20.0.0.1/24 brd 20.0.0.255 scope global vlan201 
> > inet6 fe80::30:6400:a26:3202/64 scope link 
> > valid_lft forever preferred_lft forever 
> 
> 
> > 2. eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 
> > link/ether 00:30:64:26:32:01 brd ff:ff:ff:ff:ff:ff 
> > inet 30.0.0.2/24 brd 30.0.0.255 scope global eth2 
> > inet6 fe80::30:6400:426:3201/64 scope link 
> > valid_lft forever preferred_lft forever 
> 
> 
> > routes: 
> > 40.0.0.0/24 via 20.0.0.2 dev vlan201 proto gated 
> > 20.0.0.0/24 dev vlan201 proto kernel scope link src 20.0.0.1 
> > 30.0.0.0/24 dev eth2 proto kernel scope link src 30.0.0.2 
> 
> 
> > In my setup, I am pumping traffic from both ends simultaneously. I see that IKE initiations happen simultaneously from both ends and two pair of SAs are formed instead of one as shown below: 
> 
> > 20.0.0.2 20.0.0.1 
> > esp mode=tunnel spi=3303990082(0xc4eee342) reqid=1(0x00000001) 
> > E: aes-cbc 2d2d6603 aa9bc830 1c3ee36a d964b1f1 
> > A: hmac-sha1 3889f511 69cd3c4e 6f416739 e5c685cc 3f316067 
> > seq=0x00000000 replay=64 flags=0x00000000 state=mature 
> > created: Jan 23 20:22:13 2015 current: Jan 23 20:22:37 2015 
> > diff: 24(s) hard: 300(s) soft: 268(s) 
> > last: Jan 23 20:22:13 2015 hard: 0(s) soft: 0(s) 
> > current: 285648670(bytes) hard: 0(bytes) soft: 0(bytes) 
> > allocated: 283945 hard: 0 soft: 0 
> > sadb_seq=1 pid=24064 refcnt=0 
> > 20.0.0.1 20.0.0.2 
> > esp mode=tunnel spi=3422609051(0xcc00de9b) reqid=1(0x00000001) 
> > E: aes-cbc 37be21d3 79d00867 968bcc4e 21c3a5c8 
> > A: hmac-sha1 f46a45e7 c3b90b4e 20e3e68e 782a8b48 5d2d7758 
> > seq=0x00000000 replay=64 flags=0x00000000 state=mature 
> > created: Jan 23 20:22:13 2015 current: Jan 23 20:22:37 2015 
> > diff: 24(s) hard: 300(s) soft: 265(s) 
> > last: hard: 0(s) soft: 0(s) 
> > current: 0(bytes) hard: 0(bytes) soft: 0(bytes) 
> > allocated: 0 hard: 0 soft: 0 
> > sadb_seq=2 pid=24064 refcnt=0 
> > 20.0.0.2 20.0.0.1 
> > esp mode=tunnel spi=3272081281(0xc307ff81) reqid=2(0x00000002) 
> > E: aes-cbc 6c9cbd30 0aa302bb 9741ca7f 231ce550 
> > A: hmac-sha1 9c21160b a03990f5 a07d2c29 a18d8b7f 02c020a7 
> > seq=0x00000000 replay=64 flags=0x00000000 state=mature 
> > created: Jan 23 20:22:13 2015 current: Jan 23 20:22:37 2015 
> > diff: 24(s) hard: 300(s) soft: 264(s) 
> > last: Jan 23 20:22:13 2015 hard: 0(s) soft: 0(s) 
> > current: 20120(bytes) hard: 0(bytes) soft: 0(bytes) 
> > allocated: 20 hard: 0 soft: 0 
> > sadb_seq=3 pid=24064 refcnt=0 
> > 20.0.0.1 20.0.0.2 
> > esp mode=tunnel spi=3466205953(0xce9a1b01) reqid=2(0x00000002) 
> > E: aes-cbc 465a0a5f 454ffbcc d4a63bf7 f3f102e5 
> > A: hmac-sha1 36cefc1d 6c9729fe 4a142a0d 66033097 4b6e9d3a 
> > seq=0x00000000 replay=64 flags=0x00000000 state=mature 
> > created: Jan 23 20:22:13 2015 current: Jan 23 20:22:37 2015 
> > diff: 24(s) hard: 300(s) soft: 261(s) 
> > last: Jan 23 20:22:13 2015 hard: 0(s) soft: 0(s) 
> > current: 285656718(bytes) hard: 0(bytes) soft: 0(bytes) 
> > allocated: 283953 hard: 0 soft: 0 
> > sadb_seq=0 pid=24064 refcnt=0 
> 
> 
> > Due to this there is a 100% traffic drop seen at both ends. I referred to a similar query posted - _https://lists.strongswan.org/pipermail/users/2012-October/003765.html_ but no conclusion was drawn out of that. 
> 
> > According to my investigation, the two nodes are using different set of SAs for communication resulting in the problem. tcpdump of the packets flowing is as below: 
> 
> > 20:23:48.400585 IP 20.0.0.2 > 20.0.0.1: ESP(spi=0xc4eee342,seq=0x11556a), length 1044 
> > 20:23:48.400629 IP 20.0.0.1 > 20.0.0.2: ESP(spi=0xce9a1b01,seq=0x115573), length 1044 
> > 20:23:48.400669 IP 20.0.0.2 > 20.0.0.1: ESP(spi=0xc4eee342,seq=0x11556b), length 1044 
> > 20:23:48.400713 IP 20.0.0.1 > 20.0.0.2: ESP(spi=0xce9a1b01,seq=0x115574), length 1044 
> > 20:23:48.400752 IP 20.0.0.2 > 20.0.0.1: ESP(spi=0xc4eee342,seq=0x11556c), length 1044 
> > 20:23:48.400796 IP 20.0.0.1 > 20.0.0.2: ESP(spi=0xce9a1b01,seq=0x115575), length 1044 
> > 20:23:48.400836 IP 20.0.0.2 > 20.0.0.1: ESP(spi=0xc4eee342,seq=0x11556d), length 1044 
> > 20:23:48.400881 IP 20.0.0.1 > 20.0.0.2: ESP(spi=0xce9a1b01,seq=0x115576), length 1044 
> > 20:23:48.400919 IP 20.0.0.2 > 20.0.0.1: ESP(spi=0xc4eee342,seq=0x11556e), length 1044 
> > 20:23:48.400963 IP 20.0.0.1 > 20.0.0.2: ESP(spi=0xce9a1b01,seq=0x115577), length 1044 
> > 20:23:48.401003 IP 20.0.0.2 > 20.0.0.1: ESP(spi=0xc4eee342,seq=0x11556f), length 1044 
> > 20:23:48.401047 IP 20.0.0.1 > 20.0.0.2: ESP(spi=0xce9a1b01,seq=0x115578), length 1044 
> 
> 
> > Is there any fix to this issue. The scenario of simultaneous ike initiations happening for the first time when tunnel is being established is something which is not addressed I feel. 
> 
> 
> > Regards 
> > Suhas Krishna 
> 
> 
> 
> > _______________________________________________ 
> > Users mailing list 
> > Users at lists.strongswan.org 
> > https://lists.strongswan.org/mailman/listinfo/users 
> 
> 
> _______________________________________________ 
> Users mailing list 
> Users at lists.strongswan.org 
> https://lists.strongswan.org/mailman/listinfo/users 
-----BEGIN PGP SIGNATURE----- 
Version: GnuPG v2 
iQIcBAEBCAAGBQJU0mbXAAoJEDg5KY9j7GZY+eEP/0/sp8332hmIqdFDAQIzW2fh 
MD3emEBa7DXeaPNcXUEjA2wNnv0qIP7ctiBn2YB5+pvMGYMn8KTwbrxN9vQN4sD9 
35hijguCA4YVxEvu4+xkIuNbLWylcgAglCmAIpnt6HrXxDA4+OVKbBgcF05lqcnH 
sWdnuDhmfCNjXafU2/Zxw1mpDNM2tpgab0eOnTD0LFKnRklOtq8tGQxdZl+Wtkwo 
ng0bVTZx1qM9zVektfmIYzTOnC/ScfqaRBYR3LwHdIpUfxUR6v0yFxSO0ypCVR+M 
wUK3xCOzDPC3/NlqQ6qeoOkCLzlAmGj3KDOsFmsjIpAc5JYKrcOqoI6LSWb2WZds 
q+DVp1O4OPUjQKza8rZzOiY4uPA54jiqRumum0iq4NFGv40Hua84bYJ/EPf5MqOP 
fZw8bCZj+iPxZUQuUdXCm6+DUHWzATgQQ+QU1Ysw9hziNJc5Eo+6md2Kp2p/3pW2 
sZAOYtTtK7ShD9pG7DUd51nYA5aqhyuy3XHE1gxYKSXtgeX7i2qpzVMjqV0yFRzc 
YyKh8tnlVE1tX13POYF6Wd3plbqThyZx/Yc35aRY+gugMRJ/sr/qcu2U/oVwVhy5 
slK3uG5ZLAxbj8h4cmN45WP9To282wEaVmRvdNFf14R4GarJdIOBZRLd1ivg5gfn 
vm/LimVxeJNk64H1XuNL 
=BsFr 
-----END PGP SIGNATURE----- 
_______________________________________________ 
Users mailing list 
Users at lists.strongswan.org 
https://lists.strongswan.org/mailman/listinfo/users 
_______________________________________________ 
Users mailing list 
Users at lists.strongswan.org 
https://lists.strongswan.org/mailman/listinfo/users 

_______________________________________________
Users mailing list
Users at lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users


More information about the Users mailing list