[Disclaimer: my day job involves work on Solaris's IPsec
implementation.  To avoid conflict of interest/tainting issues, this
means I'm not all that familiar with either KAME/*BSD or freeswan's
IPsec.]

>   We make a SA like:
> 
> spdadd $myip/32 0.0.0.0/0 any -P out ipsec esp/tunnel/${myip}-${gateway}/require;
> spdadd 0.0.0.0/0 $myip/32 any -P in ipsec  esp/tunnel/${gateway}-${myip}/require;

That doesn't look like an SA, that looks like a pair of SPD (policy)
entries.

>   No problems there. All packets are encrypted to his gateway across the 
> wireless LAN. Sure beats WEP.
> 
>   The problem is DHCP lease renewals.

So, one of our (Sun IPsec) test cases is ever-so-vaguely similar
(remote access to Sun's network using IPsec, tunnelling more-or-less
all traffic); 

The difference vs your environmen is that the dhcp server and tunnel
endpoint are on different systems (dhcp server is run by whichever
network we're visiting; tunnel server is remote and run by us).  So,
rather than trying to convince the nets we visit to turn on ipsec on
their dhcp server, we create a bypass policy entry on the client --
the dhcp traffic necessary to keep us up on the local LAN is sent in
the clear.  (this also avoids chicken-and-egg issues since you need an
ip address to negotiate an SA using the key management protocol of
your choice).

> Is dhclient looking for a reply only via BPF?  Examining the source
> code does not suggest this, but I'm not certain.

The output messages from the dhclient in NetBSD-current certainly
suggest that this is the case:

# dhclient fxp0
Internet Software Consortium DHCP Client V3.0rc10
Copyright 1995-2001 Internet Software Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP

Listening on BPF/fxp0/08:00:46:18:04:cf
Sending on   BPF/fxp0/08:00:46:18:04:cf
Sending on   Socket/fallback

					- Bill