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. Re: DCHP OFFER response going to relay address not to
orginating address (Dees)
2. Re: DCHP OFFER response going to relay address not to
orginating address (Simon)
----------------------------------------------------------------------
Message: 1
Date: Sun, 11 Sep 2022 14:38:41 +0000 (UTC)
From: Dees <motosi...@yahoo.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DCHP OFFER response going to relay address not to
orginating address
Message-ID: <817298041.3175823.1662907121...@mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"
Hi Simon,
Thanks for the advice.
With difficulty in routing internal site DHCP subnet across (it will prevent
usual DHCP renewal through unicast assuming a client will eventually do DHCP
broadcast), will the following subnet declaration for tunnel IP then give out a
shared-network pool subnet?
shared-network Combined-pools {subnet 192.168.1.0 netmask 255.255.255.0 {?
range 192.168.1.100 192.168.1.254;? option subnet-mask 255.255.255.0;? option
routers 192.168.1.1;
option domain-name-servers 8.8.8.8, 8.8.4.4;? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? }
subnet 192.168.3.0 netmask 255.255.255.0? {? # subnet on interface?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?}? ? ? ?
? ? ? ? ?subnet 10.0.8.0 netmask 255.255.255.0? {
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? }? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? }
Where 10.0.8.0 is the subnet for the tunnel interface.
or
shared-network Combined-pools {subnet 192.168.1.0 netmask 255.255.255.0 {?
range 192.168.1.100 192.168.1.254;? option subnet-mask 255.255.255.0;? option
routers 192.168.1.1;
option domain-name-servers 8.8.8.8, 8.8.4.4;? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ?
Thanks, Adam for your input as well.
Kind regards,Deepesh
On Sunday, 11 September 2022 at 09:26:12 BST, Simon Hobson
<dh...@thehobsons.co.uk> wrote:
Adam Nielsen <a.niel...@shikadi.net> wrote:
>> I have a network that sits remote and with DHCP on the central site.
>> DHCP DISCOVER is reaching the server and the server is responding.
>> DCHP? request source IP is 10.0.8.2 which is tunnel IP which is
>> routable IP on the network but when DCHP responds it is responding to
>> DHCP relay IP? (192.168.1.1) which is not routable not reaching back,
>> is there a way to instruct DHCP to route it back to source IP? Or is
>> this not a valid scenario for the DHCP relay?
Your network config is invalid. Packets MUST be routable from DHCP server to
the client subnet. Without this, it cannot reply to unicast packets from
clients when they are renewing leases - so you may have intermittent network
problems as thet get very close to the end of their leases and fall back to
broadcasts.
If you insist on not having the correct routing in place, you might be able to
define a shared network containing the client and tunnel subnets, and change
the relay agent to use the tunnel address. The server will then see the tunnel
address - but will be able to associate it with the clients via the shared
network.
>In your case if you don't want the IPs to change, you don't want a DHCP
>relay, and instead you want to instruct your router to forward the
>broadcast DHCP packets over the VPN link as-is.? This will cause your
>DHCP server to see the packets come from the real remote IP/MAC, and it
>will send responses there.
That won't work - the server will see locally attached clients and assign
incorrect IPs.
Also, there's a limitation that the server won't listen for broadcast packets
on non-broadcast links - so if the tunnel terminates on the seever then it
wouldn't be listening for the packets.
Simon
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20220911/897ba2a4/attachment-0001.htm>
------------------------------
Message: 2
Date: Sun, 11 Sep 2022 18:51:19 +0100
From: Simon <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DCHP OFFER response going to relay address not to
orginating address
Message-ID: <56f34769-accd-42e6-aca0-f86f7f4ad...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Dees <motosi...@yahoo.co.uk> wrote:
> With difficulty in routing internal site DHCP subnet across (it will prevent
> usual DHCP renewal through unicast assuming a client will eventually do DHCP
> broadcast), will the following subnet declaration for tunnel IP then give out
> a shared-network pool subnet
>
> shared-network Combined-pools {
> subnet 192.168.1.0 netmask 255.255.255.0 {
> range 192.168.1.100 192.168.1.254;
> option subnet-mask 255.255.255.0;
> option routers 192.168.1.1;
>
> option domain-name-servers 8.8.8.8, 8.8.4.4;
> }
>
> subnet 192.168.3.0 netmask 255.255.255.0 { # subnet on interface
> }
>
> subnet 10.0.8.0 netmask 255.255.255.0 {
> }
> }
>
> Where 10.0.8.0 is the subnet for the tunnel interface.
Is 192.168.3.0/24 the interface on the DHCP server ? If so, then it should NOT
be in the shared-network.
Otherwise, yes that should do it provided your relay agent allows you to set
the CI-Addr (Client Interface Address) field to 10.0.8.n rather than
192.168.1.1.
The normal function of the shared-network declaration is to handle the case
where you run two (or more) IP subnets on the one wire, and where (in
principle) all IPs in the subnets are functionally equivalent. Here, we are
sort of cheating the system to work around broken routing.
The way things work is :
When a client broadcasts for a DHCP server, the relay agent will pick up the
packet. It then fills in the CI-Addr field to inform the server where the
client is located. The packet is then unicast to the server(s) it?s configured
to - the source address doesn?t actually matter here.
When the server picks up the packet, it sees the CI-Addr field and looks for a
subnet declaration that contains it. If there?s a shared-network declaration,
then that will be taken into account - all addresses within subnets within a
shared-network are considered equal.
In this case, your CI-Addr will be in one subnet of the shared-network, and as
there are only ranges in the other subnet, then those will be used.
The response packet will then be unicast to the CI-Addr regardless of the IP
being offered or the source address of the request packet.
And finally the gateway will broadcast the packet on the client?s network so
the client can pick it up.
As I say, ideally you should simply add the requisite route to the subnet.
Without that, you will have clients attempting to renew leases and failing to
do so. If the packets reach the server then that will increase the load on the
server as it will be responding to each of the renewal requests.
Different clients may behave differently, and it?s possible that some ?poorly
designed? ones may time out. Most should resort to broadcasts a short time
before their lease times out and so should still be able to renew without
timing out.
Simon
------------------------------
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 167, Issue 4
******************************************
