[Openswan Users] OpenSWAN, KLIPS, and dead tunnels
David McCullough
David_Mccullough at securecomputing.com
Wed Oct 7 18:09:02 EDT 2009
Jivin Diego Rivera lays it down ...
> I'm running openswan 2.6.22. So which of the dpdaction options should I use?
>
> * clear?
> * restart?
> * restart_by_peer?
> * hold?
>
> I want whichever one will cause a peer to tear down its KLIPS policies and actively seek out the other peer(s) to re-establish the connection regardless of where the fault occurred. Does any of those options do that? From the docs, it smells like restart is a subset of restart_by_peer (hence why I chose the latter). If not, then perhaps the docs should be clarified in this regard.
You should be using restart or restart_by_peer.
I suspect that you may be hitting one of the numerous problems that were
fixed between 2.6.22 and 2.6.23 with tunnel states/DPD and so on.
Is it possible to try 2.6.23 ?
Cheers,
Davidm
> David McCullough wrote:
>
> Jivin Paul Wouters lays it down ...
>
>
> On Wed, 7 Oct 2009, Diego Rivera wrote:
>
>
>
> However, if the tunnel is up and one of the nodes disappears - due to an
> outage, machine crash, whatever - then I have a problem that I can't
> really find a solution for: the tunnel is dead, but the KLIPS policies
> still remain in place.
>
>
> And it prevents plaintext packets from accidentally lekaing out.
>
>
>
> The only solution is to manually jump into the box and restart the IPSec
> service, forcing the policies to be taken down, to be re-added when the
> tunnel is back up. This is manageable, but less than ideal.
>
> My perception of how this should really function is that when the peer
> is found to be down (we do have DPD configured on both ends so this
>
>
> DPD should do the trick.
>
>
>
> However, this isn't happening and I'm not sure if it's due to
> misconfiguration (perhaps I should use dpdaction=clear instead of
> restart_by_peer?), or due to a software defect in OpenSWAN. Any
>
>
> restart_by_peer means the equivalent of auto=add. You wait on the other
> end to connect. Which should work if your other end would be using DPD,
> but if both ends use restart_by_peer, neither end will restart the
> connectin.
>
>
>
> That wasn't my impression. It should basically be the same as restart,
> except that all tunnels to the same peer will be taken down at the same time
> to be restarted. I am fairly sure there is an "initiate" call in the code
> path for when this happens. If it doesn't do this I am in trouble :-)
>
> Which version of openswan are you running ?
>
> Cheers,
> Davidm
>
>
>
>
> --
>
> 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="------------enig62BE6CFAAA1AFA424E316B63"
>
> --------------enig62BE6CFAAA1AFA424E316B63
> 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">
> I'm running openswan 2.6.22. So which of the dpdaction options shou=
> ld
> I use?<br>
> <ul>
> <li>clear?</li>
> <li>restart?</li>
> <li>restart_by_peer?</li>
> <li>hold?</li>
> </ul>
> I want whichever one will cause a peer to tear down its KLIPS policies
> and actively seek out the other peer(s) to re-establish the connection
> regardless of where the fault occurred. Does any of those options d=
> o
> that? From the docs, it smells like restart is a subset of
> restart_by_peer (hence why I chose the latter). If not, then perhap=
> s
> the docs should be clarified in this regard.<br>
> <br>
> At any rate, any suggestions, Paul?<br>
> <br>
> Cheers.<br>
> <br>
> <br>
> David McCullough wrote:
> <blockquote cite=3D"mid:20091007212933.GA4584 at securecomputing.com"
> type=3D"cite">
> <pre wrap=3D"">Jivin Paul Wouters lays it down ...
> </pre>
> <blockquote type=3D"cite">
> <pre wrap=3D"">On Wed, 7 Oct 2009, Diego Rivera wrote:
>
> </pre>
> <blockquote type=3D"cite">
> <pre wrap=3D"">However, if the tunnel is up and one of the nodes di=
> sappears - due to an
> outage, machine crash, whatever - then I have a problem that I can't
> really find a solution for: the tunnel is dead, but the KLIPS policies
> still remain in place.
> </pre>
> </blockquote>
> <pre wrap=3D"">And it prevents plaintext packets from accidentally le=
> kaing out.
>
> </pre>
> <blockquote type=3D"cite">
> <pre wrap=3D"">The only solution is to manually jump into the box a=
> nd restart the IPSec
> service, forcing the policies to be taken down, to be re-added when the
> tunnel is back up. This is manageable, but less than ideal.
>
> My perception of how this should really function is that when the peer
> is found to be down (we do have DPD configured on both ends so this
> </pre>
> </blockquote>
> <pre wrap=3D"">DPD should do the trick.
>
> </pre>
> <blockquote type=3D"cite">
> <pre wrap=3D"">However, this isn't happening and I'm not sure if it=
> 's due to
> misconfiguration (perhaps I should use dpdaction=3Dclear instead of
> restart_by_peer?), or due to a software defect in OpenSWAN. Any
> </pre>
> </blockquote>
> <pre wrap=3D"">restart_by_peer means the equivalent of auto=3Dadd. Yo=
> u wait on the other
> end to connect. Which should work if your other end would be using DPD,
> but if both ends use restart_by_peer, neither end will restart the
> connectin.
> </pre>
> </blockquote>
> <pre wrap=3D""><!---->
> That wasn't my impression. It should basically be the same as restart,
> except that all tunnels to the same peer will be taken down at the same t=
> ime
> to be restarted. I am fairly sure there is an "initiate" call in the cod=
> e
> path for when this happens. If it doesn't do this I am in trouble :-)
>
> Which version of openswan are you running ?
>
> Cheers,
> Davidm
>
> </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>
>
>
> --------------enig62BE6CFAAA1AFA424E316B63
> 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/
>
> iEYEARECAAYFAkrNCg4ACgkQCNJ6MS9YngXMbwCfePL4IpxT6iHsrKlwiwLM3W3T
> YlsAn295ZPz14Dn98tOkwQctlmYob2q6
> =uhKc
> -----END PGP SIGNATURE-----
>
> --------------enig62BE6CFAAA1AFA424E316B63--
--
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