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

[Paul Wouters]

On Mon, 29 Jun 2009, Nick Howitt wrote:

> Date: Mon, 29 Jun 2009 19:11:34 +0100
> From: Nick Howitt <n1ck.h0w1tt at gmail.com>
> Cc: users at openswan.org
> To: Paul Wouters <paul at xelerance.com>
> Subject: Re: [Openswan Users] Upgrade 2.4.14 -> 2.6.21 Problem with secrets
> 
> Hi Paul,
>
> Have you been able to get anywhere with this?

I have not had time to look at this issue.

Paul

> Thanks,
>
> 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
>