@cf20corvuss Well lets think about this for a minute.
The screen shot you provided looks like the fog ipxe boot loader. If it is we can then make a few assumptions. My hesitation ATM is that some hypervisor’s use iPXE as their pxe boot rom (Virtual box being one). If we work under the assumption that the screen shot shows the FOG iPXE boot loader we know this.
The target computer can speak to the FOG server. We know then because the iPXE boot loader was sent by the FOG server and received by the PXE booting computer. The target computer is getting a dhcp address from some place AND that dhcp information told the client where to get the iPXE boot loader from. So we know that dhcp is working. We know that iPXE has the proper driver for the network card in the pxe booting computer because iPXE sees the mac address of the network adapter.Where we typically see this is with the network configuration where Spanning Tree is enabled but one of the fast spanning tree protocols are not used. Standard spanning tree will listen for a loop back interface for the first 27 seconds a link is active then start forwarding data. With imaging when the PXE ROM hands off control to iPXE, iPXE will reset the network interface causing the link to drop briefly as iPXE boots. Well this link briefly dropping causes the spanning tree counter to reset. So when the target computer is trying to get an IP address again, spanning tree is still listening for a loop back. By the time standard spanning tree starts forwarding data again, iPXE and FOG have already given up.
You can test this in a physical world by putting a dumb unmanaged switch between the building network and the pxe booting computer. This unmanaged switch will keep the building switch from seeing the brief link drop. Most cheap switches do not support spanning tree. So its all good there.
Now NAT and imaging do not go together with FOG. Everything needs to be bridged with real addresses for FOG imaging to work.