Set Up Wake-on-LAN for Remote Power-On on elementary OS

Wake-on-LAN (WoL) allows a computer to start when it receives a specially formed network packet, commonly called a magic packet. This is useful for an elementary OS desktop that acts as a file server, media centre, backup host, or development machine. You can leave it powered off and start it remotely when you need access.

The feature depends on several layers working together. The computer’s firmware must keep the network adapter powered while the system is off, the wired Ethernet hardware must support magic packets, and elementary OS must configure the adapter to listen for them. Your router and the device sending the packet also need to use the correct network path.

A wired connection is strongly preferred. Wake-on-LAN over Wi-Fi is uncommon and often depends on specialised wireless standards such as Wake on Wireless LAN. A desktop connected by Ethernet is the most dependable arrangement, whether it is sitting in a Melbourne home office, a Brisbane flat, or a shed converted into a workspace outside Adelaide.

The process involves enabling the firmware setting, identifying the Ethernet interface and MAC address, installing the required tools, testing a magic packet, and making the configuration persistent. Once it works on the local network, remote access needs additional care because many Australian internet connections use carrier-grade NAT or change their public address.

Check the hardware and firmware first

Begin by checking that the elementary OS computer is connected through Ethernet. Open a terminal and list the network devices:

ip link

Look for an interface name such as enp3s0, eno1, or eth0. Wireless devices commonly begin with wlp or wlan, while Ethernet devices usually begin with en, eno, or eth. The interface name on your computer will be used in later commands, so replace enp3s0 in the examples if yours is different.

Find the adapter’s MAC address with:

ip link show enp3s0

The address appears after link/ether, in a format similar to a4:5e:60:12:34:56. Record it carefully. A single incorrect character will prevent the magic packet from reaching the computer.

Restart the machine and enter its UEFI or BIOS setup. The key varies by manufacturer, but Delete, F2, F10, and Esc are common. Search menus such as Advanced, Power Management, APM, or Integrated Peripherals for settings named Wake on LAN, Power On By PCI-E, Resume By LAN, PME Event Wake Up, or similar. Enable the relevant option.

Some firmware includes a Deep Sleep, ErP, or EuP setting that cuts standby power to network hardware. Disable that setting if it prevents Wake-on-LAN. Also check that the Ethernet port LEDs remain lit or blink after shutdown. If the port loses all power, the operating system cannot wake the computer.

Enable magic packets in elementary OS

Install ethtool, the standard Linux utility for inspecting and changing Ethernet features:

sudo apt update
sudo apt install ethtool

Check what the adapter supports:

sudo ethtool enp3s0

The important lines look like this:

Supports Wake-on: pumbg
Wake-on: d

The Supports Wake-on line lists available methods. The letter g means magic-packet wake-up. The Wake-on line shows the current state. In this example, d means disabled. Enable magic-packet wake-up with:

sudo ethtool -s enp3s0 wol g

Run the inspection command again:

sudo ethtool enp3s0

You should now see:

Wake-on: g

If g does not appear in Supports Wake-on, the adapter or its driver probably cannot provide standard magic-packet wake-up. A USB Ethernet adapter may work if its chipset and driver support the feature, though built-in motherboard Ethernet is generally less troublesome.

Many elementary OS installations use NetworkManager, which can store the setting in the active connection profile. First display the connection names:

nmcli connection show

Identify the wired profile, then set its Wake-on-LAN mode to magic packets:

sudo nmcli connection modify "Wired connection 1" 802-3-ethernet.wake-on-lan magic

Replace Wired connection 1 with the exact profile name shown on your computer. Reconnect the profile or reboot, then verify the result with ethtool. If NetworkManager does not retain the setting on your particular elementary OS installation, use a small systemd service.

Create the service:

sudo nano /etc/systemd/system/wakeonlan@.service

Add these lines:

[Unit]
Description=Enable Wake-on-LAN for %i
After=NetworkManager.service
Wants=NetworkManager.service

[Service]
Type=oneshot
ExecStart=/usr/sbin/ethtool -s %i wol g
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Save the file, reload systemd, and enable it for your interface:

sudo systemctl daemon-reload
sudo systemctl enable --now wakeonlan@enp3s0.service

Check its status:

systemctl status wakeonlan@enp3s0.service

This service applies the setting during each boot. If you later rename the interface or replace the network adapter, update the service name and configuration to match.

Test the computer on your local network

Install the wakeonlan utility on a second Linux computer connected to the same local network:

sudo apt update
sudo apt install wakeonlan

Shut down the elementary OS computer normally:

systemctl poweroff

Wait for the machine to switch off, then send the magic packet from the other computer:

