• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login

    ProxyDHCP responding to PXE boot in different subnet

    Scheduled Pinned Locked Moved
    General Problems
    2
    13
    1.6k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      mstabrin
      last edited by

      Hello FOG Team,

      I have a problem with our FOG project dnsmasq setup and I am sorry if this has been answered before in another thread.

      My setup is as follows:

      • Subnet 1 hosting the FOG server + proxyDHCP (Both are on the same machine).
        I followed the setup exactly as described here: https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq

      • Subnet 2 hosting the FOG client (MAC: 52:54:00:fb:96:27).

      • Palo Alto Firewall with integrated DHCP server (Same subnet as the FOG server).
        I added a DHCP relay entry to forward the DHCP communication between the subnets.

      Everything works fine when I move the client to the same subnet as the FOG server + proxyDHCP. I attached a tcpdump log of the working DHCP communication on the FOG server (141.5.200.57): VLAN1.txt

      However, when I move the client to the other subnet, then dnsmasq seems to fail.
      I can see that the DHCP discover from the client in the different subnet is arriving at the proxyDHCP server, but the proxyDHCP is not answering with an offer and I cannot figure out why.
      I attached a tcpdump log of the not working DHCP communicatoin on the FOG server (141.5.200.57) (10.65.0.6 is the Gateway of the subnet that hosts the client): Privat.txt

      I am new to this, but the only difference in the two files seems to be that in the failing communication an additional entry “Gateway IP” exists.
      Additionally, the port of the senders incoming message seems to be 67 (10.65.0.6.67) instead of 68 (0.0.0.0.68).

      Since the broadcast message seems to reach the proxyDHCP, I do not suspect a problem with the DHCP relay, however I am not sure if the mixed up port might have an influence?
      Could it be a problem with the proxyDHCP that needs to be configured differently to handle broadcasts from another subnet or has problems to listen to DHCP pakets coming from port 67?

      If you need more information, please let me know 🙂
      Every suggestions is highly appreciated 😄

      Best,
      Markus

      george1421G 2 Replies Last reply Reply Quote 0
      • george1421G
        george1421 Moderator @mstabrin
        last edited by

        @mstabrin Give me a minute to digest this post.

        Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

        1 Reply Last reply Reply Quote 0
        • george1421G
          george1421 Moderator @mstabrin
          last edited by george1421

          @mstabrin OK let confirm the settings in your ltsp.conf. They should match the values in this document: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server (this should be the source document the wiki is based on). I would think its probably right because the target computer boots correctly on the local subnet. I’m leaning towards the dhcp-helper service as the issue. But post your ltsp.conf file here.

          On your dhcp-relay/dhcp-helper service add the fog server’s IP address as the last host in the server list.

          If the dhcp-helper service is configured correctly, then follow this tutorial to create a pcap file on your FOG server. This will tell us if your fog server is getting the dhcp DISCOVER and sending out an OFFER. I need to see the raw data not exported text as you have posted. Upload the pcap to a file share site and post the link here, or IM me the link and I will look at it.
          https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

          Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

          1 Reply Last reply Reply Quote 0
          • M
            mstabrin
            last edited by

            Hello @george1421, thank you very much for your help 🙂

            Here is the ltsp.conf: ltsp.txt

            I cannot reach the machine today anymore, but I will check the DHCP relay settings and deliver the requested tcpdump files tomorrow.

            1 Reply Last reply Reply Quote 0
            • M
              mstabrin
              last edited by

              Another question:
              Since the client and the FOG server are not in the same subnet, do you also need the tcpdump from the client PC during the time of the same PXE boot process?

              george1421G 1 Reply Last reply Reply Quote 0
              • george1421G
                george1421 Moderator @mstabrin
                last edited by george1421

                @mstabrin

                Here is the ltsp.conf

                This looks good it will function across subnets. I just wanted to make sure you didn’t mess with the range command.

                At this point I don’t need to see the client side, I want to see if the dnsmasq server is seeing the DISCOVER and responding with an OFFER.

                If the server side doesn’t give us what we need, then we can use a witness computer on the pxe booting computer’s side using the capture filter of port 67 or port 68 to ensure we see two OFFER packets. But the fog server side first.

                Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

                1 Reply Last reply Reply Quote 0
                • M
                  mstabrin
                  last edited by

                  Alright, I will provide you tomorrow with further information. 🙂

                  1 Reply Last reply Reply Quote 0
                  • M
                    mstabrin
                    last edited by

                    Hello @george1421,

                    We checked the the DHCP relay and it seems like we did setup this correclty.
                    We also seem to receive the DISCOVER at the server, but somehow the proxyDHCP is refusing to answer with an offer.

                    I uploaded the tcpdump suggested in the link you sent me to OwnCloud for the working and not working case.

                    Let me know when you need more information and thanks a lot for looking at the case 🙂

                    george1421G 1 Reply Last reply Reply Quote 0
                    • george1421G
                      george1421 Moderator @mstabrin
                      last edited by

                      @mstabrin This one is puzzling. Is there anything in the /var/log/syslog on the fog server that explains why dnsmasq is rejecting this request?

                      Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

                      1 Reply Last reply Reply Quote 0
                      • M
                        mstabrin
                        last edited by

                        Hello @george1421 ,

                        The /var/log/syslog actually seems to show some information about the rejected request!

                        Log of the failing case:

                        Feb  3 10:02:01 fog-server2021 dnsmasq-dhcp[124691]: no address range available for DHCP request via 10.65.0.6
