How to configure Wake-on-LAN for a server

You can achieve reliable remote power-on capability for your server through a simple setup. You must configure wake-on-lan using four sequential steps:
Enable power management settings inside the BIOS firmware.
Adjust adapter properties in your operating system.
Collect target MAC and network addressing details.
Dispatch the trigger packet across your network infrastructure.
You need a stable wired Ethernet connection. Wireless connections drop link states during low-power modes and fail to deliver the magic packet reliably.
This simple wol configuration restores server accessibility instantly. Use wake-on-lan to maintain control. This wake-on-lan setup simplifies wake-on-lan hardware control and wol operations.
Enable Wake-on-LAN in BIOS Firmware
You must prepare your server hardware before operating systems load network drivers. The motherboards require explicit instruction to keep integrated Ethernet interfaces active during sleep states.
Configure UEFI Power Management
Reboot your server and press the designated setup key repeatedly. You usually hit Delete, F2, or F12 during the initial boot splash screen to enter UEFI setup. You can locate these menus under section titles like Power Management, System Setup, or ACPI Settings. Navigate straight to the Advanced Power Management screen. You need to enable PCIe Power On, Wake on Integrated NIC, or Resume by LAN options. These settings allow motherboard power circuits to listen for incoming packets.
You must configure wake-on-lan hardware parameters properly at this base firmware level. Disable energy-saving modes that cut voltage to peripheral slots completely. Without proper power, your physical network card cannot process any incoming wake-on-lan frame.
Always connect your server using a physical wired Ethernet cable. Wireless adapters cause severe packet delivery failures during reduced power states. Wireless cards drain unnecessary standby current while attempting to maintain connection with access points. Wired wake-on-lan cards maintain low-power link detection effortlessly without signal loss.
Set Standby Power and Ethernet States
ACPI sleep states dictate how much power your server motherboard consumes during downtime. The wake-on-lan feature operates reliably across S3, S4, and S5 power states.
S4 reduces power consumption to the lowest level by saving volatile memory contents to disk. Some system components remain powered so the computer can wake from input from the keyboard, network, or USB device. S5 performs a complete soft shutdown and requires full boot cycles.
Each power state handles system memory and power allocation differently:
S3 state keeps system RAM powered to retain state data, enabling quick wake-on-lan response times.
S4 state saves RAM memory contents onto storage disks and cuts system board power.
S5 state represents full soft shutdown and requires complete cold boot steps.
Your initial wake-on-lan setup depends on continuous standby voltage on the system card. The ethernet interface card monitors physical ethernet traffic continuously. The adapter parses every ethernet frame seeking a matching magic packet.
When the card identifies the unique wake-up signal, it signals the power supply. The wol controller triggers motherboard startup immediately upon packet detection. Correct firmware setup prevents your port from shutting down during S5 sleep cycles. You maintain reliable remote access when you establish proper wol parameters inside your system BIOS menu.
Verify that your server firmware configuration allows wol triggers to bypass default deep sleep restrictions. This completes your firmware preparation stage. Your server wol adapter now stays alert. The primary wol mechanism monitors incoming frames. Every active wol port processes traffic. This wol process ensures rapid rebooting. Your wol system remains fully operational across your local network environment.
Configure Wake-on-LAN Settings in OS
You must configure wake-on-lan parameters inside your operating system after completing firmware setup. Operating system drivers control adapter states during system power transitions. Proper operating system driver setup ensures your network adapter stays awake and responsive during standby modes.
Set Up Linux WoL Parameters
Linux systems rely on the ethtool utility to manage interface wake behavior effectively. You must verify that your network controller supports remote wake commands before attempting further configuration.
Run
sudo ethtool <interface>to display interface settings.Check the ‘Supports Wake-on’ line to ensure it includes ‘g’.
Check the ‘Wake-on’ line to ensure it shows ‘g’ (not ‘d’).
The letter g enables Wake on MagicPacket messages, while d disables the wol feature entirely. A simple command enables this wol capability immediately on your primary network port:
sudo ethtool -s eth0 wol g
Reboots reset temporary driver changes automatically. You must establish persistent wol settings using standard system management tools to survive host reboots:
Netplan (systemd-networkd): Add
wakeonlan: trueunder your ethernet interface inside/etc/netplan/01-netcfg.yaml, then runsudo netplan apply.NetworkManager: Modify your active connection using
nmcli connection modify "Wired connection 1" 802-3-ethernet.wake-on-lan magic.Systemd service: Create a file named
/etc/systemd/system/wol.servicewithExecStart=/usr/sbin/ethtool -s eth0 wol g, then runsudo systemctl enable wol.service.
These persistent wol definitions force Linux to retain the wake-on-lan state across system reboots. This wake-on-lan routine guarantees reliable wol operation on headless Linux nodes. Proper wake-on-lan setup maintains system wake-on-lan readiness without requiring manual local intervention at any point.
Configure Windows Magic Packet Properties
Windows operating systems require adjustments inside Device Manager and Power Options menus. You must configure driver properties to accept remote wake-on-lan activation signals reliably.
Open Device Manager from the Windows Control Panel.
Expand Network Adapters and open your Network Adapter Properties window.
Select the Advanced tab from the top navigation bar.
Set ‘Wake on Magic Packet’ to Enabled.
You must also adjust Windows power management settings inside the adapter properties window. Select Power Management inside adapter properties. Check the box that allows this device to wake the computer. Require a magic packet trigger specifically to prevent false starts caused by unwanted network broadcast packet traffic.
You must disable Windows Fast Startup to protect power delivery. Fast Startup puts your server into a deep hybrid shutdown state. That deep state cuts electrical power to your physical network interface completely during shutdown events.
Open Power Options inside Control Panel.
Click Choose what the power buttons do from the sidebar menu.
Click Change settings that are currently unavailable to unlock options.
Uncheck Turn on fast startup under shutdown settings.
Click Save changes to apply your updated power profile.
Disabling Fast Startup leaves the wake-on-lan port in an active listening state continuously. The physical wake-on-lan hardware continuously processes incoming background network traffic. The host machine powers on instantly upon receiving a valid magic packet frame from another system. This completes your operating system configuration step for uninterrupted wol service.
Send the Magic Packet to the Server
You can initiate the remote power sequence now that your server configuration is complete. You send a specialized magic packet to trigger wake-on-lan over the network.
Obtain Target MAC and IP Addresses
You must identify the hardware address of the server network interface card before sending any target wake-up signal. Run ip link on Linux or getmac on Windows to record the 48-bit physical address. You need this specific identifier because the host ethernet adapter checks incoming frames for its exact hardware destination.
You also need the destination network broadcast address to transmit the magic frame properly across local network segments. You use local subnet broadcasts when your workstation sits on the same local network. Sending wake-on-lan commands across subnets requires special routing parameters.
When waking a machine on a different subnet, use the broadcast address of the remote network as the destination IP.
Trigger WoL via CLI and Magic Packet Tools
Command line utilities make dispatching a wol magic frame easy from any remote machine. You can use native tools like wakeonlan in Linux or script customized wol options inside PowerShell.
You can issue a terminal command to broadcast this magic packet instantly:
wakeonlan -i 10.8.255.255 0A:00:27:A3:0E:18You can troubleshoot wol delivery issues by capturing active network traffic with packet analyzer software. Wireshark helps you verify that your system transmits the expected magic packet over the physical network connection.
Apply the display filter
wolinside Wireshark to isolate wake-on-lan traffic.Inspect the
wol.macfield name to confirm the correct target MAC address.
This verification guarantees that your data transmission reaches the destination network segment reliably. You now possess a complete wol pipeline to configure wake-on-lan capabilities across your enterprise network using wake-on-lan automation.
Network Configuration and WoL Troubleshooting
Configure Subnet Broadcasts and Static ARP
You optimize network routing parameters to deliver every wake-on-lan frame across subnets. Routers drop Layer 2 broadcasts by default. Enable IP directed broadcasts on routers to pass traffic. Routers clear ARP entries after hosts power off. Map static ARP entries to bind addresses permanently. Transmit a wake-on-lan command using network targeting to simplify wol delivery.
Cause | Description | How Packet Capture Confirms Failure Point |
|---|---|---|
Broadcast not routed across VLANs | A magic packet cannot cross Layer 3 network boundaries. | Run sniffers on target VLAN interfaces to observe packet egress. |
Endpoint configuration issues | Hosts stay dark due to disabled firmware options. | Sniffers show traffic on target segment wires while hosts stay off. |
Wrong egress interface selected | Commands transmit on interfaces in different broadcast domains. | Sniffers show command interface traffic, but hosts stay in other VLANs. |
Configure Cisco routers to forward directed broadcasts across network boundaries. Apply ip directed-broadcast 101 on target interfaces. Restrict UDP traffic using access lists, and apply anti-smurf rules upstream to block ICMP echo requests.
Fix Port Forwarding and Firewall Blocking
Firewalls block traffic across network security boundaries without rules. Establish port settings to permit uninterrupted wol traffic and manage wol settings:
Transmit payloads using UDP port 7 or UDP port 9.
Apply bridge filtering rules because this wake-up signal bypasses firewall inspection.
Restrict IP addresses to prevent unauthorized wake-on-lan attempts on your network.
Router NAT rules require specific network setups to wake servers over the internet:
Forward ports to broadcast addresses if firmware permits broadcast forwarding.
Map static ARP entries for dummy IPs using broadcast hardware coordinates, then forward ports to dummy IPs.
Remote wake attempts fail when router ARP tables clear entries after servers shut down.
Use router interfaces or active network hosts as alternative access routes to enhance wol operations.
Establish effective best practices for wol by testing every wol trigger locally before attempting remote startup tasks across network routers. A magic packet payload must reach target interfaces without dropped frames. Issue a wake-on-lan signal, verify wol reception, and confirm your magic frame arrives intact. Proper wake-on-lan setup restores server power reliably across any local network.
You establish a dependable wake-on-lan workflow when you configure wake-on-lan inside your system BIOS, operating system, and routing devices. Always follow established best practices for wol by testing every trigger locally on your local network before attempting remote wake steps across subnets. Local validation verifies that your physical network adapter parses the magic packet payload correctly.
Remote wake-on-lan management increases administrative convenience, but you must protect system resources against unauthorized access. Restrict wol commands to trusted segments using firewalls and encrypted VPNs. Logging every wol action maintains complete auditability while preserving reliable server accessibility for your daily power management workflows.
FAQ
Can Wake-on-LAN work over a Wi-Fi connection?
You should not use Wake-on-LAN over Wi-Fi connections. Wireless network cards drop their link state during low-power modes like S5. Physical wired Ethernet cables maintain active standby link states reliably to process incoming magic packets.
Why does Wake-on-LAN fail after a full system shutdown?
Windows Fast Startup often cuts electrical power to network interfaces completely during shutdown. You must turn off Fast Startup in Power Options. Disabling this setting keeps your Ethernet port active to listen for magic packets in S5 standby states.
Which UDP ports does Wake-on-LAN use?
Wake-on-LAN utilities transmit magic packets using UDP port 7 or UDP port 9. You must configure network firewalls and port forwarding rules to allow traffic through these specific ports when sending triggers across subnets.
How do you find the target MAC address for Wake-on-LAN?
You can retrieve the 48-bit physical address easily inside your command terminal. Run ip link on Linux systems or getmac on Windows hosts. Record this specific hardware address to direct your magic packet payload accurately.
