ProxyDHCP responding to PXE boot in different subnet
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 (22.214.171.124): 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 (126.96.36.199) (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
@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.
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:
in the /etc/dnsmasq.d/ltsp.conf, I added the second subnet with the respective netmasks:
and everything seems to work now
Thank you so much for the help!
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.
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: no address range available for DHCP request via 10.65.0.6 Feb 3 10:02:04 fog-server2021 dnsmasq-dhcp: 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: 3153480460 available DHCP subnet: 188.8.131.52/255.255.240.0 Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp: 3153480460 vendor class: PXEClient:Arch:00000:UNDI:002001 Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp: 3153480460 user class: iPXE Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp: 3153480460 PXE(ens160) 52:54:00:fb:96:27 proxy Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp: 3153480460 tags: BIOS, ens160 Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp: 3153480460 bootfile name: undionly.kpxe Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp: 3153480460 next server: 184.108.40.206 Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp: 3153480460 broadcast response Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp: 3153480460 sent size: 1 option: 53 message-type 2 Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp: 3153480460 sent size: 4 option: 54 server-identifier 220.127.116.11 Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp: 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: 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: 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.
@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?
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
Alright, I will provide you tomorrow with further information.
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 68to ensure we see two OFFER packets. But the fog server side first.
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?
@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.
@mstabrin Give me a minute to digest this post.