How to enhance your network with transparent Wake-on-LAN capabilities

Kevin Koslowski — Sun, 17 May 2026 16:26:56 +0000

This is the story of how I got frustrated with the energy efficiency of my Homelab network and decided to create a solution that gradually became a sophisticated network tool, that can monitor and wake hosts transparently and keep them awake as long as they are required.

A little bit of history

The idea first took shape around 2016, after I had built my first HTPC and decided to gradually add more features and roles to it. As soon as I started using it as a development server for my web projects I imagined the server to be somehow aware of me using it (from a secondary device) and turning itself on when I started my work and off (or rather suspending itself) when I finished using it.

Opinions may differ on using Windows for professional purposes, but I took a pragmatic approach: As I am also an avid gamer, I wanted a machine that could run every game without hassle. The natural choice for this was to use a Windows system as a host and run various kinds of virtual machines for different purposes side-by-side. Although gaming on other platforms has become more comfortable over time, this assumption still generally holds true today.

A case of Insomnia

The first problem I encountered was with the built-in power management of Windows itself. In a perfect world, we could rely on the onboard faculties of the OS and stop here. But as it turned out, the world in which we live is this imperfect beauty, that we all know, and needs a little nudge here and there, so that everything runs as smoothly as it can be. The first problem arises with the simple fact, that applications can register “power requests”, that keep the system awake as long as the application deems it necessary. You can overwrite this for individual requests of course, but since they must be applied via the command line and do not survive a reboot, this can become tedious really fast. On top of that, there are a couple of kernel APIs which create power requests, that simply cannot be overridden.

As you may already imagine, this will inevitably lead to situations, where you will find your PC running late at night and cannot help yourself except with manually pressing the power button. Yuck!

When to wake up?

The other part of the problem was activating the computer on demand, without actually reaching out physically. Luckily some smart people in the early 90s came up with the idea of Wake-on-LAN. A technique that has become widely adopted since then and allows us to wake computers from their slumber conveniently via a network protocol. I will not go into any more details here, because I am pretty confident that you have heard of this before — especially since you found about this story.

Having this tool in your belt, you can start waking your computers without much problem and I am sure many of you do this on a daily basis. The tricky part here lies in deciding when to do this. You can always do this manually by opening your preferred terminal and running (using the real MAC address of your target host, instead of the fake one):

wakeonlan 00:1A:2B:3C:4D:5E

Maybe you use a software with a more appealing UI for this. But most of the time this boils down to having you decide consciously when to wake the target system.

My first attempt at solving this problem was rather brute-force and opinionated: I created a program that would continuously send Wake-on-LAN packets, while my client computer was running. Later I added a toggle to turn this on and off for individual targets, but basically the moment of wake-up was quite artificial and arbitrary. Surely we can do better, right?

Let me introduce you to Desomnia

Here is what ten years of tinkering eventually produced. I will save the design decisions and the technical journey for a follow-up — for now, let me focus on what Desomnia can do for you.

Imagine yourself in a situation where you operate one or more dedicated server machines at home or in a small office and care about the electricity bill. Desomnia can help you automate the suspension of idle hosts and wake hosts on demand transparently — without the need to think about when to do this anymore.

For one thing, it can replace the basic power management features of your operating system with a detailed list of filters and triggers that ensure your system only stays awake when you actually use it. On the other hand, it can also act as a network monitor that wakes your computers at the exact moment you need them. If you own a small, always-on device such as a Raspberry Pi, this can even be done transparently for the entire network segment without installing any software on the client or server. When deployed both ways, it allows you to specify the wake/sleep requirements of your network hosts declaratively, so you don’t have to think about it constantly.

Strong core values

Desomnia tries to follow the Unix philosophy in two important aspects:

Write programs that do one thing and do it well.
Write programs to work together.

It does not try to take over your entire network infrastructure, by introducing heavyweight appliances and does not introduce itself as a single point of failure. When Desomnia fails, your network will degrade gracefully. Automatic wake-up may not be available anymore, but apart from that everything will continue to run normally.

This is achieved by using common network protocols in an unusual yet creative way, while remaining as true as possible to the decentralised nature of Ethernet networks. It has been carefully designed to minimise interference with normal network operations.