Feb  3 10:02:04 fog-server2021 dnsmasq-dhcp[124691]: message repeated 2 times: [ no address range available for DHCP request via 10.65.0.6]

                        Log of the working case:

                        Feb  3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 available DHCP subnet: 141.5.200.57/255.255.240.0
Feb  3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 vendor class: PXEClient:Arch:00000:UNDI:002001
Feb  3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 user class: iPXE
Feb  3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 PXE(ens160) 52:54:00:fb:96:27 proxy
Feb  3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 tags: BIOS, ens160
Feb  3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 bootfile name: undionly.kpxe
Feb  3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 next server: 141.5.200.57
Feb  3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 broadcast response
Feb  3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 sent size:  1 option: 53 message-type  2
Feb  3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 sent size:  4 option: 54 server-identifier  141.5.200.57
Feb  3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 sent size:  9 option: 60 vendor-class  50:58:45:43:6c:69:65:6e:74
Feb  3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 sent size: 17 option: 97 client-machine-id  00:21:d0:93:2e:ac:07:9d:42:aa:2f:98:3c:ba...
Feb  3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 sent size: 50 option: 43 vendor-encap  06:01:03:08:07:80:00:01:8d:05:c8:39:09:0e...

                        So it seems that there is a problem with the provided (or actually not provided) DHCP address range.

                        george1421G 1 Reply Last reply Reply Quote 0
                        • george1421G
                          george1421 Moderator @mstabrin
                          last edited by

                          @mstabrin said in ProxyDHCP responding to PXE boot in different subnet:

                          no address range available for DHCP request via 10.65.0.6

                          I understand what its saying but the question is why, and why with your setup. Your dhcp-relay is using unicast messaging vs the standard broadcast messaging. That may also play into the response.

                          Let me see if I can find an answer to this.

                          Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

                          1 Reply Last reply Reply Quote 0
                          • M
                            mstabrin
                            last edited by mstabrin

                            Hello @george1421 ,

                            I looked into the error message and found an actual solution here: https://dnsmasq-discuss.thekelleys.org.narkive.com/3JlGMO6e/dhcp-proxy-problem

                            I needed to specify the dhcp-range for both subnets:

                            So instead of using:

                            dhcp-range=141.5.200.57,proxy

                            in the /etc/dnsmasq.d/ltsp.conf, I added the second subnet with the respective netmasks:

                            dhcp-range=141.5.200.255,proxy,255.255.240.0
dhcp-range=10.65.0.255,proxy,255.255.252.0

                            and everything seems to work now 🙂

                            Thank you so much for the help!

                            george1421G 1 Reply Last reply Reply Quote 1
                            • george1421G
                              george1421 Moderator @mstabrin
                              last edited by

                              @mstabrin Ok that is the answer I just came up with. For every foreign subnet you will need to add in a new dhcp-range value.

                              Well done finding the solution. I also learned something new today too about adding multiple ranges.

                              Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

                              1 Reply Last reply Reply Quote 0
                              • 1 / 1
                              • First post
                                Last post

                              222

                              Online

                              12.0k

                              Users

                              17.3k

                              Topics

                              155.2k

                              Posts
                              Copyright © 2012-2024 FOG Project