<div dir="ltr">For instance, in the below, once the SA is established a single packet is sent from west->east, but it is lost vis:<br><br><div style="margin-left:40px">004 "authenticate-ikev1-md5" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {AH=>0xAHAH <0xAHAH xfrm=HMAC_MD5_96 NATOA=none NATD=none DPD=passive}<br>+<br>004 "authenticate-ikev1-md5" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {AH=>0xd405e4fd <0x7d11a0b5 xfrm=HMAC_MD5_96 NATOA=none NATD=none DPD=passive}<br>+<br>==== cut ====<br>ping -q -n -c 1 -i 6 -w 5 -I 192.0.1.254 192.0.2.254<br>==== tuc ====<br>[   38.119182] IN=eth1 OUT= MAC=12:00:00:64:64:45:12:00:00:64:64:23:08:00 SRC=192.0.2.254 DST=192.0.1.254 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=51594 PROTO=ICMP TYPE=0 CODE=0 ID=1481 SEQ=1 <br>==== cut ====<br>PING 192.0.2.254 (192.0.2.254) from 192.0.1.254 : 56(84) bytes of data.<br><br>--- 192.0.2.254 ping statistics ---<br>1 packets transmitted, 0 received, 100% packet loss, time 0ms<br>==== tuc ====<br>down UNEXPECTED<br></div><br>however if I tweak the test to first sleep for a second vis:<br><br><div style="margin-left:40px">...<br>004 "authenticate-ikev1-md5" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {AH=>0xf3e4d1b2 <0xcd040343 xfrm=HMAC_MD5_96 NATOA=none NATD=none DPD=passive}<br>+<br>sleep 1<br>==== cut ====<br>ping -q -n -c 1 -i 6 -w 5 -I 192.0.1.254 192.0.2.254<br>==== tuc ====<br>==== cut ====<br>PING 192.0.2.254 (192.0.2.254) from 192.0.1.254 : 56(84) bytes of data.<br><br>--- 192.0.2.254 ping statistics ---<br>1 packets transmitted, 1 received, 0% packet loss, time 0ms<br>rtt min/avg/max/mdev = 0.537/0.537/0.537/0.000 ms<br>==== tuc ====<br>up<br></div><div><br></div><div>that first packet gets through.</div><div><br></div><div>I find this worrying - from my POV this should be 100% deterministic - the initiator wack only exits when it's both received the SA response (confirming that the other end's kernel is ready) and it too has configured its kernel.<br></div><div>If things are set up as KLIPS(IKE initiator)->NETKEY(IKE responder) then the problem doesn't seem to occure - suggesting the the responder (east) returned early - even more worrying.</div><div>(I've also looked at old variants of this test - where 4 packets were sent - and they two can loose the packet)<br></div><div><br></div><div>anyone?</div><div><br></div><div>Andrew</div><div><br></div></div>