Ghost Solution Suite

We can't get machines to wake when they are located in different subnets. All the typical prerequisites for WOL have been met. It works fine when the console and workstation are in the same subnet. We have version 8.3 and did not upgrade (saw the thread "WOL Stops Functioning")

We have a Cisco network, vlans, subnets, fairly complex. Multicast is enabled and working fine. What else should I be checking? Solar Winds applet can send a magic packet successfully across subnets from our console server. What's different about the way Ghost is trying to wake machines?

Any insights would be appreciated.

The main thing with GSS is that the server encapsulates the magic packet data in a normal UDP packet, and tries to get that routed to the right network segment by forming a subnet-directed IP broadcast. We don't send to a specific unicast IP - as the Solar Winds tool docs describe - because in a switched environment with DHCP it's a somewhat hit-and-miss thing. If the IP of a powered-off machine has been reassigned, there's no way to get the magic packet through to the right switch port other than using a subnet-level broadcast, so we just use that.

If the Solar Winds tool is using normal unicast IP encapsulation, that could be the key difference between it and GSS. Some companies do disable IP subnet-level broadcast at their routers.

It should be easy to use a packet sniffer on the GSS broadcast packets, they are a lot easier to capture than multicast packets because they aren't as heavily filtered at the switch level. In theory, any machine on the same subnet as a client ought to be able to see the wake-on-LAN packets coming in. I'd run Wireshark on the server and on a running client machine in the same subnet as one you have powered off, and see whether our WOL traffic is making it through the network at all.

If not, leaves us with a hard choice. I could recode the WOL code to also send additional WOL packets to the last known specific IP of the client, as a fallback - it's not really suitable to do that as a primary technique but I can see that being the only option for customers operating in networks where there is a blanket policy against enabling subnet-level broadcasts.

Any ideas what other organizations do to handle this situation? We can't be unique in not having broadcast enabled across subnets. Rewriting the software seems like a drastic step.

> Any ideas what other organizations do to handle this situation?

I don't, although I'd love to hear more people who do administer networks as well as the end PC's offer their opinions.

I can speculate, however; these days most routers or managed switches let people create far more sophisticated traffic-filtering rules than they did 10 years ago. It's both technically possible (and really, I think desirable) to apply a subnet of the of perimeter filtering rules internally as a defense-in-depth strategy, but these days you can now do that without disabling useful internal-to-internal traffic.

> Rewriting the software seems like a drastic step.

It's a relatively small rework to send an additional unicast WOL packet to the last known client IP, and comparatively easy to test. Even though unicast Wake-On-Lan won't work reliably, I figure it's better to try it as a fallback than just not do anything.

In fact, I've just added this in the pre-GSS2.0 code, and it's an easy thing to backport to GSS1.1 - once this passes some basic internal testing over the next few days I could make a test build of the GSS1.1 ngserver.exe executable for you to try, perhaps next week.