How to Set Up Wake-on-LAN in Proxmox VE (ethtool and pvenode Guide)

Introduction

Leaving a Proxmox VE box powered on 24/7 costs money, and if you're running a single tower under a desk or a mini PC in a closet, that hum adds up on the electric bill over a year. A lot of homelab users solve this by shutting the host down when it's not needed and then dreading the moment they have to walk over and press the power button. That's the exact problem Wake-on-LAN solves, and Proxmox VE actually has first-class support for it built into the pvenode command line tool, not just some third-party hack layered on top.

This guide walks through enabling Wake-on-LAN (WOL) on the network card in your Proxmox host, making that setting survive a reboot, registering the MAC address inside Proxmox itself, and then actually sending the "wake up" packet from another machine on your network. None of this requires a cluster, extra hardware, or a subscription tier — it works on a single standalone node running Proxmox VE 8.2 or newer, which is when the wakeonlan node property first shipped.

What You Will Learn

What Wake-on-LAN actually is and how the "magic packet" mechanism works
How to check whether your network card supports it (not all do, especially cheap USB NICs)
How to turn WOL on with ethtool and keep it turned on after a reboot
How to register the MAC address with Proxmox's pvenode tool
How to send a wake packet from a laptop, phone, or another server
The BIOS settings and switch quirks that quietly break WOL, and how to spot them

What Is This Feature?

Wake-on-LAN is a low-level networking feature, not something Proxmox invented. Most gigabit Ethernet chips, when the host is fully powered off, can stay in a tiny standby state that still watches the wire for one specific thing: a "magic packet." That packet is just 6 bytes of 0xFF followed by the target NIC's MAC address repeated sixteen times, wrapped in a UDP frame, usually sent to port 9. When the NIC's firmware recognizes its own MAC address in that pattern, it signals the motherboard to power on, the same way pressing the physical power button would.

Proxmox VE adds a thin, convenient layer on top of that. Since version 8.2, each node has a wakeonlan property you can set with pvenode config set, storing the node's MAC address (and optionally which interface and broadcast address to use) directly in that node's config file at /etc/pve/nodes/<nodename>/config. Once that's set, you — or another node in a cluster — can run pvenode wakeonlan <node> or click Wake on LAN from the Datacenter view in the web GUI, and Proxmox builds and broadcasts the magic packet for you.

Why Would You Use It?

The obvious case is power savings on a homelab box that only needs to run a few hours a day — a Plex server that's mostly idle overnight, or a test environment you spin up on weekends. Rather than leaving it running just in case, you shut it down cleanly and wake it from your phone or laptop when you actually need it.

The second case is convenience for anyone who doesn't have out-of-band management hardware. Enterprise servers usually have IPMI, iDRAC, or iLO, letting you power them on remotely no matter what state the OS is in. A lot of homelab gear — mini PCs, old desktops repurposed as servers, NUCs — doesn't have anything like that. WOL is the closest free substitute, and honestly, for a machine sitting on your own LAN, it's good enough for most people.

There's also a niche but real use case in small clusters: if a node crashed or got shut down for maintenance and you're not physically near it, being able to run pvenode wakeonlan node2 from node1 saves a trip to the server closet.

Prerequisites

Proxmox VE 8.2 or later (the wakeonlan node property doesn't exist on older releases — you'd have to rely on plain ethtool and a separate wakeonlan tool instead)
Root shell access to the Proxmox host, either via SSH or the web GUI's Shell button
A network card that actually supports WOL — check the motherboard or NIC spec sheet if you're not sure; most onboard Realtek and Intel gigabit chips do, many cheap USB 3.0-to-Ethernet dongles do not
Access to the BIOS/UEFI setup screen, since WOL has to be enabled at the firmware level too
A second device on the same local network to send the wake packet from — a laptop, phone with a WOL app, or another server

One thing worth flagging early: Wake-on-LAN generally only works when the host was shut down cleanly with power still connected to the motherboard, not after you've unplugged it or there's been a full power cut. The NIC needs a trickle of standby voltage from the PSU to stay listening, so if you've physically pulled the plug, no magic packet will bring it back — you'll need a smart plug or PDU for that scenario instead.

Step-by-Step Tutorial

This takes about fifteen minutes if your NIC cooperates on the first try. The longer part, if any, is usually digging through BIOS menus.

Step 1: Install ethtool and identify your network interface

SSH into your Proxmox host and install ethtool if it isn't already there:

apt update
apt install ethtool

Then find the name of your physical NIC — not vmbr0, the actual hardware interface underneath it, something like eno1 or enp3s0:

ip a

You can also check /etc/network/interfaces, where the physical NIC is listed as the bridge-ports value for your bridge.

Step 2: Check whether the NIC supports Wake-on-LAN

ethtool eno1

Look for a line near the bottom that reads Supports Wake-on: pumbg (the exact letters vary by chipset) and another reading Wake-on: d. The letter g in the "Supports" line is what matters — it means the card can wake on a magic packet. If that line reads Supports Wake-on: d only, with no g, the NIC doesn't support it and no amount of configuration will change that.

