ShreyasZare
commented
4 months ago Thanks for the post. This is how sockets work on Linux when they are bound to 0.0.0.0 address. The response is always sent to the interface with a default route. On Windows, the response is sent back via the same interface the request was received from.
There is no easy solution for this apart from the DHCP server creating a socket for all IP addresses on the system and keep a watch on changes to recreate all sockets again. This can become problematic since valid requests may get lost while DHCP server is recreating new sockets causing the ongoing transactions to fail.
There are some fixes that can be done on the Linux system itself as explained here.
If possible to try to use the same interface you have default route for your DHCP relay agent. That will be an easy way to make it work.
tannyl
Running a Docker container with multiply networks connected. When requesting an IP address from the DHCP server via a DHCP relay, then the DHCP server does not respond via the same interface the unicast request originated from. Instead it seems to respond via the default gateway and/or eth0.
As shown below the unicast request enters via eth1, but the server responds via eth0. This of course does not work since the firewall acting as the DHCP relay drops the invalid traffic that comes out of eth0.
In my opinion unicast DHCP requests should always exit via the same interface that received them. Or well rather any type of requests should always respond via the same interface it was received on.
Also as a feature request. We should be able to specify which interfaces that are allowed to respond to DHCP requests (just like we can define this for DNS queries and web service access)