On Fri, Feb 22, 2002 at 07:42:07PM -0500, Bill Sommerfeld wrote:
> 
> 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).

This is a nice idea, but at least the 1.91 FreeS/WAN code I'm
familiar with doesn't really have a configurable policy database at
all; if you want a per-port bypass rule you'll need to UTSL.

> > 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:

I think this may be the case.  dhclient configured this way is a real
lose in an IPsec environment; it sees the encrypted responses instead of
the decrypted ones.

-- 
 Thor Lancelot Simon	                                      tls@rek.tjls.com
   But as he knew no bad language, he had called him all the names of common
 objects that he could think of, and had screamed: "You lamp!  You towel!  You
 plate!" and so on.              --Sigmund Freud