Step 3: Enable Wake-on-LAN in the BIOS/UEFI

Reboot the host and enter setup (usually Del, F2, or F10 depending on the board). Look for a setting called something like Wake on LAN, Power On By PCI-E/PCI Device, or Resume by LAN, under Power Management or Advanced settings, and enable it. On some boards there's also an ErP Ready or EuP option meant to reduce standby power draw to near zero — if that's enabled, it usually kills WOL entirely, so turn it off.

Step 4: Turn on the magic packet flag with ethtool

Back at the shell, enable it for the current session:

ethtool -s eno1 wol g

Verify it stuck:

ethtool eno1 | grep Wake-on

You should now see Wake-on: g instead of d. This setting doesn't survive a reboot on its own — the kernel driver resets it to whatever the default is every time the interface comes up, which is why the next step matters.

Step 5: Make the setting persist across reboots

The cleanest way is a small systemd service. Create /etc/systemd/system/wol.service:

[Unit]
Description=Enable Wake-on-LAN
After=network.target

[Service]
Type=oneshot
ExecStart=/sbin/ethtool -s eno1 wol g

[Install]
WantedBy=multi-user.target

Then enable and start it:

systemctl daemon-reload
systemctl enable --now wol.service

Swap eno1 for whatever your actual interface name is. If you'd rather avoid a separate unit file, adding a post-up line to the physical interface's stanza in /etc/network/interfaces works too:

iface eno1 inet manual
    post-up /sbin/ethtool -s eno1 wol g

I'd lean toward the systemd unit — it's easier to check with systemctl status wol.service when you're troubleshooting later, and it doesn't get overwritten if you regenerate your network config from the GUI.

Step 6: Register the MAC address with Proxmox

Grab the NIC's MAC address:

ip link show eno1

Then tell Proxmox about it:

pvenode config set --wakeonlan XX:XX:XX:XX:XX:XX

Replacing the X's with the real MAC address. If your host has multiple NICs and the default route doesn't point out the one you enabled WOL on, add bind-interface:

pvenode config set --wakeonlan XX:XX:XX:XX:XX:XX,bind-interface=eno1

And if you need the packet sent to a specific broadcast address rather than the default 255.255.255.255 — common on networks with unusual subnetting — add that too:

pvenode config set --wakeonlan XX:XX:XX:XX:XX:XX,broadcast-address=192.168.1.255

Confirm it saved correctly:

pvenode config get --property wakeonlan

Step 7: Shut the host down and send a test wake packet

Shut down cleanly from the GUI or with shutdown -h now, then wait about ten seconds for the standby state to settle. From a second device on the same network, you have a few options.

If that second device is another Proxmox node in a cluster, use pvenode wakeonlan <node>, or click the node in the Datacenter view and choose Wake on LAN from the right-click menu. If it's just a laptop or another Linux box that isn't part of any Proxmox cluster, install the generic tool instead:

apt install wakeonlan
wakeonlan XX:XX:XX:XX:XX:XX

On macOS the same package is available through Homebrew (brew install wakeonlan), and on Windows there are free GUI tools like WakeMeOnLan that do the same job. Within a few seconds the host's fans should spin up and it should boot normally.

Commands Explained

Command	What It Does
`ethtool eno1`	Shows the NIC's current settings, including which Wake-on-LAN modes it supports and which one is active.
`ethtool -s eno1 wol g`	Sets the interface's Wake-on-LAN mode to `g` (magic packet). Other letters exist (`p` for physical activity, `u` for unicast) but `g` is what modern tools and Proxmox both use.
`pvenode config set --wakeonlan <mac>`	Stores the node's MAC address (and optional interface/broadcast overrides) in that node's cluster config file, so Proxmox knows what packet to build later.
`pvenode config get --property wakeonlan`	Reads back the stored wakeonlan value, useful for confirming it saved correctly without opening the config file directly.
`pvenode wakeonlan <node>`	Builds the magic packet using the stored MAC address and broadcasts it on UDP port 9, run from another already-running node.
`wakeonlan <mac>`	A standalone, non-Proxmox tool that does the same broadcast from any Linux machine — handy for a single-node homelab with no second Proxmox node to send from.

Common Errors

"Cannot set new wake-on-lan settings: Operation not supported" — this comes straight from ethtool and means the driver or firmware for that NIC doesn't implement magic-packet wake at all. It's not a Proxmox limitation; some low-end chipsets and most USB-Ethernet adapters simply lack this circuitry. Check the NIC's spec sheet before spending more time on it.

The web GUI's Wake on LAN option greyed out or refusing to work — nine times out of ten this means the wakeonlan property was never set for that node, or was set with a typo'd MAC address. Re-run pvenode config get --property wakeonlan and compare it against ip link show on the actual host.

ethtool shows Wake-on: g right after you set it, but a reboot resets it back to d — that's expected behavior, not a bug. The kernel doesn't remember ethtool settings across a link reset; that's exactly why step 5, the systemd service, exists.

