I’m implementing wake on LAN via Big Fix, but it isn’t working at remote VPN sites. These sites have a Cisco router. I know it does work because when I test it in the local office, it does work.
The remote site has UDP 52311 open to the forwarder because the forwarder receives the UDP when they have an action to take, so I am assuming that they are getting the UDP packet to send the “magic packet” to the powered off computer. All clients are on version 7.1. What am I missing?
How are you sending the wake-on-lan to the client on the VPN? Using the “wake-on-lan” in the console? That will require your network gear to properly forward the UDP packet from your console station all the way to the client on the VPN. I have found that problematic because it depends on the version of cisco cat/ios running on the gear at each hop. One wrong move and your packet loses its magic.
If you have licensed the Power Management site addon, the wake-on-lan wizard works much more reliably and is not dependent on your network gear. Unfortunately, Bigfix charges for it as an addon. I wish they didn’t since the basic wake-on-lan tools are not sufficient and patch management is so much easier with wol.
Yes, I am using the right-click WOL option on the computers tab within the console. What do you mean by “That will require your network gear to properly forward the UDP packet from your console station all the way to the client on the VPN” ? When I take an action on a computer, the Big Fix server sends a similar UDP packet to the recipient that tells it to go look for a task to take. If that works, why wouldn’t the the UDP for wol work? Keep in mind, the “magic pack” comes from the Forwarder on the local subnet of the recipient, no the Big Fix server or console PC.
Yes, I think we do have the power managment site because I remember seeing the Wake on LAN wizard. I will try that to see if it works better.
It confirmed my understanding of how bigfix is doing this is out of date. My first post was based on the old functionality talked about in that article.
So, I’m not sure what’s going on. Hopefully the wake on LAN wizard worked for you, you should be set. Otherwise, not sure what I can suggest. Sorry.
You are using the “Send Wake on LAN Request” option from the right-click menu, correct?
Here are some things to check (I know you have already done many of these, but I will list them anyway):
Your server/console/relays/agents must all be 7.1.
You need to have clicked the “enable wake on lan” in the power management dashboard.
You need to have enabled wake-on-lan forwarders using the Task in the Power Management site (you can do this to all your computers unless you have large subnets (bigger than Class C).
After agents become wake-on-lan forwarders they need to register with their relay before it knows about being a wake-on-lan forwarder (by default it will occur every 6 hours or you can send a refresh to the agents to make it happen sooner).
There needs to be powered-on wake-on-lan forwarder computer (“waker-upper” for lack of a better term) in the same subnet as the computer-to-be-woken.
The waker-upper needs to be able to receive UDP messages from its relay.
The computer-to-be-woken needs to have wake-on-lan enabled (from powered off or from standby depending on its state)…
To troubleshoot further:
In Web Reports, you will see a “Wake from Web” Report that will try to wake a computer up and it will notice common wake-on-lan issues. Try to see if this works…
If you think maybe the computer isn’t enabled for wake-on-lan, you can test this from a computer in the same subnet with any wake-on-lan tool you can find. We have a wake-on-lan command line tool (which you can find here http://software.bigfix.com/download/bes/misc/bes-wol.zip). You need to know the mac-address of the computer.
thanks for the info. After some more troubleshooting using Wireshark, the problems looks to be this: When the UDP packet is sent, the source is actually the relay of the forwarder, not the forwarder, and the destination is the powered down computer. However, that packet is transfered through the forwarder so that it is on the same subnet as the powered down computer. What this is called is IP Source Routing and we block it on our firewall because it could be used maliciously. Sending a pakcet via an alternate route that includes devices other than the source and destination are not a good idea. That is why it worked within the office but not out to the remote sites. Wheather this will be allow or not is another story.
I am not sure I have a complete understanding of this setup, but here is what I would expect:
You send a wake-on-lan to powered-off computer X
The server sends an HTTP request to the relay to initiate a wake-up request
The relay sends a wake-up request (let’s call this the BESWOL UDP packet) to any WoL forwarder on the same subnet as computer X (possibly including computer X).
Any computer receiving the BESWOL UDP packet will send a WoL (“magic packet”) to Computer X (note that the agents have optimizations not to send too many WoL packets if they notice other agents already sent the packet).
So the question for you is whether you actually saw the packet described in #3 or #4?
When I ran wireshark on the forwarder, it received the BESWOL UDP Packet from the relay as expected. However, that packet had a destination IP of computer X and a source IP of the relay and was being sent through the middle man (the forwarder). I understand why that is, but as I am being told from our security department, when a packet is sent from a source to a destination through a middle man, that is known as IP Source Routing. As you can understand, this could be used in a malicious way (sending a packet to a destination that isn’t really the destination) and we block IP Source Routing within our network.
What I am not able to understand is why is the relay sending the packet with a DSTN of computer X when shouldn’t the DSTN be the forwarder, then the forwarder send the “magic packet”?
To answer your question #4, I don’t remember if I saw the "magic packet’ within wireshark.
By forwarder, you mean a BigFix Agent computer? I don’t believe it works like this… The relay should send the BESWOL UDP packet from the relay (source) to the computer Y (destination) – this is very similar to any other BigFix UDP packet that notify about new action. Contained in the UDP packet is information that tells the computer Y to wake up computer X with a magic packet.
So I am a bit confused about what you saw… I will double check with our developers to make sure there isn’t something I am missing about the way we construct the BESWOL packets.
If the Relay sent the packet to Computer Y, then wouldn’t that mean the “destination IP” (which I assume you mean is the “destination IP address” in the IP packet) is Computer Y?
Correct. That is the question. Perhaps by sending the packet to Computer Y with the destination of Computer X inside the packet, that is how the relay tells computer Y to send the Magic Packet to Computer X ?
Yes… the internals of the BESWOL packet does contain information for the BigFix Agent about the MAC Address/IP address of the computer to be woken (Computer X)…
But then the question is why does your network devices care? The IP header destination IP is Computer Y and it is a valid UDP packet with our custom payload. Is there some device that is opening our packets and trying to make sense of them (seems unlikely)?
So I guess the question comes back to figuring out who is blocking our packets and why?
But we don’t use “source routing”. We are simply sending a standard UDP/IP packet to computer Y… It contains no special IP forwarding info and routers should think it is a fine and normal packet just like all the other UDP packets we use… It happens to contain the subnet/MAC address in its UDP data segment, but routers shouldn’t care about that…
So do your routers have some special packet scanning heuristics? Or have we misdiagnosed the problem?
I’m going to jump in here as cstoneba is working with me on this issue here. What is throwing an alert is our idp and dropping this packet. At least in our troubleshooting here that is the case. If we are going to discuss specifics here of our configuration I would prefer we created a support ticket and did it in a non public access forum.