-----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: [email protected] > [mailto:[email protected]] On Behalf Of ext Noel Kuntze > Sent: Wednesday, February 04, 2015 1:23 AM > To: [email protected] > 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@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@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 > > [email protected] > > https://lists.strongswan.org/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > [email protected] > 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 [email protected] https://lists.strongswan.org/mailman/listinfo/users
