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

[Nick Howitt]

Hi Paul,

Any progress? You did ask me to bug you ........

Thanks,

Nick

On 29/06/2009 19:41, Paul Wouters wrote:
> 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
>>