<!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">
Ok...coincidentally, we had an outage today so I had a chance to
examine bind.<br>
<br>
It seems bind is farting on a sendmsg() call to the far side of the
tunnel. I did confirm that if I don't re-start IPSec (service ipsec
restart), then bind will continue to have problems regardless of what
other setting I mess with. If I do restart ipsec, then bind will
operate quite happily in the absence of the other side.<br>
<br>
I'll do more detailed tests on the weekend and document exhaustively as
much as I can regarding the state of bind and ipsec (ipsec barf, is
it?).<br>
<br>
Hopefully by then we'll have enough data to paint a clear picture of
why bind is being such a whiny little beeznatch.<br>
<br>
Cheers.<br>
<br>
Diego Rivera wrote:
<blockquote cite="mid:4ACD3ED5.2090903@rbxglobal.com" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
I will do more testing on this on the weekend (when I can dispose of
the systems more freely). Thanks for all your help though!<br>
<br>
I'll most certainly make sure to keep you in the loop with whatever I
find - worst case, we'll document for posterity in case others run into
the same hiccup. Best case, we find a cure - and who wouldn't like
that? :)<br>
<br>
Cheers!<br>
<br>
David McCullough wrote:
<blockquote cite="mid:20091008010153.GA14448@securecomputing.com"
type="cite">
<pre wrap="">Jivin Diego Rivera lays it down ...
</pre>
<blockquote type="cite">
<pre wrap="">The story is like this: two networks each with a DNS. The DNS's talk to each other so people in network A can resolve names in network B and vice-versa. Each DNS is configured as a slave to the other where appropriate. There's a VPN in place. The DNS's are told that the other is accessible via the VPN.
When the tunnel is not up, each DNS server attempting to cross it will promptly be told that the host is unreachable, and will settle for its own cached copy of the far side's data. Thus, no DNS delay is seen. This works marvelously.
When the tunnel is up, they can talk to each other, so it works even more marvelously still.
The problems come when one of them comes crashing down (or the network in between). It seems bind has a queue-type design to resolv queries, since once that happens it appears to hang waiting on the other side. The only way to unblock it is to kill ipsec completely, and then re-start the server, and finally re-start IPSec. This isn't necessarily a tenable scenario since one of the two nodes also has VPN's to other sites which must remain operational.
I've tested with 2.6.23 and it now works as expected - removing all KLIPS policies upon dead peer detection (using restart_by_peer). However, my predicament is that this still doesn't fix the DNS issue and it still hangs waiting for a timeout (i.e. I still need to kill ipsec altogether...). Crappy thing is that even a kill -9 won't kill bind - it appears to be hung on a system call (likely attempting to send a packet over the tunnel... but it disappeared in the middle of it... or somesuch). Thus, kill ipsec and then kill bind is the fix.
</pre>
</blockquote>
<pre wrap=""><!---->
It would be nice to know why bind is so unhappy (ie., what it is hung on).
You could try running 'strace -p <bind-pid>', should tell you what systems
call is stuck. If you can't kill -9 it, it's stuck in an uninterruptible
sleep in the kernel. I doubt this is in klips, but it could be, and it may
be something we can fix.
Once you know the system call, we can track the FD through /proc/<pid>/fd
and then on to sockets (most likely outcome) through netstat -na.
With some luck it may tell us what network conneciton/operation has hung.
</pre>
<blockquote type="cite">
<pre wrap="">At least, now I know that the problem is more related to bind and its expected timeouts. I've searched the bind docs to try to find where to configure these timeouts, with no luck... I guess I'll keep searching.
I'll probably read more about KLIPS in general to try to determine why this might be happening (i.e. having to kill ipsec prior to restarting bind), and try to determine how to "dislodge" bind so I can kill it and restart it without having to take the whole ipsec stack down.
Tunnel restart does appear to work fine now, btw. Though to be honest I haven't checked it in depth.
</pre>
</blockquote>
<pre wrap=""><!---->
Good to hear ;-) Lets see if we can figure out why bind has hung and whether or
not klips has something to do with it that can be rectified.
Cheers,
Davidm
</pre>
<blockquote type="cite">
<pre wrap="">David McCullough wrote:
Jivin Diego Rivera lays it down ...
Problems still persist - if I lose the other node, restart_by_peer doesn't take down the policies so I still have the DNS problem I'm trying to avoid. The tunnel does come up, though. Still, the reason the DNS problem is a big one is that if it gets "locked" (because of the presence of the policies but the absence of the tunnel) then general internet access will also be affected b/c the DNS is unable to resolve names.
I'll try restart, though I don't expect there to be an improvement. Hopefully, I'm wrong about that!
Any tips?
Not really. Your DNS shouldn't be affected by your ipsec policies should it ?
Unless you are using a DNS server on the remote network, but then that would
not work initially either ?
I am a bit confused because most of the policies are installed before the
tunnel is actually up.
I think we need an "ipsec barf" output when it's stuck, and a copy of your
resolv.conf. Either that or just the info (resolv.conf/routes/eroutes/pluto
status etc) that shows why it can't come up after the other end dies.
Cheers,
Davidm
David McCullough wrote:
Jivin Diego Rivera lays it down ...
Ok... so what you're saying is that restart_by_peer should have done the job, then? If so - then can you shed some more light into what the potential source of the problem is?
The most likely cause is version 2.6.22, I have included the changelog
below from 2.6.22 to 2.6.23, there were quite a few "tunnels won't
come up/restart" bugs fixed.
It would be best if you can try 2.6.23 so that any problems you see are
new ones ;-)
Cheers,
Davidm
* Support for dropping unneeded capabilities using libcap-ng [Avesh]
(Changed using USE_LIBCAP_NG= in Makefile.inc)
* Additional ASN.1 parser checks by David McCullough [David]
* PSK support with USE_LIBNSS [Avesh Agarwal]
* Allow multiple different PSK road warriors with Aggressive Mode [David]
* Additional KLIPS debugging can be enabled in /proc/net/ipsec_saraw [David]
* Extended fipschecks [Avesh Agarwal]
* auto=route tunnels could fail due to an Opportunstic Encryption bug [David]
* passthrough routes on NETKEY where missing a a policy [Michael H. Warfield]
* The init script was mistakenly installed twice, once as 'setup' [Paul/Harald]
* LSB compliance error in initscript (debian bug#537335) [Petter Reinholdtsen]
* Fix for old style nat-t patch on newstyle 2.6.23+ kernel [Paul]
* ipsec verify now returns non-zero when an error is encountered [Paul]
* Fix for ipsec whack --crash <IP> crasher [David]
* Partial fix for #1004. We no longer drop the port from protoport= [dhr/Paul]
transport mode L2TP now works again for the non-NAT'ed case
* Fix for size (XXX) differs from size specified in ISAKMP HDR (YYY) [David]
* Removed old USE_SMARTCARD code. Smartcards are now supported via NSS [Paul]
(not all code was properly #ifdef'ed, so a few changes outside #ifdef
SMARTCARD were needed)
* Prevent aggressive mode tunnels losing phase2 [David]
* Various fixes to eroutes [David]
* Bugtracker bugs fixed:
#1044: openswan.spec file builds an RPM that is missing lwdnsq [Joe Steele]
Cheers.
Paul Wouters wrote:
On Wed, 7 Oct 2009, Diego Rivera wrote:
I was using restart_by_peer but from what Paul says, that option means wait for the other side to
re-establish the tunnel. Thus, nobody tries to re-establish (since both sides are configured identically,
for easy maintenance).
I was wrong. David was right :)
Paul
--
Diego Rivera
Director / System Operations
Roundbox Global : enterprise : technology : genius
------------------------------------------------------------------------------------------------------------------
Avenida 11 y Calle 7-9, Barrio Am??n, San Jos??, Costa Rica
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695
email: <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:diego.rivera@rbxglobal.com">diego.rivera@rbxglobal.com</a> | <a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="http://www.rbxglobal.com">www.rbxglobal.com</a>
------------------------------------------------------------------------------------------------------------------
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enigAA960B031FE487E074E8895C"
--------------enigAA960B031FE487E074E8895C
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content=3D"text/html;charset=3DISO-8859-1" http-equiv=3D"Content-=
Type">
</head>
<body bgcolor=3D"#ffffff" text=3D"#000000">
Ok... so what you're saying is that restart_by_peer should have done
the job, then?&nbsp; If so - then can you shed some more light into what =
the
potential source of the problem is?<br>
<br>
Cheers.<br>
<br>
Paul Wouters wrote:
<blockquote
cite=3D<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:mid:alpine.LFD.1.10.0910071852200.12140@newtla.xelerance.com">"mid:alpine.LFD.1.10.0910071852200.12140@newtla.xelerance.com"</a> <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:mid:alpine.LFD.1.10.0910071852200.12140@newtla.xelerance.com"><mailto:mid:alpine.LFD.1.10.0910071852200.12140@newtla.xelerance.com></a> <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:mid:alpine.LFD.1.10.0910071852200.12140@newtla.xelerance.com"><mailto:mid:alpine.LFD.1.10.0910071852200.12140@newtla.xelerance.com></a> <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:mid:alpine.LFD.1.10.0910071852200.12140@newtla.xelerance.com"><mailto:mid:alpine.LFD.1.10.0910071852200.12140@newtla.xelerance.com></a>
type=3D"cite">On Wed, 7 Oct 2009, Diego Rivera wrote:
<br>
<br>
<blockquote type=3D"cite">I was using restart_by_peer but from what
Paul says, that option means wait for the other side to
<br>
re-establish the tunnel.&nbsp; Thus, nobody tries to re-establish (since
both sides are configured identically,
<br>
for easy maintenance).
<br>
</blockquote>
<br>
I was wrong. David was right :)
<br>
<br>
Paul
<br>
</blockquote>
<br>
<div class=3D"moz-signature">-- <br>
<style type=3D"text/css">
p { margin: 0; }
</style>
<div style=3D"font-family: Arial; font-size: 10pt; color: rgb(0, 0, 0);">=
<font size=3D"1"> Diego Rivera<br>
Director / System Operations<br>
Roundbox Global : <span
style=3D"font-style: italic; color: rgb(102, 102, 102);">enterprise :
technology : genius</span><br>
-------------------------------------------------------------------------=
-----------------------------------------<br>
Avenida 11 y Calle 7-9, Barrio Am&oacute;n, San Jos&eacute;, Costa Rica<b=
r>
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506)
2258-3695<br>
email: <a href=3D<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:diego.rivera@rbxglobal.com">"mailto:diego.rivera@rbxglobal.com"</a> <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:diego.rivera@rbxglobal.com"><mailto:diego.rivera@rbxglobal.com></a> <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:diego.rivera@rbxglobal.com"><mailto:diego.rivera@rbxglobal.com></a> <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:diego.rivera@rbxglobal.com"><mailto:diego.rivera@rbxglobal.com></a> >diego.rivera@rbxglob=
al.com</a>
| <a href=3D<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a> <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://www.rbxglobal.com"><http://www.rbxglobal.com></a> <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://www.rbxglobal.com"><http://www.rbxglobal.com></a> <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://www.rbxglobal.com"><http://www.rbxglobal.com></a> ><a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="http://www.rbxglobal.com">www.rbxglobal.com</a></a><br>
-------------------------------------------------------------------------=
-----------------------------------------<br>
</font> </div>
</div>
</body>
</html>
--------------enigAA960B031FE487E074E8895C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - <a moz-do-not-send="true"
class="moz-txt-link-freetext" href="http://enigmail.mozdev.org/">http://enigmail.mozdev.org/</a>
iEYEARECAAYFAkrNHG4ACgkQCNJ6MS9YngWAMwCbBt8lUPHDUZ0guPfnCDf6ZLjH
/UwAni4UumFFXJ/U6iIuNtvzxnGCzjnZ
=YpwI
-----END PGP SIGNATURE-----
--------------enigAA960B031FE487E074E8895C--
--
Diego Rivera
Director / System Operations
Roundbox Global : enterprise : technology : genius
------------------------------------------------------------------------------------------------------------------
Avenida 11 y Calle 7-9, Barrio Am??n, San Jos??, Costa Rica
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695
email: <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:diego.rivera@rbxglobal.com">diego.rivera@rbxglobal.com</a> | <a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="http://www.rbxglobal.com">www.rbxglobal.com</a>
------------------------------------------------------------------------------------------------------------------
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enigCDF7F7110CFB1AEE0CAC1719"
--------------enigCDF7F7110CFB1AEE0CAC1719
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content=3D"text/html;charset=3DISO-8859-1" http-equiv=3D"Content-=
Type">
</head>
<body bgcolor=3D"#ffffff" text=3D"#000000">
Problems still persist - if I lose the other node, restart_by_peer
doesn't take down the policies so I still have the DNS problem I'm
trying to avoid.&nbsp; The tunnel does come up, though.&nbsp; Still, the =
reason
the DNS problem is a big one is that if it gets "locked" (because of
the presence of the policies but the absence of the tunnel) then
general internet access will also be affected b/c the DNS is unable to
resolve names.<br>
<br>
I'll try restart, though I don't expect there to be an improvement.&nbsp;=
Hopefully, I'm wrong about that!<br>
<br>
Any tips?<br>
<br>
David McCullough wrote:
<blockquote cite=3D<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:mid:20091007231256.GA9796@securecomputing.com">"mid:20091007231256.GA9796@securecomputing.com"</a> <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:mid:20091007231256.GA9796@securecomputing.com"><mailto:mid:20091007231256.GA9796@securecomputing.com></a>
type=3D"cite">
<pre wrap=3D"">Jivin Diego Rivera lays it down ...
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">Ok... so what you're saying is that restart_by_peer sh=
ould have done the job, then? If so - then can you shed some more light =
into what the potential source of the problem is?
</pre>
</blockquote>
<pre wrap=3D""><!---->
The most likely cause is version 2.6.22, I have included the changelog
below from 2.6.22 to 2.6.23, there were quite a few "tunnels won't
come up/restart" bugs fixed.
It would be best if you can try 2.6.23 so that any problems you see are
new ones ;-)
Cheers,
Davidm
* Support for dropping unneeded capabilities using libcap-ng [Avesh]
(Changed using USE_LIBCAP_NG=3D in Makefile.inc)
* Additional ASN.1 parser checks by David McCullough [David]
* PSK support with USE_LIBNSS [Avesh Agarwal]
* Allow multiple different PSK road warriors with Aggressive Mode [David]=
* Additional KLIPS debugging can be enabled in /proc/net/ipsec_saraw [Dav=
id]
* Extended fipschecks [Avesh Agarwal]
* auto=3Droute tunnels could fail due to an Opportunstic Encryption bug [=
David]
* passthrough routes on NETKEY where missing a a policy [Michael H. Warfi=
eld]
* The init script was mistakenly installed twice, once as 'setup' [Paul/H=
arald]
* LSB compliance error in initscript (debian bug#537335) [Petter Reinhold=
tsen]
* Fix for old style nat-t patch on newstyle 2.6.23+ kernel [Paul]
* ipsec verify now returns non-zero when an error is encountered [Paul]
* Fix for ipsec whack --crash &lt;IP&gt; crasher [David]
* Partial fix for #1004. We no longer drop the port from protoport=3D [dh=
r/Paul]
transport mode L2TP now works again for the non-NAT'ed case
* Fix for size (XXX) differs from size specified in ISAKMP HDR (YYY) [Dav=
id]
* Removed old USE_SMARTCARD code. Smartcards are now supported via NSS [P=
aul]
(not all code was properly #ifdef'ed, so a few changes outside #ifdef
SMARTCARD were needed)
* Prevent aggressive mode tunnels losing phase2 [David]
* Various fixes to eroutes [David]
* Bugtracker bugs fixed:
#1044: openswan.spec file builds an RPM that is missing lwdnsq [Joe St=
eele]
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">Cheers.
Paul Wouters wrote:=20
On Wed, 7 Oct 2009, Diego Rivera wrote:=20
=09
=09
I was using restart_by_peer but from what Paul says, that option means =
wait for the other side to=20
re-establish the tunnel. Thus, nobody tries to re-establish (since bot=
h sides are configured identically,=20
for easy maintenance).=20
=09
I was wrong. David was right :)=20
=09
Paul=20
=09
--=20
Diego Rivera
Director / System Operations
Roundbox Global : enterprise : technology : genius
-------------------------------------------------------------------------=
-----------------------------------------
Avenida 11 y Calle 7-9, Barrio Am??n, San Jos??, Costa Rica
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 22=
58-3695
email: <a class=3D"moz-txt-link-abbreviated" href=3D<a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:diego.rivera@=rbxglobal.com">"mailto:diego.rivera@=
rbxglobal.com"</a> <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:diego.rivera@=rbxglobal.com"><mailto:diego.rivera@=rbxglobal.com></a> ><a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:diego.rivera@rbxglobal.com">diego.rivera@rbxglobal.com</a></a> | <a class=3D"moz-txt-link-=
abbreviated" href=3D<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a> <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://www.rbxglobal.com"><http://www.rbxglobal.com></a> ><a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="http://www.rbxglobal.com">www.rbxglobal.com</a></a>
-------------------------------------------------------------------------=
-----------------------------------------
</pre>
</blockquote>
<pre wrap=3D""><!---->
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">Content-Type: multipart/signed; micalg=3Dpgp-sha1;
protocol=3D"application/pgp-signature";
boundary=3D"------------enigAA960B031FE487E074E8895C"
--------------enigAA960B031FE487E074E8895C
Content-Type: text/html; charset=3DISO-8859-1
Content-Transfer-Encoding: quoted-printable
&lt;!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"&gt;
&lt;html&gt;
&lt;head&gt;
&lt;meta content=3D3D"text/html;charset=3D3DISO-8859-1" http-equiv=3D3D=
"Content-=3D
Type"&gt;
&lt;/head&gt;
&lt;body bgcolor=3D3D"#ffffff" text=3D3D"#000000"&gt;
Ok... so what you're saying is that restart_by_peer should have done
the job, then?&amp;nbsp; If so - then can you shed some more light into w=
hat =3D
the
potential source of the problem is?&lt;br&gt;
&lt;br&gt;
Cheers.&lt;br&gt;
&lt;br&gt;
Paul Wouters wrote:
&lt;blockquote
cite=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D<a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:mid:alpine.LF=D.1.10.0910071852200.12140@newtla.xelerance.com">"mailto:mid:alpine.LF=
D.1.10.0910071852200.12140@newtla.xelerance.com"</a> <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:mid:alpine.LF=D.1.10.0910071852200.12140@newtla.xelerance.com"><mailto:mid:alpine.LF=D.1.10.0910071852200.12140@newtla.xelerance.com></a> >"mid:alpine.LFD.1.10.091=
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:0071852200.12140@newtla.xelerance.com">0071852200.12140@newtla.xelerance.com</a>"</a>
type=3D3D"cite"&gt;On Wed, 7 Oct 2009, Diego Rivera wrote:
&lt;br&gt;
&lt;br&gt;
&lt;blockquote type=3D3D"cite"&gt;I was using restart_by_peer but from =
what
Paul says, that option means wait for the other side to
&lt;br&gt;
re-establish the tunnel.&amp;nbsp; Thus, nobody tries to re-establish (si=
nce
both sides are configured identically,
&lt;br&gt;
for easy maintenance).
&lt;br&gt;
&lt;/blockquote&gt;
&lt;br&gt;
I was wrong. David was right :)
&lt;br&gt;
&lt;br&gt;
Paul
&lt;br&gt;
&lt;/blockquote&gt;
&lt;br&gt;
&lt;div class=3D3D"moz-signature"&gt;-- &lt;br&gt;
&lt;style type=3D3D"text/css"&gt;
p { margin: 0; }
&lt;/style&gt;
&lt;div style=3D3D"font-family: Arial; font-size: 10pt; color: rgb(0, 0, =
0);"&gt;=3D
&lt;font size=3D3D"1"&gt; Diego Rivera&lt;br&gt;
Director / System Operations&lt;br&gt;
Roundbox Global : &lt;span
style=3D3D"font-style: italic; color: rgb(102, 102, 102);"&gt;enterprise=
:
technology : genius&lt;/span&gt;&lt;br&gt;
-------------------------------------------------------------------------=
=3D
-----------------------------------------&lt;br&gt;
Avenida 11 y Calle 7-9, Barrio Am&amp;oacute;n, San Jos&amp;eacute;, Cost=
a Rica&lt;b=3D
r&gt;
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506)
2258-3695&lt;br&gt;
email: &lt;a href=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D<a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:d=iego.rivera@rbxglobal.com">"mailto:d=
iego.rivera@rbxglobal.com"</a> <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:d=iego.rivera@rbxglobal.com"><mailto:d=iego.rivera@rbxglobal.com></a> ><a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:diego.rivera@rbxglobal.com">"mailto:diego.rivera@rbxglobal.com"</a> <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:diego.rivera@rbxglobal.com"><mailto:diego.rivera@rbxglobal.com></a> </a>&gt;die=
go.rivera@rbxglob=3D
al.com&lt;/a&gt;
| &lt;a href=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D<a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://www.rb=xglobal.com">"http://www.rb=
xglobal.com"</a> <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="http://www.rb=xglobal.com"><http://www.rb=xglobal.com></a> ><a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a> <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://www.rbxglobal.com"><http://www.rbxglobal.com></a> </a>&gt;<a class=3D"moz-txt-link-a=
bbreviated" href=3D<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a> <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://www.rbxglobal.com"><http://www.rbxglobal.com></a> ><a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="http://www.rbxglobal.com">www.rbxglobal.com</a></a>&lt;/a=
&gt;&lt;br&gt;
-------------------------------------------------------------------------=
=3D
-----------------------------------------&lt;br&gt;
&lt;/font&gt; &lt;/div&gt;
&lt;/div&gt;
&lt;/body&gt;
&lt;/html&gt;
--------------enigAA960B031FE487E074E8895C
Content-Type: application/pgp-signature; name=3D"signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=3D"signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - <a class=3D"moz-txt-link-freetext" hr=
ef=3D<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://enigmail.mozdev.org/">"http://enigmail.mozdev.org/"</a> <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://enigmail.mozdev.org/"><http://enigmail.mozdev.org/></a> ><a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://enigmail.mozdev.org/">http://enigmail.mozdev.org/</a></a>
iEYEARECAAYFAkrNHG4ACgkQCNJ6MS9YngWAMwCbBt8lUPHDUZ0guPfnCDf6ZLjH
/UwAni4UumFFXJ/U6iIuNtvzxnGCzjnZ
=3DYpwI
-----END PGP SIGNATURE-----
--------------enigAA960B031FE487E074E8895C--
</pre>
</blockquote>
<pre wrap=3D""><!---->
</pre>
</blockquote>
<br>
<div class=3D"moz-signature">-- <br>
<style type=3D"text/css">
p { margin: 0; }
</style>
<div style=3D"font-family: Arial; font-size: 10pt; color: rgb(0, 0, 0);">=
<font size=3D"1"> Diego Rivera<br>
Director / System Operations<br>
Roundbox Global : <span
style=3D"font-style: italic; color: rgb(102, 102, 102);">enterprise :
technology : genius</span><br>
-------------------------------------------------------------------------=
-----------------------------------------<br>
Avenida 11 y Calle 7-9, Barrio Am&oacute;n, San Jos&eacute;, Costa Rica<b=
r>
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506)
2258-3695<br>
email: <a href=3D<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:diego.rivera@rbxglobal.com">"mailto:diego.rivera@rbxglobal.com"</a> <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:diego.rivera@rbxglobal.com"><mailto:diego.rivera@rbxglobal.com></a> >diego.rivera@rbxglob=
al.com</a>
| <a href=3D<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a> <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://www.rbxglobal.com"><http://www.rbxglobal.com></a> ><a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="http://www.rbxglobal.com">www.rbxglobal.com</a></a><br>
-------------------------------------------------------------------------=
-----------------------------------------<br>
</font> </div>
</div>
</body>
</html>
--------------enigCDF7F7110CFB1AEE0CAC1719
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - <a moz-do-not-send="true"
class="moz-txt-link-freetext" href="http://enigmail.mozdev.org/">http://enigmail.mozdev.org/</a>
iEYEARECAAYFAkrNL4gACgkQCNJ6MS9YngVUPACeImqX4x/AJHWC9BpEfseXgQ4I
1+wAmwYCJ4M11b5Ib/rU0MyvsphNxH/f
=pW+2
-----END PGP SIGNATURE-----
--------------enigCDF7F7110CFB1AEE0CAC1719--
--
Diego Rivera
Director / System Operations
Roundbox Global : enterprise : technology : genius
------------------------------------------------------------------------------------------------------------------
Avenida 11 y Calle 7-9, Barrio Am??n, San Jos??, Costa Rica
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695
email: <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:diego.rivera@rbxglobal.com">diego.rivera@rbxglobal.com</a> | <a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="http://www.rbxglobal.com">www.rbxglobal.com</a>
------------------------------------------------------------------------------------------------------------------
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enigE16CEB9A8D282663041FAE25"
--------------enigE16CEB9A8D282663041FAE25
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content=3D"text/html;charset=3DISO-8859-1" http-equiv=3D"Content-=
Type">
<title></title>
</head>
<body bgcolor=3D"#ffffff" text=3D"#000000">
The story is like this: two networks each with a DNS.&nbsp; The DNS's tal=
k
to each other so people in network A can resolve names in network B and
vice-versa.&nbsp; Each DNS is configured as a slave to the other where
appropriate.&nbsp; There's a VPN in place.&nbsp; The DNS's are told that =
the
other is accessible via the VPN.<br>
<br>
When the tunnel is not up, each DNS server attempting to cross it will
promptly be told that the host is unreachable, and will settle for its
own cached copy of the far side's data.&nbsp; Thus, no DNS delay is seen.=
&nbsp;
This works marvelously.<br>
<br>
When the tunnel is up, they can talk to each other, so it works even
more marvelously still.<br>
<br>
The problems come when one of them comes crashing down (or the network
in between).&nbsp; It seems bind has a queue-type design to resolv querie=
s,
since once that happens it appears to hang waiting on the other side.&nbs=
p;
The only way to unblock it is to kill ipsec completely, and then
re-start the server, and finally re-start IPSec.&nbsp; This isn't
necessarily a tenable scenario since one of the two nodes also has
VPN's to other sites which must remain operational.<br>
<br>
I've tested with 2.6.23 and it now works as expected - removing all
KLIPS policies upon dead peer detection (using restart_by_peer).&nbsp;
However, my predicament is that this still doesn't fix the DNS issue
and it still hangs waiting for a timeout (i.e. I still need to kill
ipsec altogether...).&nbsp; Crappy thing is that even a kill -9 won't kil=
l
bind - it appears to be hung on a system call (likely attempting to
send a packet over the tunnel... but it disappeared in the middle of
it... or somesuch).&nbsp; Thus, kill ipsec and then kill bind is the fix.=
<br>
<br>
At least, now I know that the problem is more related to bind and its
expected timeouts.&nbsp; I've searched the bind docs to try to find where=
to
configure these timeouts, with no luck... I guess I'll keep searching.<br=
</pre>
<pre wrap=""><br>
I'll probably read more about KLIPS in general to try to determine why
this might be happening (i.e. having to kill ipsec prior to restarting
bind), and try to determine how to "dislodge" bind so I can kill it and
restart it without having to take the whole ipsec stack down.<br>
<br>
Tunnel restart does appear to work fine now, btw.&nbsp; Though to be hone=
st
I haven't checked it in depth.<br>
<br>
Cheers.<br>
<br>
<br>
David McCullough wrote:
<blockquote cite=3D<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:mid:20091008003323.GD11186@securecomputing.com">"mid:20091008003323.GD11186@securecomputing.com"</a>
type=3D"cite">
<pre wrap=3D"">Jivin Diego Rivera lays it down ...
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">Problems still persist - if I lose the other node, res=
tart_by_peer doesn't take down the policies so I still have the DNS probl=
em I'm trying to avoid. The tunnel does come up, though. Still, the rea=
son the DNS problem is a big one is that if it gets "locked" (because of =
the presence of the policies but the absence of the tunnel) then general =
internet access will also be affected b/c the DNS is unable to resolve na=
mes.
I'll try restart, though I don't expect there to be an improvement. Hope=
fully, I'm wrong about that!
Any tips?
</pre>
</blockquote>
<pre wrap=3D""><!---->
Not really. Your DNS shouldn't be affected by your ipsec policies should=
it ?
Unless you are using a DNS server on the remote network, but then that w=
ould
not work initially either ?
I am a bit confused because most of the policies are installed before the=
tunnel is actually up.
I think we need an "ipsec barf" output when it's stuck, and a copy of yo=
ur
resolv.conf. Either that or just the info (resolv.conf/routes/eroutes/pl=
uto
status etc) that shows why it can't come up after the other end dies.
Cheers,
Davidm
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">David McCullough wrote:=20
Jivin Diego Rivera lays it down ...
=20
Ok... so what you're saying is that restart_by_peer should have done th=
e job, then? If so - then can you shed some more light into what the pot=
ential source of the problem is?
=20
=09
The most likely cause is version 2.6.22, I have included the changelog
below from 2.6.22 to 2.6.23, there were quite a few "tunnels won't
come up/restart" bugs fixed.
=09
It would be best if you can try 2.6.23 so that any problems you see are
new ones ;-)
=09
Cheers,
Davidm
=09
* Support for dropping unneeded capabilities using libcap-ng [Avesh]
(Changed using USE_LIBCAP_NG=3D in Makefile.inc)
* Additional ASN.1 parser checks by David McCullough [David]
* PSK support with USE_LIBNSS [Avesh Agarwal]
* Allow multiple different PSK road warriors with Aggressive Mode [David=
]
* Additional KLIPS debugging can be enabled in /proc/net/ipsec_saraw [Da=
vid]
* Extended fipschecks [Avesh Agarwal]
* auto=3Droute tunnels could fail due to an Opportunstic Encryption bug =
[David]
* passthrough routes on NETKEY where missing a a policy [Michael H. Warf=
ield]
* The init script was mistakenly installed twice, once as 'setup' [Paul/=
Harald]
* LSB compliance error in initscript (debian bug#537335) [Petter Reinhol=
dtsen]
* Fix for old style nat-t patch on newstyle 2.6.23+ kernel [Paul]
* ipsec verify now returns non-zero when an error is encountered [Paul]
* Fix for ipsec whack --crash &lt;IP&gt; crasher [David]
* Partial fix for #1004. We no longer drop the port from protoport=3D [d=
hr/Paul]
transport mode L2TP now works again for the non-NAT'ed case
* Fix for size (XXX) differs from size specified in ISAKMP HDR (YYY) [Da=
vid]
* Removed old USE_SMARTCARD code. Smartcards are now supported via NSS [=
Paul]
(not all code was properly #ifdef'ed, so a few changes outside #ifdef
SMARTCARD were needed)
* Prevent aggressive mode tunnels losing phase2 [David]
* Various fixes to eroutes [David]
* Bugtracker bugs fixed:
#1044: openswan.spec file builds an RPM that is missing lwdnsq [Joe S=
teele]
=09
=09
=20
Cheers.
=09
Paul Wouters wrote:=20
=09
On Wed, 7 Oct 2009, Diego Rivera wrote:=20
=09
=09
=09
I was using restart_by_peer but from what Paul says, that option mean=
s wait for the other side to=20
re-establish the tunnel. Thus, nobody tries to re-establish (since b=
oth sides are configured identically,=20
for easy maintenance).=20
=09
=09
=09
I was wrong. David was right :)=20
=09
Paul=20
=09
=09
=09
--=20
=09
Diego Rivera
Director / System Operations
Roundbox Global : enterprise : technology : genius
-----------------------------------------------------------------------=
-------------------------------------------
Avenida 11 y Calle 7-9, Barrio Am??n, San Jos??, Costa Rica
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) =
2258-3695
email: <a class=3D"moz-txt-link-abbreviated" href=3D<a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:diego.river=a@rbxglobal.com">"mailto:diego.river=
a@rbxglobal.com"</a>><a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:diego.rivera@rbxglobal.com">diego.rivera@rbxglobal.com</a></a> | <a class=3D"moz-txt-lin=
k-abbreviated" href=3D<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a>><a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="http://www.rbxglobal.com">www.rbxglobal.com</a></a>
-----------------------------------------------------------------------=
-------------------------------------------
=09
=09
=20
=09
=20
Content-Type: multipart/signed; micalg=3Dpgp-sha1;
protocol=3D"application/pgp-signature";
boundary=3D"------------enigAA960B031FE487E074E8895C"
=09
--------------enigAA960B031FE487E074E8895C
Content-Type: text/html; charset=3DISO-8859-1
Content-Transfer-Encoding: quoted-printable
=09
&lt;!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"&gt;
&lt;html&gt;
&lt;head&gt;
&lt;meta content=3D3D"text/html;charset=3D3DISO-8859-1" http-equiv=3D=
3D"Content-=3D
Type"&gt;
&lt;/head&gt;
&lt;body bgcolor=3D3D"#ffffff" text=3D3D"#000000"&gt;
Ok... so what you're saying is that restart_by_peer should have done
the job, then?&amp;nbsp; If so - then can you shed some more light into=
what =3D
the
potential source of the problem is?&lt;br&gt;
&lt;br&gt;
Cheers.&lt;br&gt;
&lt;br&gt;
Paul Wouters wrote:
&lt;blockquote
cite=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D<a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:mid:alpine.=LFD.1.10.0910071852200.12140@newtla.xelerance.com">"mailto:mid:alpine.=
LFD.1.10.0910071852200.12140@newtla.xelerance.com"</a>>"mid:alpine.LFD.1.10.0=
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:910071852200.12140@newtla.xelerance.com">910071852200.12140@newtla.xelerance.com</a>"</a> <a class=3D"moz-txt-link-rfc=
2396E" href=3D<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:mid:alpine.LFD.1.10.0910071852200.12140@newtla.xele=rance.com">"mailto:mid:alpine.LFD.1.10.0910071852200.12140@newtla.xele=
rance.com"</a>>&lt;<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="mailto:mid:alpine.LFD.1.10.0910071852200.12140@newtla.xele=">mailto:mid:alpine.LFD.1.10.0910071852200.12140@newtla.xele=</a>
rance.com&gt;</a>=20
type=3D3D"cite"&gt;On Wed, 7 Oct 2009, Diego Rivera wrote:
&lt;br&gt;
&lt;br&gt;
&lt;blockquote type=3D3D"cite"&gt;I was using restart_by_peer but fro=
m what
Paul says, that option means wait for the other side to
&lt;br&gt;
re-establish the tunnel.&amp;nbsp; Thus, nobody tries to re-establish (=
since
both sides are configured identically,
&lt;br&gt;
for easy maintenance).
&lt;br&gt;
&lt;/blockquote&gt;
&lt;br&gt;
I was wrong. David was right :)
&lt;br&gt;
&lt;br&gt;
Paul
&lt;br&gt;
&lt;/blockquote&gt;
&lt;br&gt;
&lt;div class=3D3D"moz-signature"&gt;-- &lt;br&gt;
&lt;style type=3D3D"text/css"&gt;
p { margin: 0; }
&lt;/style&gt;
&lt;div style=3D3D"font-family: Arial; font-size: 10pt; color: rgb(0, 0=
, 0);"&gt;=3D
=09
&lt;font size=3D3D"1"&gt; Diego Rivera&lt;br&gt;
Director / System Operations&lt;br&gt;
Roundbox Global : &lt;span
style=3D3D"font-style: italic; color: rgb(102, 102, 102);"&gt;enterpri=
se :
technology : genius&lt;/span&gt;&lt;br&gt;
-----------------------------------------------------------------------=
--=3D
-----------------------------------------&lt;br&gt;
Avenida 11 y Calle 7-9, Barrio Am&amp;oacute;n, San Jos&amp;eacute;, Co=
sta Rica&lt;b=3D
r&gt;
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506)
2258-3695&lt;br&gt;
email: &lt;a href=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D"mailto=
:diego.rivera@rbxglobal.com"><a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:diego.rivera@rbxglobal.com">"mailto:diego.rivera@rbxglobal.com"</a></a> <a c=
lass=3D"moz-txt-link-rfc2396E" href=3D<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:diego.rivera@rbxglobal.com">"mailto:diego.rivera@rbxglobal.com"</a>=
</pre>
<blockquote type="cite">
<pre wrap="">&lt;<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="mailto:diego.rivera@rbxglobal.com%3E">mailto:diego.rivera@rbxglobal.com&gt</a>;</a> &gt;diego.rivera@rbxglob=3D=
</pre>
</blockquote>
<pre wrap=""> al.com&lt;/a&gt;
| &lt;a href=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D<a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://www.=rbxglobal.com">"http://www.=
rbxglobal.com"</a>><a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a></a> <a class=3D"moz-txt-link-rf=
c2396E" href=3D<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a>>&lt;<a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.rbxglobal.com%3E=">http://www.rbxglobal.com&gt=</a>
;</a> &gt;<a class=3D"moz-txt-link-abbreviated" href=3D<a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://www.rbxglo=bal.com">"http://www.rbxglo=
bal.com"</a>><a moz-do-not-send="true"
class="moz-txt-link-abbreviated" href="http://www.rbxglobal.com">www.rbxglobal.com</a></a>&lt;/a&gt;&lt;br&gt;
-----------------------------------------------------------------------=
--=3D
-----------------------------------------&lt;br&gt;
&lt;/font&gt; &lt;/div&gt;
&lt;/div&gt;
&lt;/body&gt;
&lt;/html&gt;
=09
=09
--------------enigAA960B031FE487E074E8895C
Content-Type: application/pgp-signature; name=3D"signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=3D"signature.asc"
=09
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - <a class=3D"moz-txt-link-freetext" =
href=3D<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://enigmail.mozdev.org/">"http://enigmail.mozdev.org/"</a>><a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://enigmail.mozdev.org/">http://enigmail.mozdev.org/</a></a>
=09
iEYEARECAAYFAkrNHG4ACgkQCNJ6MS9YngWAMwCbBt8lUPHDUZ0guPfnCDf6ZLjH
/UwAni4UumFFXJ/U6iIuNtvzxnGCzjnZ
=3DYpwI
-----END PGP SIGNATURE-----
=09
--------------enigAA960B031FE487E074E8895C--
=20
=09
=09
=20
--=20
Diego Rivera
Director / System Operations
Roundbox Global : enterprise : technology : genius
-------------------------------------------------------------------------=
-----------------------------------------
Avenida 11 y Calle 7-9, Barrio Am??n, San Jos??, Costa Rica
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 22=
58-3695
email: <a class=3D"moz-txt-link-abbreviated" href=3D<a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:diego.rivera@=rbxglobal.com">"mailto:diego.rivera@=
rbxglobal.com"</a>><a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:diego.rivera@rbxglobal.com">diego.rivera@rbxglobal.com</a></a> | <a class=3D"moz-txt-link-=
abbreviated" href=3D<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a>><a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="http://www.rbxglobal.com">www.rbxglobal.com</a></a>
-------------------------------------------------------------------------=
-----------------------------------------
</pre>
</blockquote>
<pre wrap=3D""><!---->
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">Content-Type: multipart/signed; micalg=3Dpgp-sha1;
protocol=3D"application/pgp-signature";
boundary=3D"------------enigCDF7F7110CFB1AEE0CAC1719"
--------------enigCDF7F7110CFB1AEE0CAC1719
Content-Type: text/html; charset=3DISO-8859-1
Content-Transfer-Encoding: quoted-printable
&lt;!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"&gt;
&lt;html&gt;
&lt;head&gt;
&lt;meta content=3D3D"text/html;charset=3D3DISO-8859-1" http-equiv=3D3D=
"Content-=3D
Type"&gt;
&lt;/head&gt;
&lt;body bgcolor=3D3D"#ffffff" text=3D3D"#000000"&gt;
Problems still persist - if I lose the other node, restart_by_peer
doesn't take down the policies so I still have the DNS problem I'm
trying to avoid.&amp;nbsp; The tunnel does come up, though.&amp;nbsp; Sti=
ll, the =3D
reason
the DNS problem is a big one is that if it gets "locked" (because of
the presence of the policies but the absence of the tunnel) then
general internet access will also be affected b/c the DNS is unable to
resolve names.&lt;br&gt;
&lt;br&gt;
I'll try restart, though I don't expect there to be an improvement.&amp;n=
bsp;=3D
Hopefully, I'm wrong about that!&lt;br&gt;
&lt;br&gt;
Any tips?&lt;br&gt;
&lt;br&gt;
David McCullough wrote:
&lt;blockquote cite=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D"mailto=
:mid:20091007231256.GA9796@securecomputing.com">"mid:20091007231256.GA979=
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:6@securecomputing.com">6@securecomputing.com</a>"</a>
type=3D3D"cite"&gt;
&lt;pre wrap=3D3D""&gt;Jivin Diego Rivera lays it down ...
&lt;/pre&gt;
&lt;blockquote type=3D3D"cite"&gt;
&lt;pre wrap=3D3D""&gt;Ok... so what you're saying is that restart_by=
_peer sh=3D
ould have done the job, then? If so - then can you shed some more light =
=3D
into what the potential source of the problem is?
&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;pre wrap=3D3D""&gt;&lt;!----&gt;
The most likely cause is version 2.6.22, I have included the changelog
below from 2.6.22 to 2.6.23, there were quite a few "tunnels won't
come up/restart" bugs fixed.
It would be best if you can try 2.6.23 so that any problems you see are
new ones ;-)
Cheers,
Davidm
* Support for dropping unneeded capabilities using libcap-ng [Avesh]
(Changed using USE_LIBCAP_NG=3D3D in Makefile.inc)
* Additional ASN.1 parser checks by David McCullough [David]
* PSK support with USE_LIBNSS [Avesh Agarwal]
* Allow multiple different PSK road warriors with Aggressive Mode [David]=
=3D
* Additional KLIPS debugging can be enabled in /proc/net/ipsec_saraw [Dav=
=3D
id]
* Extended fipschecks [Avesh Agarwal]
* auto=3D3Droute tunnels could fail due to an Opportunstic Encryption bug=
[=3D
David]
* passthrough routes on NETKEY where missing a a policy [Michael H. Warfi=
=3D
eld]
* The init script was mistakenly installed twice, once as 'setup' [Paul/H=
=3D
arald]
* LSB compliance error in initscript (debian bug#537335) [Petter Reinhold=
=3D
tsen]
* Fix for old style nat-t patch on newstyle 2.6.23+ kernel [Paul]
* ipsec verify now returns non-zero when an error is encountered [Paul]
* Fix for ipsec whack --crash &amp;lt;IP&amp;gt; crasher [David]
* Partial fix for #1004. We no longer drop the port from protoport=3D3D [=
dh=3D
r/Paul]
transport mode L2TP now works again for the non-NAT'ed case
* Fix for size (XXX) differs from size specified in ISAKMP HDR (YYY) [Dav=
=3D
id]
* Removed old USE_SMARTCARD code. Smartcards are now supported via NSS [P=
=3D
aul]
(not all code was properly #ifdef'ed, so a few changes outside #ifdef
SMARTCARD were needed)
* Prevent aggressive mode tunnels losing phase2 [David]
* Various fixes to eroutes [David]
* Bugtracker bugs fixed:
#1044: openswan.spec file builds an RPM that is missing lwdnsq [Joe St=
=3D
eele]
&lt;/pre&gt;
&lt;blockquote type=3D3D"cite"&gt;
&lt;pre wrap=3D3D""&gt;Cheers.
Paul Wouters wrote:=3D20
On Wed, 7 Oct 2009, Diego Rivera wrote:=3D20
=3D09
=3D09
I was using restart_by_peer but from what Paul says, that option means =
=3D
wait for the other side to=3D20
re-establish the tunnel. Thus, nobody tries to re-establish (since bot=
=3D
h sides are configured identically,=3D20
for easy maintenance).=3D20
=3D09
I was wrong. David was right :)=3D20
=3D09
Paul=3D20
=3D09
--=3D20
Diego Rivera
Director / System Operations
Roundbox Global : enterprise : technology : genius
-------------------------------------------------------------------------=
=3D
-----------------------------------------
Avenida 11 y Calle 7-9, Barrio Am??n, San Jos??, Costa Rica
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 22=
=3D
58-3695
email: &lt;a class=3D3D"moz-txt-link-abbreviated" href=3D3D<a class=3D"mo=
z-txt-link-rfc2396E" href=3D<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:diego.rivera@=3Drbxglobal.com">"mailto:diego.rivera@=3Drbxglobal.com"</a>>"mailt=
o:diego.rivera@=3D
rbxglobal.com"</a>&gt;<a class=3D"moz-txt-link-abbreviated" href=3D"mailt=
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:o:diego.rivera@rbxglobal.com">o:diego.rivera@rbxglobal.com</a>"><a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:diego.rivera@rbxglobal.com">diego.rivera@rbxglobal.com</a></a>&lt;/a&gt; | =
&lt;a class=3D3D"moz-txt-link-=3D
abbreviated" href=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D<a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://w=ww.rbxglobal.com">"http://w=
ww.rbxglobal.com"</a>><a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a></a>&gt;<a class=3D"moz-txt-l=
ink-abbreviated" href=3D<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a>><a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="http://www.rbxglobal.com">www.rbxglobal.com</a></a>&=
lt;/a&gt;
-------------------------------------------------------------------------=
=3D
-----------------------------------------
&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;pre wrap=3D3D""&gt;&lt;!----&gt;
&lt;/pre&gt;
&lt;blockquote type=3D3D"cite"&gt;
&lt;pre wrap=3D3D""&gt;Content-Type: multipart/signed; micalg=3D3Dpgp=
-sha1;
protocol=3D3D"application/pgp-signature";
boundary=3D3D"------------enigAA960B031FE487E074E8895C"
--------------enigAA960B031FE487E074E8895C
Content-Type: text/html; charset=3D3DISO-8859-1
Content-Transfer-Encoding: quoted-printable
&amp;lt;!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"&amp=
;gt;
&amp;lt;html&amp;gt;
&amp;lt;head&amp;gt;
&amp;lt;meta content=3D3D3D"text/html;charset=3D3D3DISO-8859-1" http-eq=
uiv=3D3D3D=3D
"Content-=3D3D
Type"&amp;gt;
&amp;lt;/head&amp;gt;
&amp;lt;body bgcolor=3D3D3D"#ffffff" text=3D3D3D"#000000"&amp;gt;
Ok... so what you're saying is that restart_by_peer should have done
the job, then?&amp;amp;nbsp; If so - then can you shed some more light in=
to w=3D
hat =3D3D
the
potential source of the problem is?&amp;lt;br&amp;gt;
&amp;lt;br&amp;gt;
Cheers.&amp;lt;br&amp;gt;
&amp;lt;br&amp;gt;
Paul Wouters wrote:
&amp;lt;blockquote
cite=3D3D3D&lt;a class=3D3D"moz-txt-link-rfc2396E" href=3D3D<a class=3D"=
moz-txt-link-rfc2396E" href=3D<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:mid:alpine.LF=3DD.1.10.091007185220=0.12140@newtla.xelerance.com">"mailto:mid:alpine.LF=3DD.1.10.091007185220=
0.12140@newtla.xelerance.com"</a>><a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:mid:alpine.LF=3DD.1.10.0910071852200.12140@newtla.xelerance.com">"mailto:mid:alpine.LF=3D
D.1.10.0910071852200.12140@newtla.xelerance.com"</a></a>&gt;"mid:alpine.LFD.1=
=2E10.091=3D
<a class=3D"moz-txt-link-abbreviated" href=3D<a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:0071852200.12140@new=tla.xelerance.com">"mailto:0071852200.12140@new=
tla.xelerance.com"</a>><a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:0071852200.12140@newtla.xelerance.com">0071852200.12140@newtla.xelerance.com</a></a>"&lt;/a&gt;
type=3D3D3D"cite"&amp;gt;On Wed, 7 Oct 2009, Diego Rivera wrote:
&amp;lt;br&amp;gt;
&amp;lt;br&amp;gt;
&amp;lt;blockquote type=3D3D3D"cite"&amp;gt;I was using restart_by_peer=
but from =3D
what
Paul says, that option means wait for the other side to
&amp;lt;br&amp;gt;
re-establish the tunnel.&amp;amp;nbsp; Thus, nobody tries to re-establish=
(si=3D
nce
both sides are configured identically,
&amp;lt;br&amp;gt;
for easy maintenance).
&amp;lt;br&amp;gt;
&amp;lt;/blockquote&amp;gt;
&amp;lt;br&amp;gt;
I was wrong. David was right :)
&amp;lt;br&amp;gt;
&amp;lt;br&amp;gt;
Paul
&amp;lt;br&amp;gt;
&amp;lt;/blockquote&amp;gt;
&amp;lt;br&amp;gt;
&amp;lt;div class=3D3D3D"moz-signature"&amp;gt;-- &amp;lt;br&amp;gt;
&amp;lt;style type=3D3D3D"text/css"&amp;gt;
p { margin: 0; }
&amp;lt;/style&amp;gt;
&amp;lt;div style=3D3D3D"font-family: Arial; font-size: 10pt; color: rgb(=
0, 0, =3D
0);"&amp;gt;=3D3D
&amp;lt;font size=3D3D3D"1"&amp;gt; Diego Rivera&amp;lt;br&amp;gt;
Director / System Operations&amp;lt;br&amp;gt;
Roundbox Global : &amp;lt;span
style=3D3D3D"font-style: italic; color: rgb(102, 102, 102);"&amp;gt;ente=
rprise=3D
:
technology : genius&amp;lt;/span&amp;gt;&amp;lt;br&amp;gt;
-------------------------------------------------------------------------=
=3D
=3D3D
-----------------------------------------&amp;lt;br&amp;gt;
Avenida 11 y Calle 7-9, Barrio Am&amp;amp;oacute;n, San Jos&amp;amp;eacut=
e;, Cost=3D
a Rica&amp;lt;b=3D3D
r&amp;gt;
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506)
2258-3695&amp;lt;br&amp;gt;
email: &amp;lt;a href=3D3D3D&lt;a class=3D3D"moz-txt-link-rfc2396E" href=3D=
3D<a class=3D"moz-txt-link-rfc2396E" href=3D<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:d=3Diego.rivera@rbxgl=obal.com">"mailto:d=3Diego.rivera@rbxgl=
obal.com"</a>><a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:d=3Diego.rivera@rbxglobal.com">"mailto:d=3D
iego.rivera@rbxglobal.com"</a></a>&gt;<a class=3D"moz-txt-link-rfc2396E" href=
=3D<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:diego.rivera@rbxglobal.com">"mailto:diego.rivera@rbxglobal.com"</a>><a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:diego.rivera@rbxglobal.com=">"mailto:diego.rivera@rbxglobal.com=
"</a></a>&lt;/a&gt;&amp;gt;die=3D
go.rivera@rbxglob=3D3D
al.com&amp;lt;/a&amp;gt;
| &amp;lt;a href=3D3D3D&lt;a class=3D3D"moz-txt-link-rfc2396E" href=3D3D<=
a class=3D"moz-txt-link-rfc2396E" href=3D<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="http://www.rb=3Dxglobal.com">"http://www.rb=3Dxglobal.com"</a>>"h=
ttp://www.rb=3D
xglobal.com"</a>&gt;<a class=3D"moz-txt-link-rfc2396E" href=3D<a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://www==2Erbxglobal.com">"http://www=
=2Erbxglobal.com"</a>><a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a></a>&lt;/a&gt;&amp;gt;&lt;a c=
lass=3D3D"moz-txt-link-a=3D
bbreviated" href=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D<a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://ww=w.rbxglobal.com">"http://ww=
w.rbxglobal.com"</a>><a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a></a>&gt;<a class=3D"moz-txt-li=
nk-abbreviated" href=3D<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a>><a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="http://www.rbxglobal.com">www.rbxglobal.com</a></a>&l=
t;/a&gt;&amp;lt;/a=3D
&amp;gt;&amp;lt;br&amp;gt;
-------------------------------------------------------------------------=
=3D
=3D3D
-----------------------------------------&amp;lt;br&amp;gt;
&amp;lt;/font&amp;gt; &amp;lt;/div&amp;gt;
&amp;lt;/div&amp;gt;
&amp;lt;/body&amp;gt;
&amp;lt;/html&amp;gt;
--------------enigAA960B031FE487E074E8895C
Content-Type: application/pgp-signature; name=3D3D"signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=3D3D"signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - &lt;a class=3D3D"moz-txt-link-freetex=
t" hr=3D
ef=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D<a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://enigmail.mozdev.=org/">"http://enigmail.mozdev.=
org/"</a>><a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://enigmail.mozdev.org/">"http://enigmail.mozdev.org/"</a></a>&gt;<a class=3D"moz-txt-link-freet=
ext" href=3D<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://enigmail.mozdev.org/">"http://enigmail.mozdev.org/"</a>><a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://enigmail.mozdev.org/">http://enigmail.mozdev.org/</a></a>=
&lt;/a&gt;
iEYEARECAAYFAkrNHG4ACgkQCNJ6MS9YngWAMwCbBt8lUPHDUZ0guPfnCDf6ZLjH
/UwAni4UumFFXJ/U6iIuNtvzxnGCzjnZ
=3D3DYpwI
-----END PGP SIGNATURE-----
--------------enigAA960B031FE487E074E8895C--
&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;pre wrap=3D3D""&gt;&lt;!----&gt;
&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;br&gt;
&lt;div class=3D3D"moz-signature"&gt;-- &lt;br&gt;
&lt;style type=3D3D"text/css"&gt;
p { margin: 0; }
&lt;/style&gt;
&lt;div style=3D3D"font-family: Arial; font-size: 10pt; color: rgb(0, 0, =
0);"&gt;=3D
&lt;font size=3D3D"1"&gt; Diego Rivera&lt;br&gt;
Director / System Operations&lt;br&gt;
Roundbox Global : &lt;span
style=3D3D"font-style: italic; color: rgb(102, 102, 102);"&gt;enterprise=
:
technology : genius&lt;/span&gt;&lt;br&gt;
-------------------------------------------------------------------------=
=3D
-----------------------------------------&lt;br&gt;
Avenida 11 y Calle 7-9, Barrio Am&amp;oacute;n, San Jos&amp;eacute;, Cost=
a Rica&lt;b=3D
r&gt;
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506)
2258-3695&lt;br&gt;
email: &lt;a href=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D<a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:d=iego.rivera@rbxglobal.com">"mailto:d=
iego.rivera@rbxglobal.com"</a>><a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:diego.rivera@rbxglobal.com">"mailto:diego.rivera@rbxglobal.com"</a></a>&gt;die=
go.rivera@rbxglob=3D
al.com&lt;/a&gt;
| &lt;a href=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D<a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://www.rb=xglobal.com">"http://www.rb=
xglobal.com"</a>><a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a></a>&gt;<a class=3D"moz-txt-link-a=
bbreviated" href=3D<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a>><a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="http://www.rbxglobal.com">www.rbxglobal.com</a></a>&lt;/a=
&gt;&lt;br&gt;
-------------------------------------------------------------------------=
=3D
-----------------------------------------&lt;br&gt;
&lt;/font&gt; &lt;/div&gt;
&lt;/div&gt;
&lt;/body&gt;
&lt;/html&gt;
--------------enigCDF7F7110CFB1AEE0CAC1719
Content-Type: application/pgp-signature; name=3D"signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=3D"signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - <a class=3D"moz-txt-link-freetext" hr=
ef=3D<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://enigmail.mozdev.org/">"http://enigmail.mozdev.org/"</a>><a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://enigmail.mozdev.org/">http://enigmail.mozdev.org/</a></a>
iEYEARECAAYFAkrNL4gACgkQCNJ6MS9YngVUPACeImqX4x/AJHWC9BpEfseXgQ4I
1+wAmwYCJ4M11b5Ib/rU0MyvsphNxH/f
=3DpW+2
-----END PGP SIGNATURE-----
--------------enigCDF7F7110CFB1AEE0CAC1719--
</pre>
</blockquote>
<pre wrap=3D""><!---->
</pre>
</blockquote>
<br>
<div class=3D"moz-signature">-- <br>
<style type=3D"text/css">
p { margin: 0; }
</style>
<div style=3D"font-family: Arial; font-size: 10pt; color: rgb(0, 0, 0);">=
<font size=3D"1"> Diego Rivera<br>
Director / System Operations<br>
Roundbox Global : <span
style=3D"font-style: italic; color: rgb(102, 102, 102);">enterprise :
technology : genius</span><br>
-------------------------------------------------------------------------=
-----------------------------------------<br>
Avenida 11 y Calle 7-9, Barrio Am&oacute;n, San Jos&eacute;, Costa Rica<b=
r>
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506)
2258-3695<br>
email: <a href=3D<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:diego.rivera@rbxglobal.com">"mailto:diego.rivera@rbxglobal.com"</a>>diego.rivera@rbxglob=
al.com</a>
| <a href=3D<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a>><a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="http://www.rbxglobal.com">www.rbxglobal.com</a></a><br>
-------------------------------------------------------------------------=
-----------------------------------------<br>
</font> </div>
</div>
</body>
</html>
--------------enigE16CEB9A8D282663041FAE25
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - <a moz-do-not-send="true"
class="moz-txt-link-freetext" href="http://enigmail.mozdev.org/">http://enigmail.mozdev.org/</a>
iEYEARECAAYFAkrNNpEACgkQCNJ6MS9YngXxrgCfYxinvCMPQEPbBwi3NxraQtWM
IYgAnicZCF4QGaSCXoniyiH3OSf+Q7oA
=tC8j
-----END PGP SIGNATURE-----
--------------enigE16CEB9A8D282663041FAE25--
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<style type="text/css">
p { margin: 0; }
</style>
<div style="font-family: Arial; font-size: 10pt; color: rgb(0, 0, 0);"><font
size="1"> Diego Rivera<br>
Director / System Operations<br>
Roundbox Global : <span
style="font-style: italic; color: rgb(102, 102, 102);">enterprise :
technology : genius</span><br>
------------------------------------------------------------------------------------------------------------------<br>
Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica<br>
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506)
2258-3695<br>
email: <a moz-do-not-send="true"
href="mailto:diego.rivera@rbxglobal.com">diego.rivera@rbxglobal.com</a>
| <a moz-do-not-send="true" href="http://www.rbxglobal.com">www.rbxglobal.com</a><br>
------------------------------------------------------------------------------------------------------------------<br>
</font> </div>
</div>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Users@openswan.org">Users@openswan.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openswan.org/mailman/listinfo/users">http://lists.openswan.org/mailman/listinfo/users</a>
Building and Integrating Virtual Private Networks with Openswan:
<a class="moz-txt-link-freetext" href="http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155">http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155</a>
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<style type="text/css">
p { margin: 0; }
</style>
<div style="font-family: Arial; font-size: 10pt; color: rgb(0, 0, 0);">
<font size="1"> Diego Rivera<br>
Director / System Operations<br>
Roundbox Global : <span
style="font-style: italic; color: rgb(102, 102, 102);">enterprise :
technology : genius</span><br>
------------------------------------------------------------------------------------------------------------------<br>
Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica<br>
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506)
2258-3695<br>
email: <a href="mailto:diego.rivera@rbxglobal.com">diego.rivera@rbxglobal.com</a>
| <a href="http://www.rbxglobal.com">www.rbxglobal.com</a><br>
------------------------------------------------------------------------------------------------------------------<br>
</font> </div>
</div>
</body>
</html>