Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
D
dhcp
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 81
    • Issues 81
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 18
    • Merge Requests 18
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source Projects
  • dhcp
  • Issues
  • #101

Closed
Open
Created Apr 28, 2020 by Thor Simon@tls

Patch: Fix renewals, releases sent from wrong source address on multihomed/VPN hosts

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

Edited Apr 30, 2020 by Thor Simon
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None