Connecting FOG to Virtual Machine

[agray]

@Sebastian-Roth Here is the .pcap file of my VM attempting to PXE boot from the host point of view: https://drive.google.com/file/d/1zbHmSCoOC2tzi8xp5EVnj6KrhQwvSOcU/view?usp=sharing

After attempting to PXE boot with host off AD Domain. I’m getting a nicer looking wireshark output but still no dice on the PXE boot: https://drive.google.com/file/d/11GiICfArOKqcFUWdF6hQHV51r8oHTebV/view?usp=sharing

[Quazz]

@agray I’m assuming that if it’s on the domain that there already is a DHCP server on the network and that it is conflicting with the FOG one. Haven’t taken a look at the PCAP (don’t have time), though

[agray]

@Quazz Our domain is strictly static and FOG is isolated completely off it. A rough topology of our FOG network is on the second page of this thread

[Quazz]

@agray Yes, and around that same area it is mentioned that there is a DHCP server on the router?

[agray]

@Quazz That would be the FOG Server.

[Quazz]

@agray Just looked at the PCAP.

Your router is also dishing out IPs at 192.168.1.1 which is causing the conflict as suspected.

You can check it out by installing wireshark and typign in bootp as filter

If you can’t turn off or modify the router DHCP, you will need dnsmasq proxyDHCP on the FOG server.

https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq

[agray]

@Quazz said in Connecting FOG to Virtual Machine:

our router is also dishing out IPs

I turned off the DHCP server option on the router and it still didn’t fix the problem, I took a pcap if you’d like it.
It seems odd to me that my router would only be messing up the VM though. Never had an issue with physical machines and the router.

[george1421]

@agray OK I also looked at the second pcap the first one didn’t have anything useful that I could see.

In the second pcap you have 2 dhcp servers responding to the target computer. The first one is 192.168.1.1 and the second is 192.168.1.90. .90 appears to be a fog server since its handing out the right next server and boot file name. The issue is that it appears to be configured as a full dhcp server since its also handing out an IP address which is in conflict with what your 192.168.1.1 dhcp server is doing.

Looking at the pcap more the .90 dhcp is winning the election process because its responding with a ACK packet.

I want you to follow this tutorial when creating your PCAP so we only get the info we need and not extra internal messages: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

[george1421]

@agray I guess the question needs to be asked are you running the dhcp server on the fog server for a reason in addition to the dhcp server on your router?

Which dhcp server do you want to run? I understand the goal is to pxe boot your clients but there is a number of ways to go about it, depending on what your main goal is.

[agray]

@george1421 said in Connecting FOG to Virtual Machine:

unning the dhcp server on the fog server for a reason in addition to the dhcp server on your router

I was unaware the FOG machine had that capabilities honestly. With that now being known, I feel it would be easier for FOG to handle everything since it was overwriting the router anyway.
I did disable the DHCP server capabilities on the router to hand it off to FOG.

Let me restart everything to make sure that the server is not handing out IPs anymore and I’ll post another pcap file here if the PXE boot fails again: https://drive.google.com/file/d/1R7fLhBw7umZ6A_gEZ5rvneKQX0Y0Mw_6/view?usp=sharing

[george1421]

@agray I would say that looks like a normal pcap except I don’t see it transferring the file. If you look at the pcap we see a Discover, Offer, Request, and ACK. Then the client request the file size of undionly.kpxe and then requests the file… from there it stops. Then after 30 seconds or so it sends out a discover again and the fog server responds with an offer but then it cycles between discover and offer.

So my question is this: Does this happen with the VM only, where a physical computer boots normally?

I might understand what is happening but not the why just yet. I did notice that the mac address of the device in your picture doesn’t match the mac address of the pxe booting device in the pcap [08:00:27:8a:86:44].

[agray]

@george1421 said in Connecting FOG to Virtual Machine:

Does this happen with the VM only, where a physical computer boots normally?

If I’m understanding correctly, my physical machine boot perfectly into the FOG GUI it gives me after PXE.

@george1421 said in Connecting FOG to Virtual Machine:

the mac address of the device in your picture doesn’t match the mac address of the pxe

It changed because i had to rebuild the VM. I was originally logged into the Network admin account and, since I had to get off the domain, I exported the VM and brought it back up in the local admin account.

[agray]

To cover all our bases, does my VM set up look correct?

[george1421]

@agray When you setup vitrualbox did you add in the virtualbox extension pack? The reason why I ask is that your network settings appear correct. I’d have to look at my home linux laptop to be 100% absolute. I know pxe booting does work with virtualbox into fog because I do testing at home often.

This appears to be more of an issue with virtualbox than FOG since your physical machine works correctly.

[agray]

This post is deleted!

[agray]

@george1421 I tested uninstalling VirtualBox and it didn’t do anything. I’m going to attempt using Hyper-V and will get back to you with results.

[Sebastian Roth]

@agray This seems strange! What host OS do you have VirtualBox installed on? I am using VirtualBox on Debian Linux since years working great for PXE booting VMs with FOG.

I’ve had a look at the PCAP file as well. To me it looks like the following is happening. As seen in the picture of the initial post the “Intel UNDI PXE stack” comes up and requests an IP and PXE infos from the DHCP, gets and answer, loads undionly.kpxe via TFTP (note here that we only see the initial read requests as the rest is on random high ports and probably not seen by the filter used to strip down the PCAP!) and then iPXE itself goes for another round of DHCP (seen in the DHCP discover packets as iPXE sends DHCP option 175).

Now DHCP server responds but the client/iPXE keeps sending out DHCP discover packets. I guess that iPXE is somehow not able to receive those answers. Can you please hit s as suggested to get to the iPXE shell after DHCP failed and run the command ifstat. Take a picture and post here.

Now you can try to use a different network interface card in your VirtualBox settings. Try out different Adapter Type settings. As well you can try using other iPXE binaries. On your FOG server edit /etc/dhcp/dhcpd.conf (might be a bit different depending on the Linux OS you have) and change undionly.kpxe to ipxe.pxe for example. Restart dhcp service (systemctl restart isc-dhcp-server or similar) and see if that makes a difference.

[Quazz]

@agray Good shout, I get the same problem on the ICH9 chipset, the PIIX3 one works fine though.

[agray]

@Sebastian-Roth said in Connecting FOG to Virtual Machine:

What host OS do you have VirtualBox installed on?

Windows 10

@Quazz said in Connecting FOG to Virtual Machine:

the PIIX3 one works fine though.

I changed my chipset to PIIX3 and it works! Thank you guys for the long headache relief!

[agray]

This post is deleted!