Subject: Re: dhclient and IPsec
To: Bill Sommerfeld <email@example.com>
From: Thor Lancelot Simon <firstname.lastname@example.org>
Date: 02/25/2002 09:12:39
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 email@example.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