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. dhcpd and relayed responses from multi-interface Linux server
(Neufeld, Keith)
2. Re: dhcpd and relayed responses from multi-interface Linux
server (Simon Hobson)
3. dhcrelay is listening on all of myinterfaces instead of
specified ones (rimvydukas)
----------------------------------------------------------------------
Message: 1
Date: Wed, 3 Jun 2020 13:56:46 +0000
From: "Neufeld, Keith" <keith.neuf...@wichita.edu>
To: "dhcp-users@lists.isc.org" <dhcp-users@lists.isc.org>
Subject: dhcpd and relayed responses from multi-interface Linux server
Message-ID: <6e8bac96-fd7f-4992-9ece-0d1272848...@wichita.edu>
Content-Type: text/plain; charset="us-ascii"
Does anyone have dhcpd (server, not client) successfully running on a Linux
server built in the last few years (recent enough to use LPF, which you can see
in the log file at server start) in an environment with relayed clients?
I'm surprised if this hasn't been covered before, but my search-fu isn't good
enough to find it in the list archives.
We're prepping a pair of new ISC DHCP servers on RHEL 8. We originally tried
RH's bundled DHCP 4.1.5 and have since updated to 4.4.2, with the same results
(described below)
The DHCP servers have two interfaces (I'm renaming them from their
autogenerated names for conversational simplicity), one for administrative
access and one for application service access:
eth0 -- 10.1.61.16 -- admin
eth1 -- 10.1.69.16 -- service
We have subnet declarations for each interface because we need to serve clients
on each of those subnets; but dhcpd is being invoked with eth1 on its command
line and appears to be listening only on eth1 as desired:
Jun 1 16:26:18 netsvc-516 dhcpd[704228]: Listening on
LPF/eth1/00:50:56:be:43:d6/10.1.69.0/24
Jun 1 16:26:18 netsvc-516 dhcpd[704228]: Sending on
LPF/eth1/00:50:56:be:43:d6/10.1.69.0/24
Jun 1 16:26:18 netsvc-516 dhcpd[704228]: Sending on
Socket/fallback/fallback-net
The problem is with the "fallback" UDP socket used for transmitting unicast
messages, when it needs to send responses to relayed DISCOVERs. In
common/socket.c, in the function maybe_setup_fallback(), a UDP INET socket is
created but not bound to any specific interface. Then when packets are
transmitted out the fallback socket, it appears that the behavior is to use the
server host's route table to decide which interface to send the packet out of,
*and to use that interface's IP as the source IP*.
Since our servers are set up with the default route out eth0, eth0's IP gets
used as the source IP on the relay responses (OFFERs). It appears that the
relay agent in our LAN routers keeps a state table and checks the source IP of
relay responses. Since the OFFER is coming from a different IP (10.1.61.16)
than the DISCOVER was relayed to (10.1.69.16), the router doesn't relay the
response back to the client and the client never completes the conversation to
get a lease.
When we temporarily change the server host's default route to eth1, the client
gets the relayed responses, continues the conversation (broadcast/relay
REQUEST/ACK), and gets its lease as it normally would.
It seems to me that our scenario -- a multi-interface server running LPF plus
fallback socket and needing to handle relayed communication -- is bound to fail
under the current code. (Therefore not many people must be doing it. :-) )
It seems to me that fixing it would require building an array of UDP INET
sockets (for the sake of conversation, call it the fallback array, though maybe
conceptually it's no longer fallback), one on each interface on which dhcpd is
listening; and matching unicast transmissions, at least *relayed* ones, to send
out the interface on which they were received in order to ensure that their
source IP is correct.
It's been way too long since I studied sockets for me to remember whether it's
possible that dhcpd could instead write the desired source IP into the response
packet and it would be preserved by the server host even when sending it out a
different interface. If this would work, it would be a much less invasive code
change.
Has this come up on the list before? Anyone else run across it? Am I
overlooking a simple workaround (other than changing our server routing or
running dhcpd in a single-interface virtual jail)?
--
Keith Neufeld
Director of Networking and Telecommunications
Wichita State University
------------------------------
Message: 2
Date: Wed, 3 Jun 2020 15:44:54 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: dhcpd and relayed responses from multi-interface Linux
server
Message-ID: <3aa474ef-ad3f-4374-9f46-7f7e8cb6a...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
Neufeld, Keith <keith.neuf...@wichita.edu> wrote:
> The DHCP servers have two interfaces (I'm renaming them from their
> autogenerated names for conversational simplicity), one for administrative
> access and one for application service access:
>
> eth0 -- 10.1.61.16 -- admin
> eth1 -- 10.1.69.16 -- service
>
> We have subnet declarations for each interface because we need to serve
> clients on each of those subnets; but dhcpd is being invoked with eth1 on its
> command line
Is there a specific reason for doing it this way ? While it's easy to reply
with what is in effect "you're building the network wrong", that does seem to
be the fundamental issue here.
> and appears to be listening only on eth1 as desired:
>
> Jun 1 16:26:18 netsvc-516 dhcpd[704228]: Listening on
> LPF/eth1/00:50:56:be:43:d6/10.1.69.0/24
> Jun 1 16:26:18 netsvc-516 dhcpd[704228]: Sending on
> LPF/eth1/00:50:56:be:43:d6/10.1.69.0/24
> Jun 1 16:26:18 netsvc-516 dhcpd[704228]: Sending on
> Socket/fallback/fallback-net
>
> The problem is with the "fallback" UDP socket used for transmitting unicast
> messages, when it needs to send responses to relayed DISCOVERs. In
> common/socket.c, in the function maybe_setup_fallback(), a UDP INET socket is
> created but not bound to any specific interface. Then when packets are
> transmitted out the fallback socket, it appears that the behavior is to use
> the server host's route table to decide which interface to send the packet
> out of, *and to use that interface's IP as the source IP*.
...
> Has this come up on the list before?
I don't recall seeing this before on the list. But then it would be normal to
serve the locally connected devices directly rather than via a relay agent -
hence few would hit the problem.
I did start off setting out a couple of options that I thought might work, but
while expanding my thoughts realised that they wouldn't achieve what's needed.
Policy based routing won't work because, I think, source address selection
occurs before the routing could have an effect.
Disabling packet filter operations (needs a compile with an option set) which
can deal with some classes of problem, wouldn't get round the issue.
It might, you'd need to do the homework, be possible to apply some mangle rules
to change the source address - i.e. for UDP from port 67 on 10.1.61.16, change
(mangle) the source address to 10.1.69.16. You'd then also need to apply a
routing rule to force the packet to go out of eth1 rather than out of eth0.
I think it might be doable in the Output Mangle table looking at
https://shorewall.org/NetfilterOverview.html
Hoep this is of some help, Simon
------------------------------
Message: 3
Date: Wed, 3 Jun 2020 16:55:55 -0500 (CDT)
From: rimvydukas <rimvy...@rimvydas.info>
To: dhcp-users@lists.isc.org
Subject: dhcrelay is listening on all of myinterfaces instead of
specified ones
Message-ID: <1591221355192-0.p...@n4.nabble.com>
Content-Type: text/plain; charset=us-ascii
Hi,
Just installed isc-dhcp-relay package on my Buster and noticed one
interesting thing:
usr/sbin/dhcrelay -d -i eth0lo 172.50.16.253
Requesting: eth0lo as upstream: Y downstream: Y
Internet Systems Consortium DHCP Relay Agent 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/vnet0/
Sending on LPF/vnet0/
Listening on LPF/lan1vbr/
Sending on LPF/lan1vbr/
Listening on LPF/lan1vbr-fake/
Sending on LPF/lan1vbr-fake/
Listening on LPF/dmz1vbr/
Sending on LPF/dmz1vbr/
Listening on LPF/dmz1vbr-fake/
Sending on LPF/dmz1vbr-fake/
Listening on LPF/eth0/
Sending on LPF/eth0/
Sending on Socket/fallback
As you can see, relay agent is listening on all of my interfaces:/ Why is
that? It seems that because of that I get plenty of the following messages:
dhcrelay[4114]: Discarding packet received on vnet0 interface that has no
IPv4 address assigned.
Is there any way to force relay agent to listen only on specific interfaces?
--
Sent from: http://isc-dhcp-users.2343191.n4.nabble.com/
------------------------------
Subject: Digest Footer
_______________________________________________
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 140, Issue 1
******************************************
