dhcpd and relayed responses from multi-interface Linux server

[Simon Hobson]

Neufeld, Keith <Keith.Neufeld at wichita.edu> wrote:

> The DHCP servers have two interfaces (I'm renaming them from their autogenerated names for conversational simplicity), one for administrative access and one for application service access:
> 
> eth0 -- 10.1.61.16 -- admin
> eth1 -- 10.1.69.16 -- service
> 
> We have subnet declarations for each interface because we need to serve clients on each of those subnets; but dhcpd is being invoked with eth1 on its command line

Is there a specific reason for doing it this way ? While it's easy to reply with what is in effect "you're building the network wrong", that does seem to be the fundamental issue here.

> and appears to be listening only on eth1 as desired:
> 
> Jun  1 16:26:18 netsvc-516 dhcpd[704228]: Listening on LPF/eth1/00:50:56:be:43:d6/10.1.69.0/24
> Jun  1 16:26:18 netsvc-516 dhcpd[704228]: Sending on   LPF/eth1/00:50:56:be:43:d6/10.1.69.0/24
> Jun  1 16:26:18 netsvc-516 dhcpd[704228]: Sending on   Socket/fallback/fallback-net
> 
> The problem is with the "fallback" UDP socket used for transmitting unicast messages, when it needs to send responses to relayed DISCOVERs.  In common/socket.c, in the function maybe_setup_fallback(), a UDP INET socket is created but not bound to any specific interface.  Then when packets are transmitted out the fallback socket, it appears that the behavior is to use the server host's route table to decide which interface to send the packet out of, *and to use that interface's IP as the source IP*.
...
> Has this come up on the list before?

I don't recall seeing this before on the list. But then it would be normal to serve the locally connected devices directly rather than via a relay agent - hence few would hit the problem.

I did start off setting out a couple of options that I thought might work, but while expanding my thoughts realised that they wouldn't achieve what's needed.

Policy based routing won't work because, I think, source address selection occurs before the routing could have an effect.

Disabling packet filter operations (needs a compile with an option set) which can deal with some classes of problem, wouldn't get round the issue.

It might, you'd need to do the homework, be possible to apply some mangle rules to change the source address - i.e. for UDP from port 67 on 10.1.61.16, change (mangle) the source address to 10.1.69.16. You'd then also need to apply a routing rule to force the packet to go out of eth1 rather than out of eth0.
I think it might be doable in the Output Mangle table looking at https://shorewall.org/NetfilterOverview.html

Hoep this is of some help, Simon