Wake-on-LAN: How to Set It Up and Why It Fails Across Subnets

Updated: October 2026

Patch night is scheduled, the updates are staged, and half the fleet is switched off. The PCs that are asleep can be woken over the network, and the ones that were shut down usually can't. Here's how Wake-on-LAN works, how to set it up on Windows machines, and why it falls apart the moment the packet has to cross a router.

What Is Wake-on-LAN?

Wake-on-LAN (WoL) turns on a computer from a low-power state when its network card sees one specific packet. The card stays partly powered while the PC sleeps. It ignores ordinary traffic and waits for its cue.

That cue is the magic packet. Microsoft's documentation describes it plainly: a broadcast frame with 6 bytes of FF, followed by the target's 48-bit MAC address repeated sixteen times, 102 bytes in total. No IP address inside, no password, no port the PC listens on. The card matches its own MAC and signals the motherboard to power up.

Wake tools usually wrap that payload in a UDP broadcast to port 9, sometimes port 7. The port doesn't matter to the network card, since it reads the frame, not a socket. It matters to your firewall rules and to anything that relays the packet between networks.

Two consequences follow from the design. You need the MAC address of the exact adapter you want to wake, not the Wi-Fi card or the dock. And because the packet is a broadcast, it only travels as far as the local network segment unless you do something about it.

How to Set Up Wake-on-LAN on Windows

Three layers have to agree before a PC will wake: the firmware, the network adapter driver, and Windows power settings. Miss one and the packet arrives at a card that isn't listening.

Firmware. Enable the wake option in the BIOS or UEFI setup. Vendors name it differently: Wake on LAN, Remote Wake Up, Power On by PCI-E, Resume by LAN. Look for deep-sleep or energy-saving modes too, since some cut power to the network card completely when the PC is off. If you're already in those menus for other work, our guide to BIOS settings covers how to find them on the main vendors' boards.

Adapter driver. In Device Manager, open the network adapter's properties. On the Power Management tab, tick "Allow this device to wake the computer" and "Only allow a magic packet to wake the computer". The second box stops random network chatter from waking machines at 3 a.m. On the Advanced tab, set Wake on Magic Packet to Enabled if the driver exposes it.

Scripted. On a fleet, clicking through Device Manager doesn't scale. PowerShell covers the driver side:

powershell
Get-NetAdapterPowerManagement -Name "Ethernet"
Set-NetAdapterPowerManagement -Name "Ethernet" -WakeOnMagicPacket Enabled
powercfg /devicequery wake_armed

The last line lists every device currently allowed to wake the machine. If the Ethernet adapter isn't in that list, the PC won't wake from the network.

Why Wake-on-LAN Stops Working After Shutdown

This is the failure that shows up on patch night. The settings are right, the PC wakes fine from sleep, and after a normal shutdown it stays dark.

Microsoft documents the reason. The default shutdown in Windows 10 is hybrid shutdown, also called Fast Startup, which puts the machine into S4. Microsoft's Wake on LAN article says WoL from S4 or S5 is unsupported in that case and that network adapters "are explicitly not armed" for it. WoL is supported from sleep (S3) and from hibernate when a user explicitly chooses it. Windows 11 keeps Fast Startup on by default, so the same rule applies there.

There's a footnote in the same article. Some firmware can arm the network card for wake from S4 or S5 without Windows being involved. That's why WoL after shutdown works on some models and fails on others in the same office.

You have three options for machines that need to wake after hours:

1. Leave them asleep, not shut down. Sleep is the state Windows supports for WoL.
2. Turn off Fast Startup on those machines, which Microsoft doesn't recommend in general but which lets supported firmware wake from a full shutdown.
3. Rely on firmware. Test per model.

Laptops with Modern Standby add their own rules. They idle in a low-power S0 state instead of classic sleep, and Microsoft notes that USB-attached wired adapters can lose wake capability during standby. On Windows 11 24H2, Modern Standby also disables most wake sources when it detects excessive battery drain.

Model-specific failures are common enough to have their own threads. This one tracks WoL failing on newer Dell OptiPlex models with Intel I219-LM adapters:

