GitLab

I have a population of systems which use dhclient on their physical interfaces for DHCP, but otherwise perform essentially no local network traffic. The interface coming up triggers (via NetworkManager, not the dhclient scripts) creation of an IPsec tunnel, which uses a ‘vti’ interface which itself receives a separate address via IKE. The machines run Debian Stretch.

This effectively creates a multihomed host configuration where dhclient is operating on a different interface than the one used by the default route. If you search the lists you’ll find a scattering of reports going back over a decade that dhclient intermittently sends messages from the wrong interface’s source address on such hosts. This got to be enough of a nuisance (I ran into a non-ISC DHCP server which not only NAKed such requests, it blacklisted the client!) that I finally root-caused the issue.

The problem is caused by inappropriate use of the “fallback” send mechanism when the message in question need not be routed. According to the block comment in osdep.h which appears to be the only documentation:

/* Porting::

   If you add support for sending packets directly out an interface,
   and your support does not do ARP or routing, you must use a fallback
   mechanism to deal with packets that need to be sent to routers.
   Currently, all low-level packet interfaces use BSD sockets as a
   fallback. */

However, what dhclient.c actually does is this, in both the REQUEST and RELEASE cases:

        if (destination.sin_addr.s_addr != INADDR_BROADCAST &&
            fallback_interface) {
                result = send_packet(fallback_interface, […]

In other words, don’t bother actually checking if the destination is on a local network, send all unicast traffic via the fallback interface. The fallback interface doesn’t have a bound address so we are effectively sending from 0.0.0.0 and the system routing machinery may do with us what it will. Such as select an inappropriate source address which does not match the client-ip in the lease and freak out the DHCP server.

The attached diff, which is against Debian’s patched 4.3.5, seems to fix the issue. sane-fallback.patch