One suggestion: DO NOT run NAT on the box you use as IPsec tunnel
	gateway.  It is almost impossible to configure them on the same box.
	Reasons are: they implement conflicting functionality (IPsec policy
	is very similar to packet filter), packet filters do not really 
	handle tunnelled packet well, and they are specwise conflicting
	each other. 

>- I have a gifN route set up for the tunnel traffic (which may or may
>not be important now).  The IPsec FAQ at www.netbsd.org doesn't mention
>a gif0 interface, but does demand some static routes.  I've tried it
>both ways and don't see any traffic moving between.

	When we say "IPsec tunnel", normally it means tunnel encapsulation
	described in RFC2401.  If you configure IPsec tunnel policy as
	described in IPsec FAQ (VPN section), the packet look like this:
		IP1 ESP IP2 payload

	gif implements IPv[46] over IPv[46] tunnel based on RFC1933 (2893).
	After gif encapsulation, packet looks like this:
		IP1 IP2 payload
	If you add transport mode IPsec onto IP1 it will look like this:
	(as Michael Richardson's reply suggests)
		IP1 ESP IP2 payload

	However: since gif and IPsec tunnel implement different encapsulation
	from each other, use of gif can cause interoperability problem,
	especially if the other end is non-NetBSD box.  It is documented in
	gif(4) manpage, at the bottom.
	This is the reason why we do not mention gif in IPsec FAQ.  There's no
	guarantee the lastter configuration interoperate with other IPsec
	devices, including NetBSD boxes (we don't guarantee it).  The latter
	configuration is "If you know what you are doing it's fine go ahead
	use gif, don't blame me even if it does not interoperate" kind of thing.

	(From specification POV, I still don't really like the fact that IPsec
	defines tunnel encapsulation method.  IPsec can separately be defined
	from tunnelling, and there are dozens of tunnelling specifications
	already.  But anyway, specifications are specifications, we need to
	follow them)

itojun