Wake packet sent, nothing happens, and the host stays off — most often this is a BIOS setting, either WOL wasn't actually saved in firmware or an energy-saving option like ErP/EuP is quietly overriding it. Less commonly, it's a switch port with aggressive Energy Efficient Ethernet (802.3az) cutting power to the link entirely when the host is off, which some older switches do more aggressively than others.

Troubleshooting

Start by isolating whether the problem is on the network side or the host side. While the host is still powered on, run a packet capture on the interface:

tcpdump -i eno1 udp port 9

Then trigger a wake packet from your other device (the host obviously won't wake up since it's already on, but you can confirm the packet actually arrives). If nothing shows up in the capture, the problem is upstream — a firewall, VLAN mismatch, or a switch/router not forwarding broadcast traffic between the sender and the host. If the packet does arrive but the host still won't wake from a real power-off state, the problem is almost certainly BIOS or hardware standby power, not networking.

Double-check that the sending device and the Proxmox host are on the same VLAN and broadcast domain. Broadcast packets, by design, don't cross routed subnets, so if your laptop is on a guest VLAN and the server is on your main LAN, the packet will never reach it unless your router is specifically configured to relay it, which most consumer routers don't do by default.

If you're using bind-interface or broadcast-address in the pvenode config and it's still not working, temporarily remove those overrides and test with the defaults first — it's easy to typo a broadcast address and end up sending the packet somewhere that doesn't include your host.

Finally, if the host worked fine yesterday and stopped waking today, check whether a BIOS update happened recently. Firmware updates on consumer boards have a bad habit of silently resetting power management settings, WOL included, back to their factory defaults.

Best Practices

Give the host a static DHCP reservation on your router so its IP address doesn't drift — WOL only needs the MAC address to work, but you'll want a predictable IP once it's back up so you can actually SSH into it or hit the web GUI.

Don't expose WOL directly to the internet by port-forwarding UDP 9. If you want to wake your Proxmox box while you're away from home, connect to your LAN first through a VPN like WireGuard or Tailscale, and send the magic packet from inside that tunnel instead. Opening broadcast ports to the wider internet is asking for trouble.

If reliability really matters — say this box hosts something you can't afford to have stuck off — pair WOL with a cheap smart plug that can also power-cycle the machine, or consider hardware with real IPMI/BMC support for anything beyond casual homelab use. Wake-on-LAN is a convenience feature built on best-effort behavior, not a guaranteed remote-power solution, and it's worth being honest with yourself about that distinction.

Keep a note somewhere — a spreadsheet, a wiki page, whatever you already use — listing the MAC address and WOL status of each machine in your homelab. It sounds unnecessary until you're troubleshooting a wake failure eight months after you originally set it up and can't remember which NIC you configured.

Frequently Asked Questions

Does Wake-on-LAN survive a full power outage?
No. The NIC needs standby voltage from the power supply to listen for the packet. If the machine was unplugged or lost power entirely, it needs to be physically switched back on, or plugged into a smart outlet configured to restore power automatically.

Do I need a Proxmox cluster to use this?
No. The pvenode wakeonlan command is more convenient if you have a second node to run it from, but the standalone wakeonlan tool works from any Linux, macOS, or Windows machine on the same network regardless of whether Proxmox clustering is involved.

Does Wake-on-LAN work over Wi-Fi?
Rarely, and it's not something to plan around. Most Wi-Fi chipsets don't maintain the standby state needed, and Proxmox hosts should be on wired Ethernet anyway for stability, so this shouldn't come up in practice.

Can I wake my server from outside my home network?
Not directly, since WOL relies on local broadcast traffic. Connect through a VPN back into your LAN first, then send the packet from inside that tunnel.

What's the difference between the "g", "p", and "u" WOL modes in ethtool?
g wakes on a magic packet (what nearly everyone uses), u wakes on any unicast frame addressed to the NIC, and p wakes on physical link activity. Stick with g unless you have a specific reason not to.

My NIC shows "Supports Wake-on: d" with no other letters — is there any workaround?
Not really. That means the chipset itself doesn't implement magic-packet wake in hardware, and no driver setting or Proxmox configuration can add a capability that isn't there.

Conclusion

Wake-on-LAN is one of those features that takes fifteen minutes to set up and then quietly saves you a trip to the server closet for years afterward. The Proxmox-specific half of this — the wakeonlan node property and pvenode wakeonlan command — is genuinely well designed, and it's a shame more people don't know it exists outside of clustered setups. Get the BIOS setting right, get the systemd unit in place so ethtool doesn't forget itself on every reboot, and you'll have a server you can shut all the way down instead of leaving idle around the clock, without losing the ability to bring it back the moment you actually need it.

Vormox is an independent virtualization management platform built on Proxmox VE. Proxmox® and Proxmox VE® are trademarks of Proxmox Server Solutions GmbH. Vormox is not affiliated with, endorsed by, or sponsored by Proxmox.

How to Set Up Wake-on-LAN in Proxmox VE (ethtool and pvenode Explained)