[Openswan Users] OpenSWAN, KLIPS, and dead tunnels
David McCullough
David_Mccullough at securecomputing.com
Wed Oct 7 20:33:23 EDT 2009
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>
> 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> >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>
>
>
> --------------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"
> 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">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"------------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">"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: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>
>
>
> --------------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/</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">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>
>
>
> --------------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--
--
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