[strongSwan] FW: Traffic dropped when IKE initiation happen between two nodes simultaneously.
Noel Kuntze
noel at familie-kuntze.de
Tue Feb 3 20:52:55 CET 2015
-----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 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
-----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-----
More information about the Users
mailing list