Best of all, Desomnia is free software licensed under the GPL and hosted on GitHub. Feel free to learn from its source code, modify it to suit your needs, and share it with others. If you notice anything missing, please let me know so that it can be added to the upstream repository and benefit others too.

Supported platforms: 🪟 Windows, 🐧 Linux, 🍎 macOS

A couple of use-cases

Here is a taste of what Desomnia can do, grouped by the problem it solves.

Waking servers on demand

The most common use-case: you have a machine that should sleep when nobody needs it, and wake the moment someone does — without anyone having to think about it.

Personal cloud services — Running Nextcloud, ownCloud, FileRun or similar at home? Desomnia starts your server when it is accessed remotely and lets it sleep in between. It also understands Windows File Sharing (SMB) natively, so you can tell it to ignore certain shares or clients that would otherwise keep the machine awake unnecessarily.
Remote desktop — Connecting via RDP or VNC? Desomnia wakes the target when you initiate the connection, tracks the active session, and keeps the machine running until you disconnect.
Development environments — If you outsourced your dev setup to a dedicated machine, Desomnia can bring it online the moment the first SSH or HTTP connection comes in, and let it rest when you stop.
VPN access — Connecting from a remote network via VPN and need to reach a sleeping host? Desomnia wakes it on your behalf. It has been tested with a variety of VPN setups and providers.

Network-wide deployment

If you have a small always-on device — a Raspberry Pi, a NAS, anything that stays powered — Desomnia can act as a Wake-on-LAN proxy for your entire network. No software needs to be installed on the clients or the target machines. Any connection attempt to a sleeping host is detected and handled automatically, completely transparently.

You can also expose services to the internet via port forwarding without worrying about random scanners waking your machines. Desomnia can filter wake-up triggers by protocol, port, and source address. For an extra layer of security, it supports Single Packet Authorization (SPA) — a cryptographically authenticated single UDP packet that temporarily unlocks wake access for a specific remote host, with no persistent tunnel required.

Virtualization and game streaming

Hyper-V — Desomnia comes with support for virtual machines. It can wake the physical host when one of its VMs is accessed, start suspended VMs automatically, and stop them once they go idle — no manual lifecycle management needed.
Game streaming — Streaming from your own gaming rig via Moonlight and Sunshine or Apollo? Desomnia ensures the system only runs while someone is actually playing. It also integrates with Duo to start streaming instances when a client connects and stop them when the last session ends.

Taking back control of sleep

Sometimes the challenge is not waking machines — it is getting them to stay awake for exactly the right amount of time. Apart from what Windows already has to offer, Desomnia allows you to monitor the following:

Processes — Desomnia can watch specific processes by name and CPU usage. It keeps the system awake while meaningful work is happening and lets it sleep once things have gone quiet — optionally terminating idle programs along the way.
Power requests — Some applications and drivers issue power requests that prevent sleep without good reason. Desomnia lets you explicitly allowlist or blocklist those requests, to filter out bad actors and allow your system to rest.
Network traffic — Desomnia optionally uses the Npcap library to monitor if selected network services are currently in use, meanwhile preventing the system from sleep.
User sessions — Of course you can also track the activity of logged in users, for which the system obviously should be running.

You can find more about Desomnia’s many features in the comprehensive documentation.

Showtime

Now I want to go with you through a little hands-on, so that you get a glimpse of how Desomnia works.

Installation

First you have to download and install the program via one of the available channels:

Windows installer
Docker container
Homebrew
Manually (if none of the above fits your need)

After that you have to create an appropriate configuration file. Please refer to the documentation on where to put it.

Waking up hosts

Now let me show you, how easy it is, to configure Desomnia to wake up a sleeping host.

First you create a configuration file in XML format, in which you enable the Network Monitor and tell it to watch a host called “server”, with the specified MAC address “00:1A:2B:3C:4D:5E”:

<?xml version="1.0" encoding="UTF-8"?>
<SystemMonitor version="1">

  <NetworkMonitor>
    <RemoteHost name="server" MAC="00:1A:2B:3C:4D:5E" IPv4="192.168.1.10" />
  </NetworkMonitor>

</SystemMonitor>

