Problems with destination IP of DHCP Offer Packages

[David W. Hankins]

On Sat, Jul 11, 2009 at 05:59:41PM +0200, Martin Krellmann wrote:
> "10.0.1.0/24". The ipsec server adds an route to the destination
> 255.255.255.255 on interface "ipsec0" so broadcast packages should be
> transmitted over the tunnel. The problem is that the dhcp server does not
> broadcast the offers but sends them to the IP that should be assigned to the
> client. So the package will never be routed over the ipsec tunnel and the
> client gets no ip address.
> 
> Is this a configuration problem or is this a default behavior?

The DHCP server uses raw sockets for DHCPOFFER transmissions (in your
case, "LPF").  So it is transmitted on the raw socket that the
DHCPDISCOVER was received upon.  Routing should not enter into it, or
if it does, then your kernel is severely broken, which would be
improbable.  Even on BSD sockets, we use some fcntl tricks to send the
packet on a specific interface, bypassing routing, depending on OS.

The unicast behaviour is specified in RFC 2131 as the correct
behaviour.  If the client's BROADCAST flag is cleared in the BOOTP
flags header field, then the DHCPOFFER is unicast to the yiaddr:chaddr
IP:LL addresses without ARPing, routing, or any of it.

If the unicast nature of the packet is truly a problem for you, you
can configure the always-broadcast flag (see 'man dhcpd.conf'), but my
intuition is that you are digging in the wrong place...

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090713/ad7b0d3e/attachment.bin>