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 (Adam Nielsen)
2. Re: DCHP OFFER response going to relay address not to
orginating address (Simon Hobson)
----------------------------------------------------------------------
Message: 1
Date: Sun, 11 Sep 2022 09:46:26 +1000
From: Adam Nielsen <a.niel...@shikadi.net>
To: Dees <motosi...@yahoo.co.uk>
Cc: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DCHP OFFER response going to relay address not to
orginating address
Message-ID: <20220911094626.3c12b...@vorticon.teln.shikadi.net>
Content-Type: text/plain; charset=UTF-8
> 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?
I am far from an expert but I believe the purpose of the DHCP relay is
precisely to change the source/reply IP of the DHCP messages.
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. However forwarding broadcast packets is
often problematic, and so not normally done. (Especially when you need
to preserve the source MAC address in the forwarded packet as you do for
DHCP, which might mean a Layer 2 VPN forwarding Ethernet frames rather
than a Layer 3 VPN routing IP packets.)
I think a significantly easier solution in your case is to put the DHCP
relay on an IP address accessible over the VPN link. That way the
packets will still all come from a single IP address, but the replies
will make it back over the VPN link where the DHCP relay can pass them
on to the remote host. This way you won't have to worry about all the
pitfalls that come with forwarding broadcast packets.
Cheers,
Adam.
------------------------------
Message: 2
Date: Sun, 11 Sep 2022 09:24:44 +0100
From: Simon Hobson <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: <ef61bc98-7044-463a-bdd9-a1930511b...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
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
------------------------------
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 3
******************************************
