<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
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.<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. Thus, no DNS delay is seen.
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). 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.<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).
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.<br>
<br>
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.<br>
<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. Though to be honest
I haven't checked it in depth.<br>
<br>
Cheers.<br>
<br>
<br>
David McCullough wrote:
<blockquote cite="mid:20091008003323.GD11186@securecomputing.com"
type="cite">
<pre wrap="">Jivin Diego Rivera lays it down ...
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
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
</pre>
<blockquote type="cite">
<pre wrap="">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 class="moz-txt-link-abbreviated" href="mailto:diego.rivera@rbxglobal.com">diego.rivera@rbxglobal.com</a> | <a 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 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 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 class="moz-txt-link-rfc2396E" href="mailto:diego.rivera@rbxglobal.com">"mailto:diego.rivera@rbxglobal.com"</a> <a 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 class="moz-txt-link-rfc2396E" href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a> <a class="moz-txt-link-rfc2396E" href="http://www.rbxglobal.com"><http://www.rbxglobal.com></a> ><a 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 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 class="moz-txt-link-abbreviated" href="mailto:diego.rivera@rbxglobal.com">diego.rivera@rbxglobal.com</a> | <a 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="------------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 class="moz-txt-link-rfc2396E" href="mailto:mid:20091007231256.GA9796@securecomputing.com">"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 class="moz-txt-link-rfc2396E" href="mailto:diego.rivera@=rbxglobal.com">"mailto:diego.rivera@=
rbxglobal.com"</a>><a 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 class="moz-txt-link-rfc2396E" href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a>><a 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 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 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 class="moz-txt-link-rfc2396E" href="mailto:d=iego.rivera@rbxglobal.com">"mailto:d=
iego.rivera@rbxglobal.com"</a>><a 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 class="moz-txt-link-rfc2396E" href="http://www.rb=xglobal.com">"http://www.rb=
xglobal.com"</a>><a 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 class="moz-txt-link-rfc2396E" href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a>><a 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 class="moz-txt-link-rfc2396E" href="http://enigmail.mozdev.org/">"http://enigmail.mozdev.org/"</a>><a 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 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 class="moz-txt-link-rfc2396E" href="http://www.rbxglobal.com">"http://www.rbxglobal.com"</a>><a 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 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--
</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 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>