Subject: Re: dhclient and IPsec
To: Michael Richardson <>
From: Bill Sommerfeld <>
List: tech-net
Date: 02/22/2002 19:42:07
[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

>   We make a SA like:
> spdadd $myip/32 any -P out ipsec esp/tunnel/${myip}-${gateway}/require;
> spdadd $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)

>   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

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