[Openswan Users] Start new connection

[Andy]

On Tue, 2005-11-01 at 23:48 +0100, Paul Wouters wrote:
> On Tue, 1 Nov 2005, Frederico Madeira wrote:
> 
> > [root at fw rc.d]# /usr/sbin/ipsec auto --up ksa-fred
> >
> > 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?

This is the console output from the ipsec auto command, right? There
should be more information in the system logs that'll help us understand
what's happening. Usually /var/log/secure or /var/log/auth.log. Try to
get the logs from the other end as well.