We have also provided the IP address “192.168.1.10” to make the example less dependent on the network environment. If available you can have Desomnia configure this automatically for you.

After this setup, Desomnia has to be started as a background system service, so that it can monitor your network traffic. The moment you try to access any service of the remote host (via TCP, UDP, ICMP, etc.) and Desomnia detects that the remote host is sleeping, it will automatically send a Magic Packet in order to wake up that server.

Wake-on-LAN proxy

Instead of installing Desomnia on every client that should be capable to do transparent Wake-on-LAN, you can alternatively use an always-on device, like a Raspberry Pi or other low-power SoC, that will then act on behalf of your clients. The configuration will look surprisingly similar:

<?xml version="1.0" encoding="UTF-8"?>
<SystemMonitor version="1">

  <NetworkMonitor interface="eth0" autoDetect="IPv4" watchMode="promiscuous">
    <RemoteHost name="server" MAC="00:1A:2B:3C:4D:5E">
      <Service name="SSH" port="22" />
    </RemoteHost>
  </NetworkMonitor>

</SystemMonitor>

Setting the watch mode to “promiscuous” instructs Desomnia to extend its monitoring to cover the entire broadcast domain, which typically encompasses all hosts with the same subnet mask or address prefix. It will then observe the traffic for specific broadcast and multicast packets to detect when a client tries to access the server.

In this case we also specified that only requests to the SSH server at port 22/tcp should trigger a wake-up. To check this, Desomnia momentarily reroutes the server’s IP traffic to itself in order to verify that the request is indeed directed at port 22. Only then will Desomnia wake up the target host, which will then reclaim its own IP address. Desomnia will then forward the original request to the server, which will finally answer the original client.

Since the client receives a response from Desomnia immediately, the time until the connection attempt is considered failed is usually extended. If your server wakes up in less than 10 seconds, your application will probably not even register an error.

Local sleep management

This mode of operation is currently only available for Windows hosts. You can think of it as an open-source and free alternative to the commercially available software "Lights Out". But instead of relying on management through graphical interfaces, Desomnia is aimed more at tech-savvy users who want to keep things as lightweight as possible and are comfortable with writing a configuration file. The configuration follows the same structure and is fully compatible with the Wake-on-LAN mode:

<SystemMonitor version="1" timeout="2min" onIdle="sleep+30min" onDemand="sleepless">

  <NetworkMonitor>

    <!-- watch inbound connections -->
    <Service name="HTTP" port="8080" />
    <Service name="Jellyfin" port="8096" />

    <!-- watch inbound VM connections -->
    <VirtualHost name="gitlab" onIdle="suspend+10min">
      <Service name="SSH" port="22" />
      <Service name="HTTP" port="80" />
    </VirtualHost>

    <!-- watch outbound connections -->
    <RemoteHost name="development" MAC="00:1A:2B:3C:4D:5E" onDemand="wake">
      <Service name="SSH" port="22" />
    </RemoteHost>

  </NetworkMonitor>

  <PowerRequestMonitor>
    <RequestFilterRule type="Must" name="Backup">CBBackupPlan</RequestFilterRule>
  </PowerRequestMonitor>

</SystemMonitor>

Of course there are a lot more monitors and features included. If you want to give it a try, you can find more information in the corresponding guide in the documentation.

What comes next

This is the first part of a series. In this first part, I covered how this project came to be and what Desomnia can do. In the next part I will go deeper: the design decisions behind the proxy mechanism, what network protocols are used and how they work, and what makes Desomnia different from the simpler alternatives you might have already tried. Follow me if you want to be notified when it goes live.

Kindly requesting feedback

Desomnia has been extensively and successfully tested within my own network, but one person can only think of so many edge cases. If you like the idea, please get in touch so we can work together to rule out any remaining bugs and oversights. I have created a Discord community where you can share your experiences of using the software and let me know if anything is missing. If you encounter an error, don’t hesitate to create an issue on GitHub.

Thank you

If you made it this far, you are probably exactly the kind of person Desomnia was built for. Give it a try — and if it saves you even one avoidable (late-night) trip to the power button, it has done something right. If you like what you see, spread the word. Thank you very much for reading. I hope it inspires you.

DEV Community: Kevin Koslowski