Wake-on-LAN on Proxmox: How to Verify Support and Configure Persistently

In lab environments, homelabs, or even production infrastructure with energy-saving policies, Wake-on-LAN (WoL) is a simple feature, but it is often misconfigured or misunderstood. In this article, we will cover the complete process: how to verify if your NIC actually supports WoL, how to enable it, how to persist the configuration after reboot on Debian/Proxmox, and the hardware details that usually cause headaches — especially on generic cards.

What is Wake-on-LAN, in practice

Wake-on-LAN is a mechanism that allows you to turn on a machine remotely by sending a special packet over the network, called magic packet. This packet is quite simple in structure: 6 bytes FF followed by the destination MAC address repeated 16 times.

The important point is that when the machine is off, it does not have an active network stack — no IP, no ARP, no routing. The only thing "alive" is the network card, which keeps a small amount of auxiliary power (standby power) precisely to listen for raw layer 2 (Ethernet) traffic looking for this byte pattern. Upon recognizing the pattern with the matching MAC, the NIC signals the motherboard to start booting.

This explains why the trigger command uses the network's broadcast address (e.g., 192.168.11.255) instead of the target machine's IP: without an active network stack, there is no way to address the machine via unicast/ARP. Broadcast ensures that the frame physically reaches all ports in the broadcast domain, and only the NIC with the correct MAC (and WoL enabled) reacts. For other powered-on machines, the packet is simply discarded — it poses no risk or side effect.

Step 1 — Verify actual support on the NIC

A common mistake is trying to identify WoL support via dmidecode -t system, looking at the Wake-up Type field. This field does not indicate WoL capability — it only shows what caused the last boot of the machine (power switch, PCI, etc.). The correct source of truth is ethtool, directly on the network interface.

ip a                          # identificar a interface, ex: eth0
ethtool eth0 | grep Wake-on

Expected output:

Supports Wake-on: pumbg
Wake-on: d

Each letter in Supports Wake-on represents a mode supported by the NIC/driver:

If the letter g does not appear in Supports Wake-on, stop here: the NIC + driver combination does not support magic packet, and no software configuration can solve that.

Step 2 — Enable WoL

With support confirmed, enable it temporarily:

ethtool -s eth0 wol g
ethtool eth0 | grep Wake-on   # deve mostrar "Wake-on: g"

This change does not survive a reboot by default — it is necessary to persist it in two complementary ways.

Step 3 — Persist the configuration

Via /etc/network/interfaces (ifupdown2)

In Proxmox, the network interface is usually managed via /etc/network/interfaces, even though the file contains the "autogenerated" warning. This warning refers to not moving PVE-managed interfaces to external files via source-directory — editing the physical interface block directly is safe and is the recommended approach.

Locate the block for your physical interface (not the bridge vmbrX — WoL must be applied to the actual physical interface):

auto eth0
iface eth0 inet manual

And add the post-up directive, respecting indentation with tab (not spaces) to maintain consistency with the rest of the file:

auto eth0
iface eth0 inet manual
	post-up /usr/sbin/ethtool -s eth0 wol g

Apply without dropping the active network:

ifreload -a

Via udev rule (redundancy layer)

As a reinforcement — covering scenarios where the network module comes up before ifupdown2 processes the directives — also create a udev rule:

cat > /etc/udev/rules.d/50-wol.rules <<'EOF'
ACTION=="add", SUBSYSTEM=="net", NAME=="eth0", RUN+="/usr/sbin/ethtool -s eth0 wol g"
EOF

Adjust NAME== to the actual name of your interface and confirm the path of ethtool with which ethtool (on Debian 13/trixie, with usr-merge, /sbin is just a symlink to /usr/sbin, so both work, but it is good to use the real absolute path).

Step 4 — Validate persistence

Restart the machine:

reboot

After boot, without running anything manually, check:

ethtool eth0 | grep Wake-on

If Wake-on: g appears alone, persistence is working correctly.

Step 5 — BIOS/UEFI configuration

This is the point that causes the most confusion, especially on generic OEM boards (kits of Chinese boards with refurbished Intel chipsets are a common example). Even with the operating system configured correctly, WoL may simply not work if the BIOS does not cooperate. Check:

• Power On by PCI-E/PCI: must be enabled.

• ErP/EuP Ready: if enabled, it usually disables WoL, because it cuts standby power to the NIC to reduce consumption when off. Disable this option.

• S3 vs S5 support: some simpler boards only maintain enough auxiliary power for WoL when resuming from sleep (S3), not from full shutdown (S5). This is a hardware limitation, not a configuration issue — it is worth testing both scenarios to understand the actual behavior of your board.

Step 6 — Test the trigger

From another machine on the same network:

apt install wakeonlan
wakeonlan -i 192.168.11.255 AA:BB:CC:DD:EE:FF

Replace the broadcast IP with your network range and the MAC with the actual interface address (cat /sys/class/net/eth0/address).

Shut down the machine completely before the test:

shutdown -h now

Attention: on some recent versions of systemd, the command may return an error related to D-Bus (Refusing activation, D-Bus is shutting down) even while the shutdown is already in progress — it is a race condition between the command and systemd-logind shutting down the D-Bus bus during the shutdown process itself. If this happens, do not run new commands: check via ping from another machine whether the host actually turned off before assuming something failed.

Frequent pitfalls

• Bridge/bond in Proxmox: if the physical interface is behind a vmbrX, WoL must be configured on the physical interface (eth0), not on the bridge. The bridge does not interfere with magic packet capture, which occurs at the NIC hardware level.

• Generic Realtek NICs: they have inconsistent WoL support among variants of the same chip. Even with the driver reporting pumbg, some cards simply do not have the auxiliary power rail (VCC standby) correctly routed to the chip — in this case, it is a physical limitation, with no software solution.

• Switch with aggressive port security: some managed switches drop ports without constant active link, which can prevent the magic packet from arriving. Confirm that the switch keeps the port active even with the host off.

• WoL across different VLANs/subnets: the broadcast used in WoL does not cross routers by default. To wake a machine on another subnet, directed broadcast support is required on the router, or some host on the same physical network acting as a packet proxy.

Conclusion

Wake-on-LAN is a simple feature to configure, but with multiple layers that need to be aligned: driver/NIC support, persistence of configuration in the OS, BIOS/UEFI cooperation, and correct network switch behavior. Testing each layer in isolation — starting with ethtool, then persistence, then BIOS — makes it much simpler to isolate where the problem is when WoL "doesn't work".