wakeonlan a4:5e:60:12:34:56

Use the actual MAC address from your system. The command normally reports that a packet was sent, but it cannot confirm that the sleeping computer received it. Give the target several seconds to start. Some firmware takes longer than expected before handing control to the bootloader.

If the computer does not start, test while it is fully powered off rather than suspended. Confirm that the Ethernet cable is plugged into the same adapter whose MAC address you recorded. Check that Wake-on: g was enabled before shutdown and that the Ethernet port still has standby lights.

A second useful test is to send the packet to the local broadcast address:

wakeonlan -i 192.168.1.255 a4:5e:60:12:34:56

Replace 192.168.1.255 with the broadcast address for your network. On a typical home network using 192.168.1.0/24, that address is often correct, but the router may use a different subnet such as 192.168.0.0/24 or 10.0.0.0/24.

Some Linux firewalls can interfere with locally generated or forwarded UDP traffic. Wake-on-LAN commonly uses UDP port 7 or 9. A local test usually needs no firewall rule on the sleeping computer because its operating system is inactive, but the router or sending computer may still filter the packet.

Make remote wake-up work safely

Wake-on-LAN across the internet is more complicated than sending a packet inside your home. A router must know where to forward the packet even though the target computer is powered off and has no active ARP entry. Some routers support a dedicated Wake-on-LAN page or a static DHCP and ARP reservation. Use that feature if available.

Avoid exposing a generic UDP port directly to the internet unless you understand the security and reliability implications. A safer approach is to connect to your home network through a VPN and send the packet from a device inside the network. A router, NAS, Raspberry Pi, or small always-on computer can act as the local Wake-on-LAN relay.

This matters for many Australian households because NBN providers may place customers behind carrier-grade NAT. With CGNAT, inbound port forwarding may not work at all, even when the router appears to have a public-looking address. Mobile broadband and some fixed-wireless services can have similar restrictions. Contacting the provider or checking the WAN address against a public IP lookup can reveal the situation, though a VPN-based relay avoids much of the problem.

Dynamic public IP addresses are another practical issue. If your address changes, a remote client will need a dynamic DNS hostname or a VPN account that handles address changes automatically. When travelling from Perth to Sydney, or accessing a home server while working remotely in regional New South Wales, connect to the VPN first, then send the packet to the local broadcast address or to the relay device.

A VPN running on the sleeping elementary OS computer cannot wake that computer by itself. The VPN endpoint must remain available while the target is off. Once the machine starts, you can connect to its normal hostname or static DHCP address and use SSH, a web dashboard, or your preferred remote desktop service.

Diagnose failures and avoid common traps

The most common fault is firmware configuration. A Linux command cannot compensate for a disabled PCIe wake option or a power-saving mode that removes standby power. Recheck the UEFI settings after firmware updates, since some vendors restore defaults. If the computer starts only from suspend but not from shutdown, firmware support for the chosen power state may be limited.

The network adapter driver is another possible cause. Compare the output of:

sudo ethtool enp3s0

before and after enabling WoL. If the setting returns to d immediately, NetworkManager or the driver may be resetting it. Check the connection profile, confirm the systemd service is enabled, and inspect logs with:

journalctl -u wakeonlan@enp3s0.service

A system update can also change interface names or driver behaviour. The ip link command is the quickest way to confirm the current name. MAC addresses should be entered without spaces, and colons should be retained unless the sending application documents another format.

Switches and routers can block broadcast traffic between VLANs or guest networks. Ensure the sending device and target are on the same trusted LAN during initial testing. Mesh Wi-Fi systems may isolate wireless clients, while managed business networks often suppress directed broadcasts intentionally. If the packet works from a wired laptop but not from a guest tablet, network isolation is likely responsible.

Wake-on-LAN is also affected by the physical path. Cheap or damaged Ethernet cables, an unpowered switch, and powerline adapters that shut down aggressively can all prevent delivery. For a reliable home server, connect the target and the relay device to a stable switch or router, and consider a small uninterruptible power supply in areas where summer storms or local outages are common.

A useful final test is to run the complete sequence locally: confirm Wake-on: g, shut down, observe the Ethernet standby lights, send the packet from another device, and wait for the boot process. Only after that works should you troubleshoot VPNs, port forwarding, public addresses, or remote applications.

The practical takeaway is to configure Wake-on-LAN in firmware and NetworkManager, test it on the local wired network, and use a VPN or always-on relay for access from outside home. Keep the elementary OS computer on reliable Ethernet, record its MAC address and interface name, and treat the magic packet as the first step in a secure remote-access setup rather than as a replacement for one.