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

[Nick Howitt]

On 28/07/2009 16:17, Paul Wouters wrote:
> 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
>
No, it is on the gateway.

BTW, this problem disappeared a little while back on its own accord. I 
now have the problem in another post with %any and %defaultroute being 
accepted in conns after upgrading to ClarkConnect CE5.0.
>> 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
>>
>>