<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
More comments below...<br>
<br>
Paul Wouters wrote:
<blockquote
 cite="mid:alpine.LFD.1.10.0908091606270.18844@newtla.xelerance.com"
 type="cite">On Sun, 9 Aug 2009, Diego Rivera wrote:
  <br>
  <br>
  <blockquote type="cite">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Out of curiosity, what were those bugs?
    <br>
  </blockquote>
  <br>
thanks for listing those.
  <br>
</blockquote>
There were several others - but those were the two big ones.&nbsp; The
static policies basically meant that if any of my firewalls went down,
the other two would continue to forward traffic but would essentially
be inaccessible because of the way they were configured to inter-depend
over the tunnels when available.&nbsp; Since I couldn't get rid of that
inter-dependency without losing significant functionality, it became a
matter of finding a way to establish policies dynamically as the phase1
tunnels were brought up.<br>
<br>
I did just that - added scripts to add the policies.&nbsp; However, since I
now had to bring the tunnel up manually, it presented a slew of
problems not the least of which was&nbsp; how to reliably detect that the
tunnel had been taken down so it could be brought back up.&nbsp; Essentially
I would have had to write a watchdog daemon to patrol the tunnels and
bring up whichever one hadn't been explicitly torn down...etc..etc...<br>
<br>
Too much work, too little reward.&nbsp; So I started playing with OpenSWAN
and everything worked fairly quickly.&nbsp; Had to take some time to figure
out how to avoid some smaller pitfalls but nothing too bad.&nbsp; The XAUTH
deployment is the last one.<br>
<blockquote
 cite="mid:alpine.LFD.1.10.0908091606270.18844@newtla.xelerance.com"
 type="cite"><br>
  <blockquote type="cite">I know that's how you enable it so I guess a
better question is: when I
    <br>
don't specify "authby=secret", will it automagically use PAM?&nbsp; That's
    <br>
more or less what I was asking.
    <br>
  </blockquote>
  <br>
No. Authby=secret means "Use Preshared Key" for IPsec. Or in Cisco
speak,
  <br>
that is the "Group Secret". It has nothing to do with the user
authentication,
  <br>
it is only the IPsec host identification.
  <br>
  <br>
XAUTH (a.k.a phase 1.5) uses a username plus password in addition to
the
  <br>
above secret. That's where pam comes into play. A safer method would be
  <br>
to not use a group secret, but X.509 certificates. XAUTH would still be
  <br>
used on top of that for user/password authentication.
  <br>
  <br>
</blockquote>
Yes - I knew what XAUTH was I just wasn't sure if PAM would
automatically be used as the authentication means or how to specify
that it would be used.&nbsp; The reason I ask is because I also see that
it's possible to create an htpasswd-type file with usernames and
passwords in it - but no documentation on how to specify which of the
two methods to use (or if they can be combined in the same deployment,
for instance, for two different endpoints).<br>
<br>
Interesting that you should mention the X.509 certificates - we used
exactly that with Racoon, and no group secret (or rather, the group
secret was ignored).&nbsp; I've drafted a tunnel configuration for this but
I can't seem to get it to come up - keeps complaining about "address
family inconsistency in this client connection".&nbsp; I'm sure it's just me
being too dumb again:<br>
<br>
----- BEGIN XAUTH CONF -----<br>
conn rbx-ras<br>
&nbsp;&nbsp;&nbsp; authby=secret<br>
&nbsp;&nbsp;&nbsp; leftid=%fromcert<br>
&nbsp;&nbsp;&nbsp; leftcert=/etc/openswan/ras.crt<br>
&nbsp;&nbsp;&nbsp; left=&lt;my-public-ip&gt;<br>
&nbsp;&nbsp;&nbsp; leftnexthop=%defaultroute<br>
&nbsp;&nbsp;&nbsp; leftsourceip=&lt;my-private-ip&gt;<br>
&nbsp;&nbsp;&nbsp; leftsubnets={&lt;all-the-private-subnets&gt;}<br>
&nbsp;&nbsp;&nbsp; leftxauthserver=yes<br>
&nbsp;&nbsp;&nbsp; leftmodecfgserver=yes<br>
&nbsp;&nbsp;&nbsp; right=%any<br>
&nbsp;&nbsp;&nbsp; rightnexthop=%defaultroute<br>
&nbsp;&nbsp;&nbsp; rightid=@RAS<br>
&nbsp;&nbsp;&nbsp; rightxauthclient=yes<br>
&nbsp;&nbsp;&nbsp; rightmodecfgclient=yes<br>
&nbsp;&nbsp;&nbsp; dpdaction=restart_by_peer<br>
&nbsp;&nbsp;&nbsp; dpddelay=30<br>
&nbsp;&nbsp;&nbsp; dpdtimeout=60<br>
&nbsp;&nbsp;&nbsp; pfs=yes<br>
&nbsp;&nbsp;&nbsp; ike=3des-md5-modp1024<br>
&nbsp;&nbsp;&nbsp; esp=3des-md5-modp1024<br>
&nbsp;&nbsp;&nbsp; aggrmode=yes<br>
&nbsp;&nbsp;&nbsp; salifetime=15m<br>
&nbsp;&nbsp;&nbsp; ikelifetime=1h<br>
&nbsp;&nbsp;&nbsp; rekeymargin=2m<br>
&nbsp;&nbsp;&nbsp; rekey=no<br>
&nbsp;&nbsp;&nbsp; auto=add<br>
------ END XAUTH CONF ------<br>
<br>
Can you offer any pointers as to where I might be going wrong here?<br>
<blockquote
 cite="mid:alpine.LFD.1.10.0908091606270.18844@newtla.xelerance.com"
 type="cite">
  <blockquote type="cite">Also - would you happen to know how to tell
pluto to *NOT* listen on all
    <br>
interfaces/addresses?&nbsp; I have multiple interfaces on those boxes, some
of
    <br>
those with multiple IP's - yet I only want pluto to listen on a
couple.&nbsp;
    <br>
I can't seem to find clear documentation of how to achieve this.
    <br>
  </blockquote>
  <br>
There is currently no method for that. You cannot really mix IKE
daemons,
  <br>
on a single host. I'd recommend using some firewall rules if you are
  <br>
really concerned about listening to certain addresses.
  <br>
  <br>
Paul
  <br>
</blockquote>
I already have just such rules in place - I'm just somewhat
anal-rententive that way :)&nbsp; I like to be able to fully control
everything I deploy so I don't inadvertently leave something hanging
where it shouldn't.&nbsp; It's a shame that hasn't been done in such a
mature daemon... maybe a configuration such as
"listenaddress={aaa.bbb.ccc.ddd:500 eee.fff.ggg.hhh:500}" ... ?<br>
<br>
Thanks!<br>
<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&oacute;n, San Jos&eacute;, 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>