[Openswan Users] [Fwd: Re: Upgrade 2.4.14 -> 2.6.21 Problem with secrets]

[Paul Wouters]

On Thu, 25 Jun 2009, Nick Howitt wrote:

> Date: Thu, 25 Jun 2009 20:28:02 +0100
> From: Nick Howitt <n1ck.h0w1tt at gmail.com>
> Cc: users at openswan.org
> To: Paul Wouters <paul at xelerance.com>
> Subject: [Fwd: Re: [Openswan Users] Upgrade 2.4.14 -> 2.6.21 Problem with
>     secrets]

> I've tried to go back over earlier 2.6.x versions from the download site. 2.6.14 and 2.6.16 won't compile so I can't
> test. 2.6.18 will compile (release notes indicate a bug fix for Centos on which ClarkConnect is based) and It runs.
> It shows the same problems with multiple passwords as 2.6.21 and 2.6.22.
> 
> BTW, the ipsec.secrets file I listed below should have the %any removed. I do not normally have it in the file as it
> does not work for 2.4.x. I put it in to try to get 2.6.21 to work correctly but it made no difference.

Is your openswan server behind NAT?

Paul

> p.s. I am now at 2.4.15 which is fine.
> 
> -------- Original Message --------
> Subject: Re: [Openswan Users] Upgrade 2.4.14 -> 2.6.21 Problem with secrets
> Date: Tue, 23 Jun 2009 18:34:44 +0100
> From: Nick Howitt <n1ck.h0w1tt at gmail.com>
> To: Paul Wouters <paul at xelerance.com>
> CC: users at openswan.org
>
>  Paul,
> 
> I've tested again changing USE_DYNAMICDNS?= back to false and it made no 
> difference. It still uses the first secret.
> 
> I've had to downgrade back to 2.4.14 (soon to be .15!) in order to keep 
> the two tunnels up.
> 
> Regards,
> 
> Nick
> 
> On 22/06/2009 21:27, Paul Wouters wrote:
> > On Mon, 22 Jun 2009, Nick Howitt wrote:
> >
> >> I have just upgraded from 2.4.14 to 2.6.21 and I've hit an issue with
> >> ipsec.secrets.
> >
> > There should not be any differences there...
> >
> >>     leftnexthop=%defaultroute
> >>     keylife=28800s     # (2.6.x only)                # salifetime and
> >> lifetime do not work as aliases
> >>     ikelifetime=28800s    # (2.6.x only)
> >
> > I am confused how that does not work, from keywords.c:
> >
> >     {"keylife",        kv_conn|kv_auto|kv_alias, kt_time, 
> > KBF_SALIFETIME,NOT_ENUM},
> >     {"lifetime",       kv_conn|kv_auto|kv_alias, kt_time, 
> > KBF_SALIFETIME,NOT_ENUM},
> >     {"salifetime",     kv_conn|kv_auto, kt_time, 
> > KBF_SALIFETIME,NOT_ENUM},
> >     {"ikelifetime",    kv_conn|kv_auto, kt_time, 
> > KBF_IKELIFETIME,NOT_ENUM},
> >
> > Can you explain what "does not work" about those keywords?
> >
> >> and ipsec.secrets
> >> %any : PSK "DialInSecret"
> >> my.FQDN MumOut.FQDN : PSK "MumOutRouter'sSecret"
> >>
> >> This worked absolutely fine in 2.4.14. I have compiled 2.6.21 with
> >> USE_DYNAMICDNS?=true and it no longer works.
> >
> > You can try and reverse the two entries, making the most specific one
> > match first. David has a patch that should allow better picking with %any
> > in the secrets, and I'll see about applying that shortly.
> >
> >> The documentation says the best match is used so for conn MumOut it
> >> should pick up the second secret. In this scenario I cannot connect to
> >> MumOut. If I switch the lines round in ipsec.secrets, I get the same
> >> message and conn Mark is never able to establish with the following 
> >> message:
> >
> > Hmm, so much for that idea then...
> >
> >> I do not even see how conn Mark should be matching "my.FQDN MumOut.FQDN
> >> : PSK "MumOutRouter'sSecret" as MumOut.FQDN resolves to a completely
> >> different IP address to the one which is initiating the connection.
> >
> > Note that secrets are read on startup.
> >
> > bug me in a few days if you have not seen me picking this up.
> >
> > Paul
> 
>