How to Wake a PC Over the Internet: Secure Wake-on-LAN Setup for Remote Teams

Wake-on-LAN (WoL) lets you power on a sleeping or shut-down computer from another machine. On a single office network it is simple. Across sites, or from home to the office, it becomes a routing and security problem, which is why so many "WoL not working" threads end without an answer.

This guide is for IT administrators and small business owners who want to start servers, lab machines or workstations remotely without sending someone on site. We explain what the magic packet contains, why it fails across networks, five reliable ways to make it work, and how to do it without opening your network to attackers. Remote access products from the Remote Access Software category on SaaSPodium are the most common way to solve this, so we point to those where relevant.

A magic packet is a UDP frame that contains six bytes of 0xFF followed by the target network card's MAC address repeated sixteen times. UDP itself is defined in IETF RFC 768. Because the packet is addressed at the MAC layer, the sleeping machine only needs a network card that is still powered and listening.

Why Wake-on-LAN fails across networks

Wake-on-LAN usually fails across networks because magic packets are broadcast frames, and routers do not forward broadcasts between subnets or from the internet. Even when the packet arrives, a firewall may drop it before it reaches the sleeping network card.

There are four common failure points. First, the packet is sent to the wrong subnet broadcast address. Second, the router blocks directed broadcasts by default, which is good security practice. Third, ARP entries expire, so a router no longer knows which port the sleeping device sits on. Fourth, the device itself is not configured to wake on a magic packet.

• Enable Wake-on-LAN or "Power on by PCI-E" in the BIOS or UEFI.
• Enable "Wake on Magic Packet" in the network adapter driver settings.
• Disable fast startup features that put the adapter into a state that cannot listen, on Windows machines where this applies.
• Confirm the machine is connected by Ethernet; Wi-Fi wake-up is far less reliable.

Step 1: Prepare the target computer

Preparing the target means enabling WoL in firmware, enabling magic packet wake in the operating system and recording the MAC address and local IP. Do this first, because no network trick can wake a machine that is not listening.

Record the MAC address from the network adapter details. Reserve a static or DHCP-reserved IP so the address does not change. Test locally first: from another PC on the same switch, send a magic packet and confirm the machine starts. Only move to remote testing once the local test works every time.

Step 2: Choose a gateway that sits inside the network

You need something always on inside the target network to turn a remote request into a local broadcast. This can be a firewall, a router, a small always-on PC, a NAS, or a remote access agent installed on an always-on machine.

This is where remote access software helps. Products such as TeamViewer Remote, Splashtop and ConnectWise Control are commonly used to reach a machine that stays on, from which you can then wake others. Not every product wakes devices directly, so confirm Wake-on-LAN support on the vendor site before you buy. The vendor site for one widely used option is TeamViewer.

If you already run monitoring or asset tools, check whether they include a wake feature. Our guides to free Wake-on-LAN tools and Wake-on-LAN software setup cover utilities and management suites.

Step 3: Connect securely with a VPN or agent

The safest way to reach the gateway is through a VPN or a vendor-managed remote access session, not by exposing a port to the internet. This keeps the broadcast step inside your network and keeps the attack surface small.

NIST guidance on telework and remote access recommends strong authentication, encrypted tunnels and limiting what remote users can reach. See NIST SP 800-46 Revision 2 for the framework. In practice, that means multi-factor authentication on the VPN or remote access account, and logging every wake request.

• Prefer WireGuard, IPsec or your firewall vendor's VPN over open port forwards.
• Require multi-factor authentication for every remote access account.
• Restrict wake permissions to named administrators.
• Log who woke which device and when.

Step 4: Send the magic packet to the right address

Send the packet as a directed broadcast to the target subnet, or as a unicast to the gateway that relays it. Use UDP port 9 or port 7, which are common conventions, and set the correct subnet broadcast address.

For example, on a 192.168.10.0/24 network the broadcast address is 192.168.10.255. Many routers expose an option to forward UDP to that address, but treat it as a last resort because it can be abused. A relay agent on the LAN that receives a request and then sends a local broadcast is safer and more reliable.

Test with one device, then document the working settings. Include MAC, subnet, port and the gateway used so a colleague can repeat the process.

Cost and energy savings from remote wake-ups

The case for WoL is simple: machines sleep when unused and wake on demand, which saves power and avoids truck rolls. A short calculation shows whether it is worth the effort for your fleet.

Use this simple model to estimate monthly savings from powering down idle machines:

Machines is the number of devices you sleep. Idle hours is how long each would otherwise sit powered on and unused. Watts saved is the difference between idle and sleep draw, which you can measure with a plug-in meter. Price per kWh comes from your electricity bill. Add avoided on-site visit costs for servers and lab machines to see the full return.

Security checklist before enabling remote wake-up

Treat Wake-on-LAN as a privileged action. A wake request should be authenticated, logged and limited to specific devices. Never leave a raw UDP forward open to the internet.

Review the checklist below with your security team, and extend the same controls to the wider remote access setup described in our guide on setting up secure remote access.

• Use a VPN or managed remote access gateway for all external requests.
• Put WoL devices in a dedicated VLAN where practical.
• Disable WoL on devices that do not need it.
• Alert on wake events outside business hours.
• Review remote access accounts quarterly.

Frequently Asked Questions

Can I use Wake-on-LAN without a VPN?
Yes, but with trade-offs. A remote access agent on an always-on device or a managed relay can send the broadcast locally. Exposing a UDP port forward directly to the internet works but is the least secure option and should be avoided.

Does Wake-on-LAN work over Wi-Fi?
Rarely. Most laptops and desktops cannot listen for magic packets on Wi-Fi while asleep. Use a wired Ethernet connection on the target device, or use a vendor feature designed for wireless wake-up where documented.

How long does it take to set up remote Wake-on-LAN?
Preparing one device and testing locally takes under an hour. Adding secure remote access through a VPN or agent typically takes another one to two hours, plus time to document and train staff.