On Fri, 9 Nov 2001, Ken Raeburn wrote:

> I'd like to use IPsec for at least some of the tunnels I'm using at
> home, but haven't managed to figure out how to get it working yet.
>
> All the stuff I've found on NetBSD so far (I'm running 1.5X plus some
> newer stuff from pkgsrc) seems to always lead to a point saying
> either, "here's where you store your pre-shared secret key", or
> "here's where you put your certificate info".  For the most important
> tunnel I want to protect, what I've got is an ID string, an RSA public
> key, and a DNS "auth-only host-level IPsec RSA" KEY RR (not actually
> in DNS, but published via a web page) for the FreeS/WAN server, and
> the ability to tell it the corresponding values for my system; no
> secret keys, and no certificates, but AFAICT it should be enough for
> key negotiation.  But if those fit into the NetBSD configuration
> schemes, I haven't figured out how.  (It doesn't help that most of the
> docs seem to assume you already understand how IPsec configuration
> works and just need to know where to stick the values.)

You should look specifically at racoon and isakmpd. I prefer racoon, but
these are the two programs (in pkgsrc) that handle key negotiation. I
*think* they can add and remove policies too.

> My local address is assigned via DHCP by my ISP, so I should avoid
> hard-coding it if practical, and use a "road warrior" type
> configuration, but for a subnet, not a single node.  In fact, the
> driving reason for my wanting to use IPsec has less to do with actual
> privacy than with the remote end not needing a fixed address for my
> home system if I use IPsec.  (That and wanting to start learning about
> IPsec.)
>
>
> The next problem is, this tunnel endpoint machine is also my firewall
> (using ipf) and NAT box (for those "internal" machines using net-10
> addresses, which is not all of them).  Yes, I've read about the
> problems with mixing IPF and IPsec.  It looks to me like the security
> policy stuff is probably flexible enough to do many of the things I do
> through ipf.conf, though not all (e.g., logging), but I don't see any
> way to do NAT.  And I'm assuming that packets not going in or out
> using IPsec will still be processed by the regular ipf/ipnat code.  If
> not, IPsec is definitely lower priority than firewall/NAT, so I could
> just give up on it right now.

I've had no problem with NAT and IPSec. But then I've used a different
form of tunneling. My setup has gif (IP in IP) tunnels on each end, and
ESP/transport mode policy set up between each end.

Then the routing table sends inside-net traffic going to the other part of
the VPN out over the gif interface. So normal (should be NATed) and VPN
(should not be NATed) traffic goes out different interfaces.

The packets end up being assembled like ESP/tunnel ones, but the policies
are just a little different so that things work easily.

Take care,

Bill