<html>
<head>
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 22/09/2013 09:01, Nick Howitt wrote:<br>
</div>
<blockquote
cite="mid:alpine.LFD.2.10.1309212132100.23494@bofh.nohats.ca"
type="cite">
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
<br>
<div class="moz-cite-prefix">On 22/09/2013 02:39, Paul Wouters
wrote:<br>
</div>
<blockquote
cite="mid:alpine.LFD.2.10.1309212132100.23494@bofh.nohats.ca"
type="cite"> <br>
On Sat, 21 Sep 2013, Nick Howitt wrote: <br>
<br>
<blockquote type="cite">This is the working conn: <br>
</blockquote>
<br>
<blockquote type="cite">conn PaulIn <br>
left=82.19.147.85 <br>
right=%any <br>
</blockquote>
<br>
<blockquote type="cite">and this one does not: <br>
<br>
conn PaulIn <br>
left=%defaultroute <br>
right=%any <br>
</blockquote>
<br>
In theory, we never "supposed" havng both endpoints dynamic,
though it <br>
apparently did work.... <br>
</blockquote>
It always worked with Openswan<br>
<blockquote
cite="mid:alpine.LFD.2.10.1309212132100.23494@bofh.nohats.ca"
type="cite"> <br>
<blockquote type="cite">000 "MumIn":
172.17.2.0/24===82.19.147.85[@Nick]---82.19.147.1...82.30.103.217<82.30.103.217>===192.168.10.0/24;
erouted; eroute owner: <br>
#4 <br>
000 "MumIn": oriented; my_ip=172.17.2.1; their_ip=unset; <br>
</blockquote>
<br>
<blockquote type="cite">000 "PaulIn":
172.17.2.0/24===82.19.147.85<82.19.147.85>[@Nick]...%any===192.168.30.0/24;
unrouted; eroute owner: #0 <br>
000 "PaulIn": oriented; my_ip=172.17.2.1; their_ip=unset;
<br>
</blockquote>
<br>
It seems MunIn and PaulIn are very similar connections and I
think that <br>
might have caused confusion. You could try using aggressive mode
<br>
(aggrmode=yes) and adding different leftid/rightid to those two
conns. <br>
</blockquote>
</blockquote>
Logically most conns will probably be similar, only differing by
right and rightsubnet so it should not really be an issue.<br>
<blockquote
cite="mid:alpine.LFD.2.10.1309212132100.23494@bofh.nohats.ca"
type="cite">
<blockquote
cite="mid:alpine.LFD.2.10.1309212132100.23494@bofh.nohats.ca"
type="cite"> </blockquote>
I can work round the issues although I've never tried aggressive
mode. I'd just like to Libreswan working as Openswan did. In
Libreswan I believe the interface and detection routine was
"improved", but it seems to be causing issues.<br>
<blockquote type="cite">and FWIW, "service ipsec status" always
gives: <br>
<br>
[root@server ~]# service ipsec status <br>
ipsec: pluto is stopped <br>
<br>
I thought we'd seen this one before and fixed it. <br>
</blockquote>
<br>
Hmmm. I'll check it out. <br>
</blockquote>
<blockquote cite="mid:523EA3C7.8010209@gmail.com" type="cite"> I've
checked the mailing lists. This was why 3.5-2 was released. Your
comment was:<br>
<blockquote><tt>The quick fix is to add the following line after
the "make install" in the spec file:</tt><br>
<br>
<tt>install -m 0755 initsystems/sysvinit/init.rhel.in
%{buildroot}%{_initrddir}/ipsec</tt><br>
<br>
<tt>Or grab the src or binary rpm for libreswan-3.5-2 from
downloads.libreswan.org.</tt><br>
</blockquote>
The line "make install" no longer exists in the spec file.<br>
<blockquote
cite="mid:alpine.LFD.2.10.1309212132100.23494@bofh.nohats.ca"
type="cite"> <br>
Paul <br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>