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

[Nick Howitt]

I've done a bit more troubleshooting.

With my dial-in conn, if right=%any, I am having to set left="IP 
address". If I set left=myFQDN or left=%defaultroute I get

022 connection must specify host IP address for our side
037 attempt to load incomplete connection

With my dial-out conn, if left=%defaultroute then, if right=farFQDN or 
right=FarIPAddress, I get

022 "MumOut": We cannot identify ourselves with either end of this 
connection.

Nick

On 30/07/2009 19:49, Nick Howitt wrote:
> Any more thoughts or things I can look at?
>
> On 28/07/2009 10:50, Nick Howitt wrote:
>    
>> 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
>>>
>>>        
>> _______________________________________________
>> Users at openswan.org
>> http://lists.openswan.org/mailman/listinfo/users
>> Building and Integrating Virtual Private Networks with Openswan:
>> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>>
>>      
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>