-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU0ScVAAoJEDg5KY9j7GZYMUsP/11/IMcmEV7YYy3P/AkbAB7q ee6iSKqTmm62eukz2meIxlWeB9bl9Rkx13vAOOeVjbb7gCV1Yq6RsNp+i/Vv5s+V FGO9lnUmHa3yF6jPMyExQaC1dprEXCkCIXaIne3KC7olaVQjDuX04iiCbt9lzs5g jYEJvtHb2A89CLw6mIWvK7yK/eGkWQkjL8GsrzEq7YFltO3ZhWNXy5XXyE5r8V1Q EelXAUfrQcyC6vh7s9fU5iTY6zHDNhqSrDysR5WX3twRL6bF1sGU9PwFGYbr9H3N pTIgFCiv+nWpYpses8Zni4su6UNxlI0DQFJJR1U+sIJ0B5OBMW+HWcCjA8E87idP hlkVabuUjJeixjtLsG4QTPXoa33sCiTQRnXXUTdFDUUUpN7O0GqC7Svplq0zmNBQ AapX8a6E+DeMHmDtMSofHgi4LkWLuFu3rrDoQoudzcVxgVYtqiGMAnOYMssjBcuq Yem14Y1ZPz+1C454qSOo9gDcBdZAkO/Ifx6zPCirbFTWPw2PJ/w31YDp98u5Oemc OtrsvARCxXbYDcXoEfVv4efvR+ghM1C1PJaPHrEkkHb7KZ3UU9zuNR6/XWgwlnJF a2laRPVOBAEp4+kTmShRaglPG3s12npzlSpdTmUoZeWkpoj0z9PjElGbrl0zNLZf Lp37GLP7TQ5VAbL0evzV =Pqmg -----END PGP SIGNATURE----- _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
