DHCP Issue
-
Server Ubuntu 16.10
- FOG Version: 1.4.0
- OS:
Client
- Service Version:
- OS:
Description
I have set FOG up a good few times over the past few weeks, always on a NAT network on Virtualbox DHCP worked fine from the FOG server DHCP option
i have now installed FOG as BRIDGED network using my VirginMedia router as DHCP, options 67,68 set up through port forwarding to direct requests to the FOG server’s IP but try as i might i cannot get it working.
the client machines do see the ipxe but then fail to boot from the media
-
i get this error
-
This appears to be a home kit right? Most home routers don’t support dhcp options 66 and 67, if your VirginMedia route does then you are lucky.
In my home lab fog setup, my router doesn’t support dhcp options of any kind, so I run dnsmasq on the fog server to support pxe booting. This method works really well. No configuration changes to the isp router, just enable dnsmaq on fog and configure it.
In your case if you are running fog on VB then for the network adapter change the style to one of the intel (like) nics from the AMD default. You will see better speed improvements and set it to bridge mode.
If you are trying to pxe boot the client also running on VB, do the same. The error message you posted is not a FOG related error message this is VM saying its not getting the proper file name (dhcp option 67) and I assume the fog server IP address (dhcp option 66) since the next server is 192.168.0.1 (your ISP router address??) to be able to pxe boot.
-
hi
yes the router allows port forwarding for PXE etc, i know this does work with VMs as on my other set up it passes the PXE to a MS server fine, but does not seem to work with the FOG server
all NIC are all set to Intel already
yes 192.168.0.1 is router
i was trying to get this system set up to pass to a friend as a low maintenance image system, not looking like it going to work though
-
@KeithDib said in DHCP Issue:
router allows port forwarding for PXE
This statement confuses me a bit. Port forwarding of PXE?? Unless I’m totally missing how you have things setup, this entire kit is inside you home network right? If that is the case I can’t see where port forwarding comes into play.
For a small DIY project I turned a Raspberry Pi2 into a FOG imaging server. Now that the Pi3s are available I might have to take another look at the project. The Pi2 ran great but maxed out at 2 unicast streams before running into issues with the 100Mb/s network interface. The Pi3 has a GbE interface. In your case I think I would just grab any old laptop that has 2GB or more of ram in it and turn it into a low cost FOG server and move away from the VB deployment system.
But back on point I can tell you that your pxe booting client is not getting the proper boot information. In your case what device is suppling the dhcp 66 and 67 values. I know you talked about port forwarding, but what ever you forward to has to provide this info.
-
yes the router deals with 66,67 etc as protforwarding rules for DHCP, as i say this works fine if pointing it at an MS server as i also run SCCM for myself as a test bed, all i have done for testing fog is to change the IP on the rule
-
another ting i have noticed, and i cannot explain this but after FOG installs it seems to change the password of the account i used to install it, i have to set up a second acocunt to allow me root access again, then change the original password back
-
These are just scattered thoughts on this so far.
I take it your fog server is at 192.168.0.7?
What services do you have on the fog server to accept these port forwards? You need to have something to catch these forwards.
Your picture clearly shows your next server being 192.168.0.1so something is telling your pxe booting client to go that way.
Well we can say the truth is on the wire here. If you can load tcpdump on your fog server (or wireshark on a witness computer) and capture the pxe booting process we can see who is saying what things to your pxe booting client.
-
@george1421 Thinking about this a bit more (that port forward stuff is still bugging me if everything is on your local lan. That port forwarding is (typically) intended to be port forwarding from your WAN port to your LAN port of your ISP modem.
Anyway, install dnsmasq on your FOG server and use the config file from this thread: https://forums.fogproject.org/topic/8726/advanced-dnsmasq-techniques for now use the initial post for the configuration. Update the IP settings in the file to point towards your FOG server and then restart dnsmasq.
The reason why sccm is working (probably) because sccm has a built in ProxyDHCP server that is suppling the right bits needed to pxe boot. We’ll use dnsmasq to do the same. dnsmasq will sit quietly until it hears a dhcp discover request from a client asking for a dhcp address, then it will reply as a proxy dhcp server supplying the missing bits. It will not interfere with other types of dhcp requests just pxe boot requests it will reply with what is needed.
-
Thanks for your help but not being a Linux guy I have no idea about how to configure Linux etc
I will just advise my friend to stick to his USB based imaging I don’t think this would be the low support solution I had hoped for
Cheers
-
@KeithDib I’m having a hard time understanding what the end goal is here.
We really are trying to help and it seems you’ve already all but thrown in the towel on this.
Port Forwarding is NOT pxe boot options. So I’d recommend removing those options from your router.
Port forwarding on a router is used to forward internet traffic to your designated place. Most routers don’t do native “loopback” which would be required in how you’ve setup your port forwarding. “Loopback” as I’ve termed it here means, internal sources are going to the “internet” source and being looped back in through the port forward just as normal internet traffic would flow.
Your PXE options are not port forwarding. I know I already said this, but I cannot stress that enough. You almost certainly are not wanting people requesting your internet IP address to be able to boot from your fog server.
-
@Tom-Elliott said in DHCP Issue:
You almost certainly are not wanting people requesting your internet IP address to be able to boot from your fog server.
It’d be easy to do a DOS attack via a simple script if that were the case.
-
As I say it is PXE options and does work if using a Windows server as per my SCCM box, this is not running either dhcp or dns, I leave that to the router.
I guess you could say I have thrown in the towel, but not with FOG as a whole only in the project I am working towards. I need to build a very low maintenance (as I’ll will be maintaining it) imaging solution. I fear I would spend more time at the friends than I do on my own systems
I work in IT on MS systems, including SCCM so I have a few test beds all running on VM systems, on a few different hosts but all running through the dhcp on the router and have not had any problems with any of them
The support from both you and George has been great but as I say my knowledge of Linux is very limited and I don’t want to be back here asking basic questions on a daily basis
-
@KeithDib As @george1421 suggested, the only reason SCCM is working is not because of your PXE Options themselves. Your forwarding rules will work, kind of, but it’s more likely SCCM is working because it’s got a “proxyDHCP” layout built in. I wouldn’t be surprised if you removed the port forward and SCCM still works.
-
That said, you don’t need the port forward to do the work, you can actually install dnsmasq and configure your FOG Server to also respond as a proxy server. This would allow your devices to boot and for you to leave your router completely untouched.
-
I understand what you say but the SCCM has nothing like that, in fact it needs the same 67,68,69 set up in dhcp,
As I say in Linux virgin so I looked up a few posts about setting up but on Georges post it seems you need to recompile stuff to get it going, not enough free time to learn that for Linux , I’m at that age for everything new I learn something is lost lol
-
@KeithDib While the ports you’re discussing are correct port forwarding is not how you address the problem. Port forwarding is NOT intended to handle internal requests for information. All port forwarding is doing is forwarding traffic from a designated part and source IP and forwards it to the defined system. Then that other system can handle the information to be returned to the requestor.
The dnsmasq stuff isn’t that hard and you don’t have to learn all new stuff. It’s pretty much a step by step guide. While there is the “off chance” you can learn something, I don’t think it would be overly time consuming, and I’m always willing to help when you run into issues.
We’re trying to help you get FOG working in your environment with as little work as possible based on the information we have. If you don’t feel the need/want to perform the actions, that’s up to you. Just know we’re still here trying to help you succeed in your project.
-
I may have a new way to do this, strange as it may sound I forgot one of my NAS boxes can also handle my DHCP, so i need to reconfigure the network when i get some free time