DHCP relay - wrong interface for relayed packet

Alan DeKok aland at deployingradius.com
Thu Jul 7 11:51:20 UTC 2022


On Jul 7, 2022, at 7:24 AM, Paul Thornton <paul at prt.org> wrote:
> This may be a Matthew specific question - I'm testing out the patch he kindly posted to me on uknof at the beginning of June to enable relaying to a different UDP port.

  That shouldn't affect the selection of IP address tho.

> For testing, I have a Cumulus box with two interfaces that we care about: vlan4091 which has a test client connected to it, and vlan545 which is the connection back to the rest of the network. Our test DHCP server (217.198.54.101) is in this "rest of the network" - IP routing all works as expected, and you can ping the DHCP server from the vlan4091 interface IP address (217.198.52.2) on the Cumulus router, and from clients on that VLAN - and vice versa.
> 
> When I send in a test DHCP request from a client connected to vlan4091, FR receives it and and re-sends it out to 217.198.54.101 on port 1067.  However, the DHCP server never sees that packet.
> 
> After some rummaging with strace and tcpdump, I've determined that FR is transmitting the relayed packet out of vlan4091 (I saw suspect looking ARPs, and put in a static ARP entry after which I see the frame transmitted on vlan4091) and not following the default route up out of vlan545.

  The DHCP socket generally binds to a particular interface.  So that may be it.

> Looking in proto_dhcp/dhcpd.c at dhcprelay_process_client_request, there's nothing in there to suggest that the outgoing interface is set and routing is overridden: But it looks like some parts are copied over from the socket handling the client communication; is there something here that could cause what I'm seeing?

  If the src/dst IP/port are correct, then generally routing issues are the responsibility of the routing layer.

  Unless the socket is bound to a particular interface.  In which case the packet *must* get sent out that interface.

> My other thought that if this was a general problem it would break FR DHCP relaying in a lot of people's use cases - and there aren't lots of people grumbling about this, so there must be something wacky going on with my setup but I'm slightly at a loss to see what's happening.  Any pointers greatfully received.

  The current DHCP relay behavior is a bit of a hack, TBH.  It should arguably have a different socket for outgoing packets.  The current behaviour works in most situations, but sometimes doesn't. :(

> Listening on dhcp interface vlan4091 address * port 67 bound to server dhcp.vlan4091

  Yup.  Packets using that socket are being sent via vlan4091, because that socket is bound to interface vlan4091.

  The solution is to create a new outbound socket, specifically for DHCP relaying.  It can be bound to "*" for the IP, and then the normal DHCP port.

  There are a few ways to do this... one might be to simply create a "wildcard" DHCP listener, which doesn't have an "interface" configured.  Then somehow update proto_dhcp/dhcpd.c to choose this listener for relayed packets.

  It's likely not hard, it just requires a bit of spelunking in the code.

  Alan DeKok.



More information about the Freeradius-Users mailing list