<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
On 26/07/2009 21:01, Paul Wouters wrote:
<blockquote
cite="mid:alpine.LFD.1.10.0907261557001.15775@newtla.xelerance.com"
type="cite">On Sun, 26 Jul 2009, Nick Howitt wrote:
<br>
<br>
<blockquote type="cite">I have now moved it to each conn and it works
the same irrespective of where it is.
<br>
With left=%defaultroute in my default conn and right=%any
in conn Mark
<br>
(in ipsec.conf) in /var/log/secure I get:
<br>
<br>
<br>
You cannot use both in the same conn, as pluto would not be able
to deduct
<br>
if it should be left= or right=, as both are dynamic.
<br>
<br>
It used to work with CC4.3 and openswan 2.4.15 and 2.6.15.
<br>
</blockquote>
<br>
Are you sure about that? It has never been a supported method.
<br>
<br>
</blockquote>
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)<br>
<blockquote
cite="mid:alpine.LFD.1.10.0907261557001.15775@newtla.xelerance.com"
type="cite">
<blockquote type="cite">I have now put left in the conn and with
left=myFQDN, right=%any, in /var/log/messages I still get:
<br>
<br>
Jul 26 19:12:07 server ipsec__plutorun: 022 connection must specify
host IP address for our side
<br>
Jul 26 19:12:07 server ipsec__plutorun: 037 attempt to load incomplete
connection
<br>
</blockquote>
<br>
Do you have a reachable DNS server before the tunnel is up that can
resolve myFQDN?
<br>
</blockquote>
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.<br>
<blockquote
cite="mid:alpine.LFD.1.10.0907261557001.15775@newtla.xelerance.com"
type="cite"><br>
<blockquote type="cite">and, similarly, in /var/log/secure:
<br>
<br>
Jul 26 19:12:07 server pluto[19800]: connection must specify host IP
address for our side
<br>
Jul 26 19:12:07 server pluto[19800]: attempt to load incomplete
connection
<br>
<br>
The error messages clear and the tunnel comes up only if I define
right=farFQDN. right=%any does not
<br>
work.
<br>
</blockquote>
<br>
right=%any should work find if you use auto=add and let the connection
be a responder. But
<br>
I think you want both ends to try to initiate to the other. That on
dynamic IP will always
<br>
be a challenge, and you will need to use DNS servers to resolve the
dyndns hostnames.
<br>
</blockquote>
This is the conn:<br>
<br>
<small><font face="Courier New">conn %default<br>
type=tunnel<br>
authby=secret<br>
keyingtries=%forever<br>
leftsubnet=192.168.2.0/24<br>
leftsourceip=192.168.2.1<br>
leftnexthop=%defaultroute<br>
rightnexthop=%defaultroute<br>
<br>
conn Mark<br>
auto=add # Stops outbound keying. Still works OK.<br>
rekey=no<br>
left=myFQDN<br>
# right=%any<br>
right=farFQDN<br>
rightsubnet=192.168.20.0/24<br>
rightsourceip=192.168.20.1<br>
rightid=@FromMark # This must also be in the Local ID field in
the DrayTek<br>
</font></small><br>
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.<br>
<blockquote
cite="mid:alpine.LFD.1.10.0907261557001.15775@newtla.xelerance.com"
type="cite"><br>
Paul
<br>
</blockquote>
</body>
</html>