[Openswan Users] OpenSWAN, KLIPS, and dead tunnels
David McCullough
David_Mccullough at securecomputing.com
Wed Oct 7 21:01:53 EDT 2009
Jivin Diego Rivera lays it down ...
> 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.
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.
> 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.
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
> 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: diego.rivera at rbxglobal.com | www.rbxglobal.com
> ------------------------------------------------------------------------------------------------------------------
>
>
>
>
>
>
>
> 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? 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"mid:alpine.LFD.1.10.0910071852200.12140 at newtla.xelerance.com" <mailto:mid:alpine.LFD.1.10.0910071852200.12140 at newtla.xelerance.com> <mailto:mid:alpine.LFD.1.10.0910071852200.12140 at newtla.xelerance.com> <mailto:mid:alpine.LFD.1.10.0910071852200.12140 at newtla.xelerance.com>
> 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. 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ón, San José, Costa Rica<b=
> r>
> tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506)
> 2258-3695<br>
> email: <a href=3D"mailto:diego.rivera at rbxglobal.com" <mailto:diego.rivera at rbxglobal.com> <mailto:diego.rivera at rbxglobal.com> <mailto:diego.rivera at rbxglobal.com> >diego.rivera at rbxglob=
> al.com</a>
> | <a href=3D"http://www.rbxglobal.com" <http://www.rbxglobal.com> <http://www.rbxglobal.com> <http://www.rbxglobal.com> >www.rbxglobal.com</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 - http://enigmail.mozdev.org/
>
> 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: diego.rivera at rbxglobal.com | www.rbxglobal.com
> ------------------------------------------------------------------------------------------------------------------
>
>
>
>
>
>
>
> 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. 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.<br>
> <br>
> I'll try restart, though I don't expect there to be an improvement. =
>
> Hopefully, I'm wrong about that!<br>
> <br>
> Any tips?<br>
> <br>
> David McCullough wrote:
> <blockquote cite=3D"mid:20091007231256.GA9796 at securecomputing.com" <mailto:mid:20091007231256.GA9796 at securecomputing.com>
> 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 <IP> 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"mailto:diego.rivera@=
> rbxglobal.com" <mailto:diego.rivera@=rbxglobal.com> >diego.rivera at rbxglobal.com</a> | <a class=3D"moz-txt-link-=
> abbreviated" href=3D"http://www.rbxglobal.com" <http://www.rbxglobal.com> >www.rbxglobal.com</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
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
> <meta content=3D3D"text/html;charset=3D3DISO-8859-1" http-equiv=3D3D=
> "Content-=3D
> Type">
> </head>
> <body bgcolor=3D3D"#ffffff" text=3D3D"#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 w=
> hat =3D
> the
> potential source of the problem is?<br>
> <br>
> Cheers.<br>
> <br>
> Paul Wouters wrote:
> <blockquote
> cite=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:mid:alpine.LF=
> D.1.10.0910071852200.12140 at newtla.xelerance.com" <mailto:mid:alpine.LF=D.1.10.0910071852200.12140 at newtla.xelerance.com> >"mid:alpine.LFD.1.10.091=
> 0071852200.12140 at newtla.xelerance.com"</a>
> type=3D3D"cite">On Wed, 7 Oct 2009, Diego Rivera wrote:
> <br>
> <br>
> <blockquote type=3D3D"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 (si=
> nce
> 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=3D3D"moz-signature">-- <br>
> <style type=3D3D"text/css">
> p { margin: 0; }
> </style>
> <div style=3D3D"font-family: Arial; font-size: 10pt; color: rgb(0, 0, =
> 0);">=3D
>
> <font size=3D3D"1"> Diego Rivera<br>
> Director / System Operations<br>
> Roundbox Global : <span
> style=3D3D"font-style: italic; color: rgb(102, 102, 102);">enterprise=
> :
> technology : genius</span><br>
> -------------------------------------------------------------------------=
> =3D
> -----------------------------------------<br>
> Avenida 11 y Calle 7-9, Barrio Am&oacute;n, San Jos&eacute;, Cost=
> a Rica<b=3D
> r>
> tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506)
> 2258-3695<br>
> email: <a href=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:d=
> iego.rivera at rbxglobal.com" <mailto:d=iego.rivera at rbxglobal.com> >"mailto:diego.rivera at rbxglobal.com" <mailto:diego.rivera at rbxglobal.com> </a>>die=
> go.rivera at rbxglob=3D
> al.com</a>
> | <a href=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D"http://www.rb=
> xglobal.com" <http://www.rb=xglobal.com> >"http://www.rbxglobal.com" <http://www.rbxglobal.com> </a>><a class=3D"moz-txt-link-a=
> bbreviated" href=3D"http://www.rbxglobal.com" <http://www.rbxglobal.com> >www.rbxglobal.com</a></a=
> ><br>
> -------------------------------------------------------------------------=
> =3D
> -----------------------------------------<br>
> </font> </div>
> </div>
> </body>
> </html>
>
>
> --------------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"http://enigmail.mozdev.org/" <http://enigmail.mozdev.org/> >http://enigmail.mozdev.org/</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ón, San José, Costa Rica<b=
> r>
> tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506)
> 2258-3695<br>
> email: <a href=3D"mailto:diego.rivera at rbxglobal.com" <mailto:diego.rivera at rbxglobal.com> >diego.rivera at rbxglob=
> al.com</a>
> | <a href=3D"http://www.rbxglobal.com" <http://www.rbxglobal.com> >www.rbxglobal.com</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 - http://enigmail.mozdev.org/
>
> 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: diego.rivera at rbxglobal.com | www.rbxglobal.com
> ------------------------------------------------------------------------------------------------------------------
>
>
> 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. The DNS's tal=
> k
> 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 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. 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 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). 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 hone=
> st
> I haven't checked it in depth.<br>
> <br>
> Cheers.<br>
> <br>
> <br>
> David McCullough wrote:
> <blockquote cite=3D"mid:20091008003323.GD11186 at securecomputing.com"
> 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 <IP> 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"mailto:diego.river=
> a at rbxglobal.com">diego.rivera at rbxglobal.com</a> | <a class=3D"moz-txt-lin=
> k-abbreviated" href=3D"http://www.rbxglobal.com">www.rbxglobal.com</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
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
> <meta content=3D3D"text/html;charset=3D3DISO-8859-1" http-equiv=3D=
> 3D"Content-=3D
> Type">
> </head>
> <body bgcolor=3D3D"#ffffff" text=3D3D"#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 =3D
> the
> potential source of the problem is?<br>
> <br>
> Cheers.<br>
> <br>
> Paul Wouters wrote:
> <blockquote
> cite=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:mid:alpine.=
> LFD.1.10.0910071852200.12140 at newtla.xelerance.com">"mid:alpine.LFD.1.10.0=
> 910071852200.12140 at newtla.xelerance.com"</a> <a class=3D"moz-txt-link-rfc=
> 2396E" href=3D"mailto:mid:alpine.LFD.1.10.0910071852200.12140 at newtla.xele=
> rance.com"><mailto:mid:alpine.LFD.1.10.0910071852200.12140 at newtla.xele=
> rance.com></a>=20
> type=3D3D"cite">On Wed, 7 Oct 2009, Diego Rivera wrote:
> <br>
> <br>
> <blockquote type=3D3D"cite">I was using restart_by_peer but fro=
> m 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=3D3D"moz-signature">-- <br>
> <style type=3D3D"text/css">
> p { margin: 0; }
> </style>
> <div style=3D3D"font-family: Arial; font-size: 10pt; color: rgb(0, 0=
> , 0);">=3D
> =09
> <font size=3D3D"1"> Diego Rivera<br>
> Director / System Operations<br>
> Roundbox Global : <span
> style=3D3D"font-style: italic; color: rgb(102, 102, 102);">enterpri=
> se :
> technology : genius</span><br>
> -----------------------------------------------------------------------=
> --=3D
> -----------------------------------------<br>
> Avenida 11 y Calle 7-9, Barrio Am&oacute;n, San Jos&eacute;, Co=
> sta Rica<b=3D
> r>
> tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506)
> 2258-3695<br>
> email: <a href=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D"mailto=
> :diego.rivera at rbxglobal.com">"mailto:diego.rivera at rbxglobal.com"</a> <a c=
> lass=3D"moz-txt-link-rfc2396E" href=3D"mailto:diego.rivera at rbxglobal.com"=
> ><mailto:diego.rivera at rbxglobal.com></a> >diego.rivera at rbxglob=3D=
>
> al.com</a>
> | <a href=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D"http://www.=
> rbxglobal.com">"http://www.rbxglobal.com"</a> <a class=3D"moz-txt-link-rf=
> c2396E" href=3D"http://www.rbxglobal.com"><http://www.rbxglobal.com>=
> ;</a> ><a class=3D"moz-txt-link-abbreviated" href=3D"http://www.rbxglo=
> bal.com">www.rbxglobal.com</a></a><br>
> -----------------------------------------------------------------------=
> --=3D
> -----------------------------------------<br>
> </font> </div>
> </div>
> </body>
> </html>
> =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"http://enigmail.mozdev.org/">http://enigmail.mozdev.org/</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"mailto:diego.rivera@=
> rbxglobal.com">diego.rivera at rbxglobal.com</a> | <a class=3D"moz-txt-link-=
> abbreviated" href=3D"http://www.rbxglobal.com">www.rbxglobal.com</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
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
> <meta content=3D3D"text/html;charset=3D3DISO-8859-1" http-equiv=3D3D=
> "Content-=3D
> Type">
> </head>
> <body bgcolor=3D3D"#ffffff" text=3D3D"#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; 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.<br>
> <br>
> I'll try restart, though I don't expect there to be an improvement.&n=
> bsp;=3D
>
> Hopefully, I'm wrong about that!<br>
> <br>
> Any tips?<br>
> <br>
> David McCullough wrote:
> <blockquote cite=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D"mailto=
> :mid:20091007231256.GA9796 at securecomputing.com">"mid:20091007231256.GA979=
> 6 at securecomputing.com"</a>
> type=3D3D"cite">
> <pre wrap=3D3D"">Jivin Diego Rivera lays it down ...
> </pre>
> <blockquote type=3D3D"cite">
> <pre wrap=3D3D"">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?
> </pre>
> </blockquote>
> <pre wrap=3D3D""><!---->
> 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 &lt;IP&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]
>
>
> </pre>
> <blockquote type=3D3D"cite">
> <pre wrap=3D3D"">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: <a class=3D3D"moz-txt-link-abbreviated" href=3D3D<a class=3D"mo=
> z-txt-link-rfc2396E" href=3D"mailto:diego.rivera@=3Drbxglobal.com">"mailt=
> o:diego.rivera@=3D
> rbxglobal.com"</a>><a class=3D"moz-txt-link-abbreviated" href=3D"mailt=
> o:diego.rivera at rbxglobal.com">diego.rivera at rbxglobal.com</a></a> | =
> <a class=3D3D"moz-txt-link-=3D
> abbreviated" href=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D"http://w=
> ww.rbxglobal.com">"http://www.rbxglobal.com"</a>><a class=3D"moz-txt-l=
> ink-abbreviated" href=3D"http://www.rbxglobal.com">www.rbxglobal.com</a>&=
> lt;/a>
> -------------------------------------------------------------------------=
> =3D
> -----------------------------------------
>
>
> </pre>
> </blockquote>
> <pre wrap=3D3D""><!---->
> </pre>
> <blockquote type=3D3D"cite">
> <pre wrap=3D3D"">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
>
> &lt;!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"&=
> ;gt;
> &lt;html&gt;
> &lt;head&gt;
> &lt;meta content=3D3D3D"text/html;charset=3D3D3DISO-8859-1" http-eq=
> uiv=3D3D3D=3D
> "Content-=3D3D
> Type"&gt;
> &lt;/head&gt;
> &lt;body bgcolor=3D3D3D"#ffffff" text=3D3D3D"#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 in=
> to w=3D
> hat =3D3D
> 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=3D3D3D<a class=3D3D"moz-txt-link-rfc2396E" href=3D3D<a class=3D"=
> moz-txt-link-rfc2396E" href=3D"mailto:mid:alpine.LF=3DD.1.10.091007185220=
> 0.12140 at newtla.xelerance.com">"mailto:mid:alpine.LF=3D
> D.1.10.0910071852200.12140 at newtla.xelerance.com"</a>>"mid:alpine.LFD.1=
> =2E10.091=3D
> <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:0071852200.12140 at new=
> tla.xelerance.com">0071852200.12140 at newtla.xelerance.com</a>"</a>
> type=3D3D3D"cite"&gt;On Wed, 7 Oct 2009, Diego Rivera wrote:
> &lt;br&gt;
> &lt;br&gt;
> &lt;blockquote type=3D3D3D"cite"&gt;I was using restart_by_peer=
> but from =3D
> 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=3D
> 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=3D3D3D"moz-signature"&gt;-- &lt;br&gt;
> &lt;style type=3D3D3D"text/css"&gt;
> p { margin: 0; }
> &lt;/style&gt;
> &lt;div style=3D3D3D"font-family: Arial; font-size: 10pt; color: rgb(=
> 0, 0, =3D
> 0);"&gt;=3D3D
>
> &lt;font size=3D3D3D"1"&gt; Diego Rivera&lt;br&gt;
> Director / System Operations&lt;br&gt;
> Roundbox Global : &lt;span
> style=3D3D3D"font-style: italic; color: rgb(102, 102, 102);"&gt;ente=
> rprise=3D
> :
> technology : genius&lt;/span&gt;&lt;br&gt;
> -------------------------------------------------------------------------=
> =3D
> =3D3D
> -----------------------------------------&lt;br&gt;
> Avenida 11 y Calle 7-9, Barrio Am&amp;oacute;n, San Jos&amp;eacut=
> e;, Cost=3D
> a Rica&lt;b=3D3D
> r&gt;
> tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506)
> 2258-3695&lt;br&gt;
> email: &lt;a href=3D3D3D<a class=3D3D"moz-txt-link-rfc2396E" href=3D=
> 3D<a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:d=3Diego.rivera at rbxgl=
> obal.com">"mailto:d=3D
> iego.rivera at rbxglobal.com"</a>><a class=3D"moz-txt-link-rfc2396E" href=
> =3D"mailto:diego.rivera at rbxglobal.com">"mailto:diego.rivera at rbxglobal.com=
> "</a></a>&gt;die=3D
> go.rivera at rbxglob=3D3D
> al.com&lt;/a&gt;
> | &lt;a href=3D3D3D<a class=3D3D"moz-txt-link-rfc2396E" href=3D3D<=
> a class=3D"moz-txt-link-rfc2396E" href=3D"http://www.rb=3Dxglobal.com">"h=
> ttp://www.rb=3D
> xglobal.com"</a>><a class=3D"moz-txt-link-rfc2396E" href=3D"http://www=
> =2Erbxglobal.com">"http://www.rbxglobal.com"</a></a>&gt;<a c=
> lass=3D3D"moz-txt-link-a=3D
> bbreviated" href=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D"http://ww=
> w.rbxglobal.com">"http://www.rbxglobal.com"</a>><a class=3D"moz-txt-li=
> nk-abbreviated" href=3D"http://www.rbxglobal.com">www.rbxglobal.com</a>&l=
> t;/a>&lt;/a=3D
> &gt;&lt;br&gt;
> -------------------------------------------------------------------------=
> =3D
> =3D3D
> -----------------------------------------&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=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 - <a class=3D3D"moz-txt-link-freetex=
> t" hr=3D
> ef=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D"http://enigmail.mozdev.=
> org/">"http://enigmail.mozdev.org/"</a>><a class=3D"moz-txt-link-freet=
> ext" href=3D"http://enigmail.mozdev.org/">http://enigmail.mozdev.org/</a>=
> </a>
>
> iEYEARECAAYFAkrNHG4ACgkQCNJ6MS9YngWAMwCbBt8lUPHDUZ0guPfnCDf6ZLjH
> /UwAni4UumFFXJ/U6iIuNtvzxnGCzjnZ
> =3D3DYpwI
> -----END PGP SIGNATURE-----
>
> --------------enigAA960B031FE487E074E8895C--
> </pre>
> </blockquote>
> <pre wrap=3D3D""><!---->
>
> </pre>
> </blockquote>
> <br>
> <div class=3D3D"moz-signature">-- <br>
> <style type=3D3D"text/css">
> p { margin: 0; }
> </style>
> <div style=3D3D"font-family: Arial; font-size: 10pt; color: rgb(0, 0, =
> 0);">=3D
>
> <font size=3D3D"1"> Diego Rivera<br>
> Director / System Operations<br>
> Roundbox Global : <span
> style=3D3D"font-style: italic; color: rgb(102, 102, 102);">enterprise=
> :
> technology : genius</span><br>
> -------------------------------------------------------------------------=
> =3D
> -----------------------------------------<br>
> Avenida 11 y Calle 7-9, Barrio Am&oacute;n, San Jos&eacute;, Cost=
> a Rica<b=3D
> r>
> tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506)
> 2258-3695<br>
> email: <a href=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:d=
> iego.rivera at rbxglobal.com">"mailto:diego.rivera at rbxglobal.com"</a>>die=
> go.rivera at rbxglob=3D
> al.com</a>
> | <a href=3D3D<a class=3D"moz-txt-link-rfc2396E" href=3D"http://www.rb=
> xglobal.com">"http://www.rbxglobal.com"</a>><a class=3D"moz-txt-link-a=
> bbreviated" href=3D"http://www.rbxglobal.com">www.rbxglobal.com</a></a=
> ><br>
> -------------------------------------------------------------------------=
> =3D
> -----------------------------------------<br>
> </font> </div>
> </div>
> </body>
> </html>
>
>
> --------------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"http://enigmail.mozdev.org/">http://enigmail.mozdev.org/</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ón, San José, Costa Rica<b=
> r>
> tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506)
> 2258-3695<br>
> email: <a href=3D"mailto:diego.rivera at rbxglobal.com">diego.rivera at rbxglob=
> al.com</a>
> | <a href=3D"http://www.rbxglobal.com">www.rbxglobal.com</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 - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkrNNpEACgkQCNJ6MS9YngXxrgCfYxinvCMPQEPbBwi3NxraQtWM
> IYgAnicZCF4QGaSCXoniyiH3OSf+Q7oA
> =tC8j
> -----END PGP SIGNATURE-----
>
> --------------enigE16CEB9A8D282663041FAE25--
--
David McCullough, david_mccullough at securecomputing.com, Ph:+61 734352815
McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org
More information about the Users
mailing list