>   Excellent. Have you seen www.wavesec.org?

This is very similar to what I've been doing on my home network for a
couple of years.  There are some differences in the details, though:

1) I require the client certificates to be signed with my CA key, so
   that unauthorized clients can't set up a tunnel through my router.
   Additionally, I use a combination of ipf and IPsec SPDs to require
   that all traffic (except DHCP) be encrypted with IPsec.

2) As I've proposed before, to solve the DHCP client identifier
   namespace issue, I use identifiers of the form
   "machine/email-address" -- e.g. "hiroshima/root@ihack.net".

>   The DHCP server answers the request in the IPsec, but the client is
> listening only on the wire. It discards packets on port 67. The result is
> that it thinks the renewal didn't happen.
>   The problem is that getting two answers would be bad. I think that we
> should be able to cope with that and enable reading on the UDP socket.

A "correct" solution to this would seem to involve 4 components:

1) Add the ability to "tap and discard" to BPF, so we don't get
   duplicate packets on the UDP socket.  This would probably be useful
   for some other types of traffic as well.

2) Modify the BPF tap to only catch multicast/broadcast packets.

3) Enable reception through the UDP socket.

4) Make sure that replies go back out the same way they came in.

In principal this should not be difficult, but I didn't really want to
spend a lot of time hacking on the ISC code.