FOG Client On Multiple Subnets
I’m getting straight to my problem.
We have FOG 0.32 on a CentOS (latest version) VM and we have set it up to work on multiple subnets.
I’ll be giving you numbers, so you can understand.
The server itself is on [B]subnet 48[/B]. The [B]other subnets[/B] we use it on is [B]145, 146 and 147[/B], by using forwarding via some firewall rules and it works fine for imaging. In that essence it doesn’t work on all the subnets at the same time, but it does work on one at a time. Let me also note that subnet 48 is on one NIC and we switch the other one on a second NIC.
[U][B]So here is our problem:[/B][/U]
We have installed the FOG service in the image we deploy, but it doesn’t seem to be able to communicate with the server. The IP we have set during installation is the one the server is on at all times (subnet 48), so that we wouldn’t have any problems when switching subnets. If the target machine is on subnet 48, it can talk to the server normally. If we change the ip in the FOG client settings to say subnet 145, again, it doesn’t work on 146 and 147.
So, is there a way to make the FOG service work on all subnets ?
Thanks in advance !
Windows Firewall is disabled. There are Windows 7 computers on the same subnet as the server which have working FOG services so the antivirus is not blocking the FOG service.
Unfortunately, the command recommended by Jose did not help, though I appreciate the ideas.
I’ve come across a few other threads where people have similar problems, but I haven’t seen any direct solutions related to this specific Windows 7 subnet issue. I’ll keep working on it though.
Windows Firewall issue??? Antivirus Blocking the FOG Agent on the computers??? Other security software on the computer?? Security Policy??
There is a bung in Windows 7 in which it “thinks” there is no Internet connection, and some applications use that information to determine if there is network connectivity at all. There are some fixes like this one for Windows 7:
open cmd as Administrator and run:
netsh int ip reset c:\resetlog.txt
This command has resolved problems for applications such as One Note, and other apps that complain that DNS resolution is not working… When this happens and we open any web browser, we can go out to the internet no problem. Still some applications “respect” what Windows 7 says with the “No Internet Access” thing…
Hope this helps…
Computers running XP have no problems with the FOG Service connecting on any subnet which suggests the server could communicate with all computers on all subnets previous to adding Windows 7 systems to our network. Furthermore, host registration and imaging works for ALL computers regardless of operating system which suggests the server can STILL communicate with all computers on all subnets.
For some reason, though, the FOG Service specifically installed in Windows 7 does not communicate with the FOG server when on subnets different from the server. And just to note, there are computers running XP with FOG Services working correctly on the same subnets as computers running Win7 with FOG Services not working.
I would look into port trunking the port on the switch where the fog server is connected. This way the server could communicate to all client computers in your subnets.
We have a similar problem to this.
We have FOG 1.1.0 and Ubuntu 12.4 working over multiple subnets. We have a couple models of computers running Windows XP and a few models running Windows 7 (recent OS addition to our network).
PXE booting and imaging works great for all machines. After imaging any machines running XP, the FOG service normally reboots the machines to change the computer name to match the registered host name which works across all subnets. After imaging the Win7 machines, we expected the same routine, but for an unknown reason, only the FOG service on the computers on the same subnet as the FOG server can communicate with the FOG server. All other Win7 machines on different subnets give constant error messages in the log file of:
[CODE]7/31/2014 6:15 PM FOG::GreenFog Sleeping for 1 minute.
7/31/2014 6:16 PM FOG::TaskReboot Attempting to connect to fog server…
7/31/2014 6:16 PM FOG::DisplayManager Attempting to connect to fog server…
7/31/2014 6:16 PM FOG::UserCleanup Failed to connect to fog server!
7/31/2014 6:16 PM FOG::UserCleanup The server committed a protocol violation. Section=ResponseStatusLine
7/31/2014 6:16 PM FOG::UserCleanup at System.Net.WebClient.DownloadDataInternal(Uri address, WebRequest& request)
at System.Net.WebClient.DownloadString(Uri address)
7/31/2014 6:16 PM FOG::AutoLogOut Sleeping for 1 minute.
7/31/2014 6:16 PM FOG::HostnameChanger Attempting to connect to fog server…
7/31/2014 6:16 PM FOG::PrinterManager Attempting to connect to fog server…
7/31/2014 6:16 PM FOG::DisplayManager Failed to connect to fog server!
7/31/2014 6:16 PM FOG::DisplayManager The server committed a protocol violation. Section=ResponseStatusLine
7/31/2014 6:16 PM FOG::DisplayManager at System.Net.WebClient.DownloadDataInternal(Uri address, WebRequest& request)
at System.Net.WebClient.DownloadString(Uri address)
Where I work, we have 12 subnets.
We only have the one FOG Server and all subnets can communicate and work with the main FOG Server at the same time.
All of our machines are also communicating to the FOG Server using the same IP for FOG and communicate just fine.
Something tells me the way your network is setup, you can’t communicate to FOG.
The way we have done our setup is through extensive use of the ip-helper command.
Our routing switch (our gateway for each of the subnets) simply point back to our DHCP server. Depending on which system is where our Windows DHCP server distributes to required IP on the proper subnet. From the DHCP server, it tells (for bootup) option 66/67 to point at our FOG Server.
Because we’re using a centralized DHCP server and FOG system we don’t see any issues. My guess in your case is this is possibly the intention, but hasn’t been realized quite yet?