[Openswan Users] Start new connection

Paul Wouters paul at xelerance.com
Wed Nov 2 05:20:03 CET 2005


On Tue, 1 Nov 2005, Andy wrote:

> > > 104 "ksa-fred" #1: STATE_MAIN_I1: initiate
> > > 003 "ksa-fred" #1: received Vendor ID payload [Openswan (this version)
> > > 2.4.0rc3  X.509-1.5.4 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR]
> > > 003 "ksa-fred" #1: received Vendor ID payload [Dead Peer Detection]
> > > 106 "ksa-fred" #1: STATE_MAIN_I2: sent MI2, expecting MR2
> > > 108 "ksa-fred" #1: STATE_MAIN_I3: sent MI3, expecting MR3
> > > 004 "ksa-fred" #1: STATE_MAIN_I4: ISAKMP SA established
> > > {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5
> > > group=modp1536}
> > > 117 "ksa-fred" #2: STATE_QUICK_I1: initiate
> > > 010 "ksa-fred" #2: STATE_QUICK_I1: retransmission; will wait 20s for
> > > response
> > > 010 "ksa-fred" #2: STATE_QUICK_I1: retransmission; will wait 40s for
> > > response
> > > 031 "ksa-fred" #2: max number of retransmissions (2) reached
> >
> > The other end is not sending a single packet back. There might be a
> > filter for udp port 500/4500 in place somewhere.
> >
> Surely that's not right. Phase 1 is completed OK, so isakmp must be
> getting through?

Oops. You are absolutely right. It was phase 2 that never saw a packet, not
phase 1. In this case, the other end does not like the phase 2 proposal
packet that was sent, and silently disgarded the packet. Logs on that end
should tell you why it disgarded it.

Paul
-- 

"Happiness is never grand"

	--- Mustapha Mond, World Controller (Brave New World)


More information about the Users mailing list