Send dhcp-users mailing list submissions to
        dhcp-users@lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
        dhcp-users-requ...@lists.isc.org

You can reach the person managing the list at
        dhcp-users-ow...@lists.isc.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."


Today's Topics:

   1. Migration within the 4.x codestream (Patrick Trapp)
   2. Patch: Fix renewals, releases sent from wrong source address
      on multihomed/VPN hosts (Thor Simon)
   3. Re: Patch: Fix renewals, releases sent from wrong source
      address on multihomed/VPN hosts (John Ioannidis)


----------------------------------------------------------------------

Message: 1
Date: Mon, 27 Apr 2020 20:56:45 +0000
From: Patrick Trapp <ptr...@nex-tech.com>
To: "dhcp-users@lists.isc.org" <dhcp-users@lists.isc.org>
Subject: Migration within the 4.x codestream
Message-ID:
        
<dm6pr12mb3577339748b3cb7f022814b9e6...@dm6pr12mb3577.namprd12.prod.outlook.com>
        
Content-Type: text/plain; charset="iso-8859-1"

We have been running isc dhcp 4.2.7 on a private network since it was the 
current release. We are finally replacing the servers in question and so 
upgrading isc dhcp. I'm seeing tips and suggestions for upgrading from a DHCP 3 
instance to a DHCP 4 instance, but nothing regarding migration from a DHCP 4 to 
a later DHCP 4.

So I ask the knowledgeable folks found here - can you share with me the 
concerns I need to be looking for with this update? Can you share any 
improvements or configuration changes that you recommend I consider that will 
be available as a result of this upgrade?

Thank you for your time! And in a trying time for almost everyone, I feel I'm 
overdue to say thank you for your contributions to the community.

Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<https://lists.isc.org/pipermail/dhcp-users/attachments/20200427/4e65a05a/attachment-0001.htm>

------------------------------

Message: 2
Date: Tue, 28 Apr 2020 00:19:36 +0000
From: Thor Simon <thor.si...@twosigma.com>
To: "dhcp-users@lists.isc.org" <dhcp-users@lists.isc.org>
Subject: Patch: Fix renewals, releases sent from wrong source address
        on multihomed/VPN hosts
Message-ID:
        <3da87cf1eaf7476f8e85853d0d4d0...@exmbdft11.ad.twosigma.com>
Content-Type: text/plain; charset="us-ascii"

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.

Thor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<https://lists.isc.org/pipermail/dhcp-users/attachments/20200428/719823ac/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sane-fallback.patch
Type: application/octet-stream
Size: 4511 bytes
Desc: sane-fallback.patch
URL: 
<https://lists.isc.org/pipermail/dhcp-users/attachments/20200428/719823ac/attachment-0001.obj>

------------------------------

Message: 3
Date: Mon, 27 Apr 2020 21:13:23 -0400
From: John Ioannidis <j...@tla.org>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Patch: Fix renewals, releases sent from wrong source
        address on multihomed/VPN hosts
Message-ID:
        <cabrqyhwqpjung2grmk_cnc2xsdwzujmmb3nppg0lxurvhhd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Thor!!! It's been ages!

Couple of things on this patch:

1. does the faulty behavior you are trying to fix happen if you have
explicitly set a more-specific route with a default src address for the
traffic in question, thus using the kernel's proper mechanism for setting
the source address rather than replicating in the dhclient code?
2. Fix your formatting, it's inconsistent with the surrounding code, and
Vixie will probably be annoyed :)
Cheers,

/ji

On Mon, Apr 27, 2020 at 8:19 PM Thor Simon <thor.si...@twosigma.com> wrote:

> 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.
>
>
>
> Thor
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<https://lists.isc.org/pipermail/dhcp-users/attachments/20200427/8e1a053f/attachment.htm>

------------------------------

Subject: Digest Footer

_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users


------------------------------

End of dhcp-users Digest, Vol 138, Issue 13
*******************************************

Reply via email to