[Openswan Users] "STATE_MAIN_I3 (sent MI3, expecting MR3)" forever

[Irek Slonina]

Hello,
I have a strange problem with one of my vpn client.

000 "szmetor-superchruper": 213.213.213.213[C=PL, ST=podkarpackie, O=Mex
s.j., OU=Salony, CN=superchruper.mex.com.pl,
E=superchruper at mex.com.pl,S=C]...80.80.80.80[C=PL, ST=podkarpackie,
O=Mex s.j., OU=Pion Techniczny, CN=szmetor.mex.com.pl,
E=szmetor at mex.com.pl,S=C]; unrouted; eroute owner: #0
000 "szmetor-superchruper":   CAs: 'C=PL, L=Rzeszow, O=Mex s.j.,
ST=podkarpackie, OU=Pion Techniczny, CN=szmetor.mex.com.pl,
E=szmetor at mex.com.pl'...'%any'
000 "szmetor-superchruper":   ike_life: 3600s; ipsec_life: 28800s;
rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "szmetor-superchruper":   policy: RSASIG+ENCRYPT+TUNNEL+PFS+UP;
prio: 32,32; interface: ppp0;
000 "szmetor-superchruper":   newest ISAKMP SA: #0; newest IPsec SA: #0;
000
000 #2: "szmetor-superchruper" STATE_MAIN_I3 (sent MI3, expecting MR3);
EVENT_RETRANSMIT in 31s
000 #2: pending Phase 2 for "szmetor-superchruper" replacing #0
000

That host is in Phase 2 for eternity. I have set up ca. 20 other
identical vpn clients with the same ipsec.conf, same method of generating
certificate, same firewall rules, same kernel 2.6.7, same openswan (2.1.4),
same everything. I have tried with ipsec-tools 0.2.5 and 0.3.3.

I just see one odd thing in barf:

Sep 22 11:59:03 czeche pluto[17969]: |  I am sending a certificate
request
Sep 22 11:59:03 czeche pluto[17969]: | looking for secret for C=PL,
ST=podkarpackie, O=Mex s.j., OU=Salony, CN=superchruper.szmetor.cc,
E=superchruper at szmetor.cc->C=PL, ST=podkarpackie, O=Mex s.j., OU=Pion
Techniczny, CN=szmetor.szmetor.cc, E=szmetor at szmetor.cc of kind PPK_RSA
Sep 22 11:59:03 czeche pluto[17969]: | searching for certificate
PPK_RSA:AwEAAa8Fi vs PPK_RSA:AwEAAa8Fi
Sep 22 11:59:03 czeche pluto[17969]: | signing hash with RSA Key
*AwEAAa8Fi
Sep 22 11:59:03 czeche pluto[17969]: "szmetor-superchruper" #2:
transition from
state STATE_MAIN_I2 to state STATE_MAIN_I3
Sep 22 11:59:03 czeche pluto[17969]: | inserting event EVENT_RETRANSMIT,
timeout in 10 seconds for #2
Sep 22 11:59:03 czeche pluto[17969]: | next event EVENT_RETRANSMIT in 10
seconds for #2
Sep 22 11:59:13 czeche pluto[17969]: |
Sep 22 11:59:13 czeche pluto[17969]: | *received 244 bytes from
80.80.80.80:500
on ppp0
Sep 22 11:59:13 czeche pluto[17969]: | ICOOKIE:  45 98 12 60  7f ff 4c
b3
Sep 22 11:59:13 czeche pluto[17969]: | RCOOKIE:  b4 98 bd 6c  90 3a 6f
2f
Sep 22 11:59:13 czeche pluto[17969]: | peer:  50 37 e8 eb
Sep 22 11:59:13 czeche pluto[17969]: | state hash entry 23
Sep 22 11:59:13 czeche pluto[17969]: | peer and cookies match on #2,
provided msgid 00000000 vs 00000000
Sep 22 11:59:13 czeche pluto[17969]: | state object #2 found, in
STATE_MAIN_I3
Sep 22 11:59:13 czeche pluto[17969]: "szmetor-superchruper" #2:
discarding duplicate packet; already STATE_MAIN_I3
Sep 22 11:59:13 czeche pluto[17969]: | next event EVENT_RETRANSMIT in 0
seconds
for #2

Does the ICOOKIE and RCOOKIE should be the same? If yes then how to fix
that? If no then where to find the solution? I would be very thankful
for every constructive response.

Whole barf is here:
http://zetor.mex.com.pl/barf

Regards,
Irek Slonina