Wake-on-LAN Software Explained: How Magic Packets Work and How to Set Them Up Across Subnets

Wake-on-LAN (WoL) lets IT teams patch, back up and manage machines without anyone pressing a power button. Typical uses include overnight patching of office desktops, waking a workstation before a remote session, and powering on lab or kiosk machines on a schedule. Done well, it saves energy and avoids unnecessary trips to the office.

The idea is old and simple, but the details trip up many admins: firmware settings, operating system power states, VLAN boundaries and firewall rules all decide whether a packet wakes anything. This guide explains the mechanism, the setup steps, the cross-subnet problem and where management platforms fit in.

WoL packets are sent over UDP, defined in IETF RFC 768, and are usually addressed to UDP port 7 or 9, which the IANA port registry lists as echo and discard. Because the packet is unauthenticated, treat the ability to send one as a management privilege, in line with access control guidance in NIST SP 800-53, and restrict it accordingly.

How does Wake-on-LAN work?

A magic packet is a frame that contains 6 bytes of 0xFF followed by the target network card's MAC address repeated 16 times, 102 bytes in total. The adapter stays powered in a low-power state, watches for this pattern and signals the motherboard to start.

Because the machine is off, it has no IP address to answer to. The sender therefore addresses the frame by MAC, usually inside a UDP datagram sent to the broadcast address of the local network. The network card checks every frame it receives, so a matching broadcast is enough.

• Frame contents: 6 x FF, then the MAC address 16 times; many tools also support an optional password (SecureOn) on adapters that allow it.
• Transport: UDP broadcast to port 7 or 9 is common, but the frame itself is what matters, and tools may also send raw Ethernet frames.
• Direction: the packet is one way. The target does not reply while it is waking, so confirm success with a ping or agent check-in.

What do you need to enable Wake-on-LAN?

Wake-on-LAN needs four things: a motherboard and network adapter that support it, the option turned on in firmware, the right power settings in the operating system, and a wired connection that keeps the adapter powered. Missing any one of them is the usual cause of failure.

Step 1: Firmware settings

Open the BIOS or UEFI setup and enable options named Wake on LAN, Power On by PCI-E, or similar. Disable deep power-saving modes (such as ErP or EuP) that cut power to the adapter when off.

Step 2: Operating system settings

• Windows: in Device Manager open the network adapter properties, enable Wake on Magic Packet on the Advanced tab, and on the Power Management tab allow the device to wake the computer and, if desired, only on a magic packet. Disabling Fast Startup helps when waking from a full shutdown.
• Linux: use a tool such as ethtool to check that the adapter reports magic packet wake support (the "g" flag) and enable it, then make the setting persistent with your network configuration.
• macOS: Wake for network access in energy settings covers sleeping Macs; wake from shutdown is generally not supported.

Step 3: Record each machine's MAC address

Collect MAC addresses before machines go to sleep. Inventory and monitoring platforms record them automatically, and a spreadsheet is fine for small offices. Store the subnet and broadcast address next to each entry.

Why does Wake-on-LAN fail across subnets and VLANs?

Routers do not forward broadcast traffic by default, so a magic packet sent from one subnet never reaches machines on another. You solve this with a directed broadcast, a relay agent on the target subnet, or a management platform whose agent sends the packet locally.

• Directed broadcast: some networks forward packets aimed at the target subnet's broadcast address, but many administrators disable this for security reasons.
• Local relay agent: an always-on machine or server on each subnet that receives a command and sends the magic packet locally. This is the most reliable pattern.
• Router or switch features: some network gear can forward specific UDP broadcast ports to a target subnet. Restrict such rules to port numbers and sources you control.
• Wi-Fi limits: most WoL setups require Ethernet because wireless adapters rarely stay powered when the system is off.

Pair WoL with a network monitoring tool so you can confirm that machines actually came up, and review subnet design with the help of our network admin tools guide.

Which Wake-on-LAN software and platforms should you consider?

Three types of tools send magic packets: free command-line and desktop utilities, wake features built into remote management platforms, and scheduled jobs in endpoint management suites. Pick based on how many machines and sites you manage.

• Standalone utilities: small desktop or command-line senders suit home labs and small offices. Compare them in our review of free Wake-on-LAN tools.
• RMM platforms: remote monitoring and management products can power on endpoints before patch windows. Candidates on SaaSPodium include NinjaOne, Atera, Datto RMM, N-able N-central and Pulseway. Wake support and its exact behavior vary by product, so confirm it in a trial.
• Network and endpoint suites: larger environments often tie wake to patch deployment or maintenance windows.

Evaluate a tool by testing it on your own network: one machine on the same subnet, one on another VLAN, one at a remote site. See the full RMM software category for more options.

How do you troubleshoot a Wake-on-LAN packet that does nothing?

Check in order: is the packet sent, does it reach the subnet, does the adapter see it, and does the board act on it. Capturing traffic answers the first three questions quickly, and a packet analyzer shows whether the 102-byte pattern arrives.

• Use a packet analyzer such as Wireshark (also listed as Wireshark on SaaSPodium) to capture on the target subnet and confirm the magic packet arrives.
• Confirm the adapter link light stays on when the machine is off. If it goes dark, a firmware power-saving setting is cutting power.
• Test from a machine on the same switch first, then add routers and VLANs one hop at a time.
• The adapter acts before the OS loads, but the sending host's firewall or endpoint protection can still block outgoing UDP, so check it.
• If wake works from sleep but not from shutdown, revisit Fast Startup, hybrid shutdown and BIOS power states.

Security and energy considerations

Wake-on-LAN has no built-in authentication, so anyone who can send a broadcast on the segment can wake the machine. Limit who may send packets, segment management networks and log wake events. The benefit is lower energy use, since machines can stay off until needed.

• Restrict wake senders to management hosts using access lists.
• Wake machines only inside defined maintenance windows and shut them down afterwards.
• Record wake and shutdown events in your monitoring system for audit purposes.

Multiply by your electricity rate to estimate savings. For example, a desktop that idles at 0.05 kW and would otherwise run 12 extra hours a day over 250 days saves 150 kWh per machine per year.

Frequently Asked Questions

Does Wake-on-LAN work over Wi-Fi?
Rarely. Most wireless adapters are not powered when the system is off, so Ethernet is the reliable choice. Some laptops support a wireless variant, but you should test your specific hardware and access points before relying on it.

Which RMM tools can wake computers remotely?
Several remote monitoring and management platforms offer a wake or power-on action, usually through an agent on the same network. Support varies by product and plan, so verify it in a trial before you choose, and test across your own subnets.

Is Wake-on-LAN secure to use in a company network?
It is unauthenticated by default, so treat it as a management function. Restrict senders with access lists, keep it on management networks, log wake events and only enable it on machines that need scheduled power-on.