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

Nick Howitt n1ck.h0w1tt at gmail.com
Thu Jul 30 14:49:23 EDT 2009


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
>    


More information about the Users mailing list