[strongSwan] FW: Traffic dropped when IKE initiation happen between two nodes simultaneously.
Krishna G, Suhas (NSN - IN/Bangalore)
suhas.krishna_g at nsn.com
Fri Feb 13 08:14:16 CET 2015
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> [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<mailto: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<mailto: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> [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<mailto: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<mailto:Users at lists.strongswan.org>
> > https://lists.strongswan.org/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org<mailto: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<mailto:Users at lists.strongswan.org>
https://lists.strongswan.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users at lists.strongswan.org<mailto:Users at lists.strongswan.org>
https://lists.strongswan.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150213/08c068a8/attachment-0001.html>
More information about the Users
mailing list