Why Wake-on-LAN Fails Across Subnets

The magic packet is a broadcast. Routers don't forward broadcasts, so a packet sent from the admin VLAN never reaches the finance VLAN. WoL works on the bench and fails in production, where every floor has its own subnet.

There are three ways around it.

Subnet-directed broadcast. Send the packet to the target subnet's broadcast address, for example 10.20.30.255. The routers carry it like a normal packet until the last router turns it into a local broadcast. That last hop only happens if you enable directed broadcasts on the router interface. It's off by default for a reason: RFC 2644 (August 1999) made "disabled" the required default after Smurf attacks used directed broadcasts to amplify floods. If you turn it on, do it on internal interfaces only and restrict which source can send.

A relay on the router. Many routers and layer 3 switches can forward a specific UDP port to a subnet's broadcast address. It's the same mechanism with a narrower rule, because only port 9 from your management host gets through.

A sender inside each subnet. Put the wake job on a machine that's already on the target network, such as an always-on server or another managed PC. The packet never crosses a router, so no router changes are needed. Configuration Manager has worked this way since version 1810: it finds a client that's awake on the target subnet and has that client send the magic packet. Microsoft lists 802.1X network authentication as a limitation of that feature, which matters on wired networks with port authentication.

One thing not to do: forward the WoL port from the internet to the LAN. If someone needs to wake a machine remotely, they connect to the VPN first and send the packet from inside. Our post on port forwarding covers why an open inbound port is the wrong tool here.

This r/sysadmin thread describes the harder version of the problem: clients spread across several sites and networks, with 802.1X in place.

Wi-Fi, Docks and Laptops

Wake-on-LAN was built for wired networks. Wi-Fi has a variant, Wake on Wireless LAN, but the adapter has to stay associated with the access point while the PC sleeps, and that support varies widely by card and driver. Plan patch windows around wired machines and treat Wi-Fi wake as a bonus.

Docks cause their own confusion. A laptop on a USB-C dock uses the dock's network adapter, and some docks pass the laptop's own MAC address through instead of their own. Your wake tool needs the MAC that's on the wire at that desk. Check it on the machine with Get-NetAdapter while it's docked, not from an old inventory export.

Using Wake-on-LAN for After-Hours Patching

Patching at night only works if the machines are on at night. WoL closes that gap without asking staff to leave PCs running.

A workable routine looks like this. Keep an inventory of wired MAC addresses per site. Wake machines in batches, not all at once, so the network and the update source don't get hammered. Give each machine time to boot and check in, then run the patch job, confirm the reboot, and let it return to sleep. The next morning, powercfg /lastwake on a sample of machines shows what woke them.

The machines that didn't wake are the useful output. Chase them by model, since the cause is usually firmware or Fast Startup, not the network. Our patch management roundup compares tools that schedule this kind of window. With OpenFrame, you can run the Get-NetAdapterPowerManagement check as a script across a client's devices and collect the output, so the unarmed machines show up before patch night instead of after it.

TroubleChute's walkthrough covers the Windows side step by step, including the network adapter settings:

Wake-on-LAN Troubleshooting Checklist

When a machine won't wake, work from the cable up:

1. Right MAC. Confirm the MAC belongs to the wired adapter in use, not Wi-Fi or an old dock.
2. Link light. With the PC off or asleep, the port's link light should stay on. Dark means the card has no power, so check firmware deep-sleep settings.
3. Firmware. The wake option is enabled in BIOS or UEFI, and it survived the last firmware update.
4. Driver. powercfg /devicequery wake_armed lists the adapter, and magic packet wake is enabled.
5. Power state. Test from sleep first. If sleep works and shutdown doesn't, it's Fast Startup or firmware.
6. Packet delivery. Capture on another machine in the same subnet and filter for UDP port 9. No packet means the problem is routing, not the PC.

The Short Version

Wake-on-LAN wakes a PC when its network card sees a magic packet with its MAC address. It works reliably from sleep, unreliably after a Fast Startup shutdown, and not at all across routers until you add a directed broadcast, a relay, or a sender inside each subnet. Set the firmware, driver and power state together, test per model, and keep the wake traffic inside your network.