Hi Martin, Christophe, I have also similar kind of problem posted long time back. But, i didn't get any update on my query.
Looks, Both are discussing the similar problem. Please provide your comments. Strongswan Version: Linux strongSwan U4.5.0/K2.6.32.58 I am facing the issue in allocating the req id for IPSec tunnel and Policy. If we have both the side become a initiator then two SA (in & out) tunnels created for Single SP. "reqid" is mismatching between SA and SP. Node A <------------> Node B Tunnel established between Node A and Node B. I am sending the Ping from Node A to Node B and its failing. Sender Side: (PING Request) ========================= root@10:~ >ping -I 2.2.2.2 12.12.12.12 PING 12.12.12.12 (12.12.12.12) from 2.2.2.2 : 56(84) bytes of data. 01:21:03.207543 IP 10.10.10.10 > 10.10.10.11: ESP(spi=0xc869e935,seq=0x1f), length 96 01:21:04.208366 IP 10.10.10.10 > 10.10.10.11: ESP(spi=0xc869e935,seq=0x20), length 96 Security Association Table: ======================== root@10:~ >ip x s src 10.10.10.10 dst 10.10.10.11 proto esp spi 0xc869e935 reqid 1 mode tunnel replay-window 0 flag 20 auth hmac(sha1) 0x000e5af11f3ff6385af7c1452e1e472b5e997f16 enc cbc(aes) 0x6eca8ddfa393bb18207de3e75e60bd1d src 10.10.10.11 dst 10.10.10.10 proto esp spi 0xc699d2d5 reqid 1 mode tunnel replay-window 0 flag 20 auth hmac(sha1) 0xc8b39b92ac18c211f5eb32cd6d7d9e10095b0413 enc cbc(aes) 0x4997e1f2a391bfdaf1e251fcd18eafd7 src 10.10.10.10 dst 10.10.10.11 proto esp spi 0xc6c50120 reqid 2 mode tunnel replay-window 0 flag 20 auth hmac(sha1) 0xf132e706c40deeda21e9147f2dee624423468fa0 enc cbc(aes) 0xafdf0fa8e923e35112ace1975044cc75 src 10.10.10.11 dst 10.10.10.10 proto esp spi 0xc599369c reqid 2 mode tunnel replay-window 0 flag 20 auth hmac(sha1) 0xbf6a1a52216d4daebb5bb18f9b84e119a7248c9e enc cbc(aes) 0xed45eb6c03ae379b0c51c6739fb74bf9 root@10:~ > Receiver Side: ============= root@10:~ >01:23:28.005013 IP 10.10.10.10 > 10.10.10.11: ESP(spi=0xc869e935,seq=0x22), length 94 01:23:28.005090 IP 2.2.2.2 > 12.12.12.12: ICMP echo request, id 10901, seq 1, length 64 Security Association: ================= root@10:~ >ip x s src 10.10.10.11 dst 10.10.10.10 proto esp spi 0xc599369c reqid 1 mode tunnel replay-window 0 flag 20 auth hmac(sha1) 0xbf6a1a52216d4daebb5bb18f9b84e119a7248c9e enc cbc(aes) 0xed45eb6c03ae379b0c51c6739fb74bf9 src 10.10.10.10 dst 10.10.10.11 proto esp spi 0xc6c50120 reqid 1 mode tunnel replay-window 0 flag 20 auth hmac(sha1) 0xf132e706c40deeda21e9147f2dee624423468fa0 enc cbc(aes) 0xafdf0fa8e923e35112ace1975044cc75 src 10.10.10.11 dst 10.10.10.10 proto esp spi 0xc699d2d5 reqid 2 mode tunnel replay-window 0 flag 20 auth hmac(sha1) 0xc8b39b92ac18c211f5eb32cd6d7d9e10095b0413 enc cbc(aes) 0x4997e1f2a391bfdaf1e251fcd18eafd7 src 10.10.10.10 dst 10.10.10.11 proto esp spi 0xc869e935 reqid 2 mode tunnel replay-window 0 flag 20 auth hmac(sha1) 0x000e5af11f3ff6385af7c1452e1e472b5e997f16 enc cbc(aes) 0x6eca8ddfa393bb18207de3e75e60bd1d Security Policy: ============= root@10:~ >ip x p src 2.2.2.2/32 dst 12.12.12.12/32 dir fwd priority 1 tmpl src 10.10.10.10 dst 10.10.10.11 proto esp reqid 1 mode tunnel src 2.2.2.2/32 dst 12.12.12.12/32 dir in priority 1 tmpl src 10.10.10.10 dst 10.10.10.11 proto esp reqid 1 mode tunnel src 12.12.12.12/32 dst 2.2.2.2/32 dir out priority 1 tmpl src 10.10.10.11 dst 10.10.10.10 proto esp reqid 1 mode tunnel root@10:~ >cat /proc/net/xfrm_stat XfrmInError 0 XfrmInBufferError 0 XfrmInHdrError 0 XfrmInNoStates 10 XfrmInStateProtoError 0 XfrmInStateModeError 0 XfrmInStateSeqError 0 XfrmInStateExpired 0 XfrmInStateMismatch 0 XfrmInStateInvalid 0 XfrmInTmplMismatch 121 XfrmInNoPols 0 XfrmInPolBlock 0 Thanks. Jegathesh > Sent: Thursday, May 23, 2013 1:17 PM > To: Christophe Gouault > Cc: dev@lists.strongswan.org > Subject: Re: [strongSwan-dev] rationale of reqid update on responder side > > > > Does this mean we decide to give up older SAs as soon as we establish a > new > > CHILD_SA as responder? This may not be what the remote peer wants > (otherwise > > it would have *rekeyed* the SA instead). > > No. It means that two different CHILD_SAs triggered from the same trap > policy use the same reqid. > > Assuming a trap policy to 10.0.0.0/16, and traffic to 10.0.1.1 triggers > an SA. The responder, however, narrows the traffic selector to > 10.0.1.0/24. Now you have traffic to 10.0.2.1, which triggers another > CHILD_SA, which might get narrowed by the responder to 10.0.2.0/24. > > So you'll have two CHILD_SA with the same reqid (that of the trap > policy). This is problematic for the kernel, which uses the reqid to map > policies to SAs. > > > According to what I observed, the trap CHILD_SA is left unchanged, but > > the policy in the kernel is updated with the new CHILD_SA reqid (I agree > > that itis necessary if we want the SA to be used). > > > > However, the trap CHILD_SA becomes unusable because it mismatches the > > policy reqid. > > Yes. Because we can't have two identical policies in XFRM, we use > refcounting to install it only once. This doesn't work for different > reqids, as only one reqid can be active for these refcounted policies. > > This is why we reuse the reqid of a trap policy when installing an SA > triggered by it. And this is what we should do when we install an SA as > responder for which we have a trap installed. > > Regards > Martin > > > _______________________________________________ > Dev mailing list > Dev@lists.strongswan.org > https://lists.strongswan.org/mailman/listinfo/dev >
_______________________________________________ Dev mailing list Dev@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/dev
