<html><head></head><body><div class="ydp5c7445a8yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div id="ydp5c7445a8yiv9736295530"><div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;" class="ydp5c7445a8yiv9736295530ydp43afd171yahoo-style-wrap"><div></div>
        <div dir="ltr">Hi Simon,</div><div dir="ltr"><br clear="none"></div><div dir="ltr">Thanks for the advice.</div><div dir="ltr"><br></div><div dir="ltr" data-setdir="false">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 </div><div dir="ltr"><br clear="none"></div><div dir="ltr" data-setdir="false"><div><div>shared-network Combined-pools {</div><div>subnet 192.168.1.0 netmask 255.255.255.0 {</div><div>  range 192.168.1.100 192.168.1.254;</div><div>  option subnet-mask 255.255.255.0;</div><div>  option routers 192.168.1.1;</div><div><br></div><div>option domain-name-servers 8.8.8.8, 8.8.4.4;</div><div>                                          }</div><div><br></div><div dir="ltr" data-setdir="false"><div><div style="color: rgb(0, 0, 0); font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: 16px;" dir="ltr" data-setdir="false">subnet 192.168.3.0 netmask 255.255.255.0  {  # subnet on interface <br></div><div style="color: rgb(0, 0, 0); font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: 16px;">                                                                       }</div><div style="color: rgb(0, 0, 0); font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: 16px;">                 </div></div></div><div>subnet <b>10.0.8.0 </b>netmask 255.255.255.0  {<br></div><div>                                                                  }</div><div>                                }</div></div><div><br></div><div dir="ltr" data-setdir="false">Where <b>10.0.8.0</b> is the subnet for the tunnel interface.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">or</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false"><div><div style="color: rgb(0, 0, 0); font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: 16px;">shared-network Combined-pools {</div><div style="color: rgb(0, 0, 0); font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: 16px;">subnet 192.168.1.0 netmask 255.255.255.0 {</div><div style="color: rgb(0, 0, 0); font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: 16px;">  range 192.168.1.100 192.168.1.254;</div><div style="color: rgb(0, 0, 0); font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: 16px;">  option subnet-mask 255.255.255.0;</div><div style="color: rgb(0, 0, 0); font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: 16px;">  option routers 192.168.1.1;</div><div style="color: rgb(0, 0, 0); font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: 16px;"><br></div><div style="color: rgb(0, 0, 0); font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: 16px;">option domain-name-servers 8.8.8.8, 8.8.4.4;</div></div>                                                           </div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Thanks, Adam for your input as well.<br></div><br></div><div dir="ltr" data-setdir="false">Kind regards,</div><div dir="ltr" data-setdir="false">Deepesh</div><div><br><br clear="none"></div>
        
        </div></div></div><div id="ydpb22b0a81yiv9736295530yqt91788" class="ydpb22b0a81yiv9736295530yqt6950422533"><div id="ydpb22b0a81yiv9736295530ydp4ec40589yahoo_quoted_3451102543" class="ydpb22b0a81yiv9736295530ydp4ec40589yahoo_quoted">
            <div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
                
                <div>
                    On Sunday, 11 September 2022 at 09:26:12 BST, Simon Hobson <dhcp1@thehobsons.co.uk> wrote:
                </div>
                <div><br clear="none"></div>
                <div><br clear="none"></div>
                <div><div dir="ltr">Adam Nielsen <<a shape="rect" href="mailto:a.nielsen@shikadi.net" rel="nofollow" target="_blank">a.nielsen@shikadi.net</a>> wrote:<br clear="none">>> I have a network that sits remote and with DHCP on the central site.<br clear="none">>> DHCP DISCOVER is reaching the server and the server is responding.<br clear="none">>> DCHP  request source IP is 10.0.8.2 which is tunnel IP which is<br clear="none">>> routable IP on the network but when DCHP responds it is responding to<br clear="none">>> DHCP relay IP  (192.168.1.1) which is not routable not reaching back,<br clear="none">>> is there a way to instruct DHCP to route it back to source IP? Or is<br clear="none">>> this not a valid scenario for the DHCP relay?<br clear="none"><br clear="none">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.<br clear="none"><br clear="none">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.<div id="ydpb22b0a81yiv9736295530ydp4ec40589yqtfd81616" class="ydpb22b0a81yiv9736295530ydp4ec40589yqt0570967990"><br clear="none"><br clear="none"><br clear="none">>In your case if you don't want the IPs to change, you don't want a DHCP<br clear="none">>relay, and instead you want to instruct your router to forward the<br clear="none">>broadcast DHCP packets over the VPN link as-is.  This will cause your<br clear="none">>DHCP server to see the packets come from the real remote IP/MAC, and it<br clear="none">>will send responses there.</div><br clear="none"><br clear="none">That won't work - the server will see locally attached clients and assign incorrect IPs.<br clear="none">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.<br clear="none"> <br clear="none"><br clear="none">Simon<br clear="none"><br clear="none">-- <br clear="none">ISC funds the development of this software with paid support subscriptions. Contact us at <a shape="rect" href="https://www.isc.org/contact/ " rel="nofollow" target="_blank">https://www.isc.org/contact/ </a>for more information.<br clear="none"><br clear="none">dhcp-users mailing list<br clear="none"><a shape="rect" href="mailto:dhcp-users@lists.isc.org" rel="nofollow" target="_blank">dhcp-users@lists.isc.org</a><br clear="none"><a shape="rect" href="https://lists.isc.org/mailman/listinfo/dhcp-users" rel="nofollow" target="_blank">https://lists.isc.org/mailman/listinfo/dhcp-users</a><div id="ydpb22b0a81yiv9736295530ydp4ec40589yqtfd97931" class="ydpb22b0a81yiv9736295530ydp4ec40589yqt0570967990"><br clear="none"></div></div></div>
            </div>
        </div></div></body></html>