[strongSwan] Multiple Child_SAs are causing traffic drop

[Joern Mewes]

Hi Martin,

Many thanks for your reply.

> As reqids are assigned incrementally, the SA with the higher reqid is
> newer (rekey times are randomized using rekeyfuzz). This means that
> strongSwan is using the newer SA {454}, while Checkpoint is still using
> the old one {338}.

This would be my understanding as well but unfortunately I cannot
confirm this. Just check the below example from yesterday evening.
>From the trace I see that the following SPIs are used between
strongswan 5.0.4 (192.168.57.122) and Checkpoint (192.168.30.165).

21:47:29.989835 IP 192.168.57.122 > 192.168.30.165:
ESP(spi=0x079d9476,seq=0x91), length 132
21:47:29.990733 IP 192.168.30.165 > 192.168.57.122:
ESP(spi=0xc51e2430,seq=0x48), length 132
21:47:31.731989 IP 192.168.57.122 > 192.168.30.165:
ESP(spi=0x079d9476,seq=0x92), length 116
21:47:31.732788 IP 192.168.30.165 > 192.168.57.122:
ESP(spi=0xc51e2430,seq=0x49), length 340
21:47:32.999557 IP 192.168.57.122 > 192.168.30.165:
ESP(spi=0x079d9476,seq=0x93), length 132
21:47:33.000405 IP 192.168.30.165 > 192.168.57.122:
ESP(spi=0xc51e2430,seq=0x4a), length 132

"ipsec status" shows that theses SPIs are belonging to different Child_SAs.

root at vpn-57:~/test# ipsec status vpn-57-122
Routed Connections:
  vpn-57-122{122}:  ROUTED, TUNNEL
  vpn-57-122{122}:   10.57.11.122/32 === 10.22.11.122/32

Security Associations (150 up, 0 connecting):

  vpn-57-122[405]: ESTABLISHED 16 minutes ago, 192.168.57.122[O=COMP,
  CN=vpn-57]...192.168.30.165[192.168.30.165]
  vpn-57-122{458}:  INSTALLED, TUNNEL, ESP SPIs: c9baad47_i 079d9476_o
  vpn-57-122{458}:   10.57.11.122/32 === 10.22.11.122/32
  vpn-57-122{404}:  INSTALLED, TUNNEL, ESP SPIs: c51e2430_i 796bc8a6_o
  vpn-57-122{404}:   10.57.11.122/32 === 10.22.11.122/32

>From the Charon log (vpn-57-122.log) I see that the SPI the Checkpoint
is using (line 598) has been established later that the one used by
strongswan (line 523), so I would assume that strongswan uses the
older SPI. Can you confirm this and do you have an idea what went
wrong? Could it be related to the number of parallel VPNs (150) we are
running towards the same peer (we are using strongswan as vpn tester
to simulate a lot of parallel site-to-site vpns).

> The problem is that you can't have two equal IPsec policies in Linux,
> even if the reqids differs. This means that strongSwan can install the
> policy for the newest CHILD_SA only. While the old IPsec SAs are still
> in place, they won't have a reqid that we have a valid policy for. Hence
> a packet on the old SA won't get through.

Understood.

> With 5.1.0 we now reject the installation of a policy if we already have
> one installed with the same selectors, but different reqids. This will
> make CHILD_SA negotiation fail, and you should only ever have one
> CHILD_SA for the same selectors (but different reqids).

This is something we will definitely try in the upcoming days.

Again, thanks for your help and have a nice day.

Best regards,
Joern
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vpn-57.122.log
Type: application/octet-stream
Size: 72858 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20131001/50cd1c4b/attachment.obj>