[Openswan Users] Upgrading ClarkConnect from v4.3 to 5.0 gives errors in OPenswan

[Nick Howitt]

This is a repost. The lists scrubbed the last one as it interpreted 
formatting as an html attachment.

On 26/07/2009 21:01, Paul Wouters wrote:
> On Sun, 26 Jul 2009, Nick Howitt wrote:
>
>> I have now moved it to each conn and it works the same irrespective 
>> of where it is.
>>             With left=%defaultroute in my default conn and right=%any 
>> in conn Mark
>>             (in ipsec.conf) in /var/log/secure I get:
>>
>>
>>       You cannot use both in the same conn, as pluto would not be 
>> able to deduct
>>       if it should be left= or right=, as both are dynamic.
>>
>> It used to work with CC4.3 and openswan 2.4.15 and 2.6.15.
>
> Are you sure about that? It has never been a supported method.
>
100% positive. After the CC upgrade I reused the same conf files. I 
started with the original files but I had to set oe=no instead of an 
include statement. Also the upgrade moved my conf files (from /etc to 
/etc/ipsec.d) so I copied them back rather than change my include 
statement. I then hit this issue which I can only solve using FQDN's (or 
IP's, presumably)
>> I have now put left in the conn and with left=myFQDN, right=%any, in 
>> /var/log/messages I still get:
>>
>> Jul 26 19:12:07 server ipsec__plutorun: 022 connection must specify 
>> host IP address for our side
>> Jul 26 19:12:07 server ipsec__plutorun: 037 attempt to load 
>> incomplete connection
>
> Do you have a reachable DNS server before the tunnel is up that can 
> resolve myFQDN?
>
Yes. The server has been running continuously since yesterday. I got the 
latest logs doing a "service ipsec restart" today. I think the error 
message is misleading as it clears when I set right=farFQDN. The tunnel 
is then OK.
>> and, similarly, in /var/log/secure:
>>
>> Jul 26 19:12:07 server pluto[19800]: connection must specify host IP 
>> address for our side
>> Jul 26 19:12:07 server pluto[19800]: attempt to load incomplete 
>> connection
>>
>> The error messages clear and the tunnel comes up only if I define 
>> right=farFQDN. right=%any does not
>> work.
>
> right=%any should work find if you use auto=add and let the connection 
> be a responder. But
> I think you want both ends to try to initiate to the other. That on 
> dynamic IP will always
> be a challenge, and you will need to use DNS servers to resolve the 
> dyndns hostnames.
>
This is the conn:

conn %default
     type=tunnel
     authby=secret
     keyingtries=%forever
     leftsubnet=192.168.2.0/24
     leftsourceip=192.168.2.1
     leftnexthop=%defaultroute
     rightnexthop=%defaultroute

conn Mark
     auto=add
     rekey=no
     left=myFQDN    # works in default conn as well and used to work as 
%defaultroute in default conn
     # right=%any    # no longer works
     right=farFQDN
     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

To be honest, I would suspect something during the CC4.3 -> 5.0 upgrade 
has messed up as everything was OK before and the errors are not 
normally expected, but I am hoping we can pinpoint the source of the 
error here. I have tried uninstalling Openswan then re-installing the CC 
version (2.6.14) , but it shows the same errors. Upgrading to 2.6.22 
again did nothing.
> Paul