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

[Nick Howitt]

I have just upgraded from 2.4.14 to 2.6.21 and I've hit an issue with 
ipsec.secrets.

I had 2 tunnels:
config setup
     interfaces=%defaultroute
     plutodebug=none
     klipsdebug=none
     protostack=netkey    # 2.6.x only

conn %default
     type=tunnel
     authby=secret
     keyingtries=%forever
     left=%defaultroute
     leftsubnet=192.168.2.0/24
     leftsourceip=192.168.2.1
     leftnexthop=%defaultroute
     keylife=28800s     # (2.6.x only)                # salifetime and 
lifetime do not work as aliases
     ikelifetime=28800s    # (2.6.x only)
     rightnexthop=%defaultroute        # Made no difference

conn Mark
     auto=add
     right=%any
     rightsubnet=192.168.20.0/24
     rightsourceip=192.168.20.1
     rightid=@FromMark    # This must also be in the Local ID field in 
the DrayTek

conn MumOut
     auto=start
     right=MumOut.FQDN
     rightsubnet=192.168.10.0/24
     rightsourceip=192.168.10.1
     ike=3des-md5
     esp=3des-sha1

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.
It looks like only the first secret is used. For both connections I 
always get the message:

multiple ipsec.secrets entries with distinct secrets match endpoints: 
first secret used

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:

next payload type of ISAKMP Identification Payload has an unknown value: 224
probable authentication failure (mismatch of preshared secrets?): 
malformed payload in packet

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.

Is there something I am missing. All connections are dynamic, but none 
changed during the testing.

Regards,

Nick