Relay magic packets across flat networks, routed VLANs, and remote Tailscale tunnels — without touching the target machine.
Wake-on-LAN sounds trivial until a routed boundary gets in the way. A magic packet is a raw Layer-2 broadcast — it dies the moment it hits a router interface. This tutorial tears apart why that happens, then rebuilds the path: starting with a simple same-subnet relay, adding the cross-VLAN UDP forwarder that makes it work across routed segments, and finally attaching a Tailscale-triggered script so you can wake a server in a hotel server room from anywhere on the planet.
Each layer builds on the previous one. By the end you will have a reusable RouterOS toolkit — /tool wol, named scripts, the scheduler, and firewall rules — plus a defender's checklist so WoL doesn't become an unauthorised remote-power-on vector.
01
Before touching RouterOS, understand what you're actually sending — and where it breaks.
A Wake-on-LAN magic packet is a UDP datagram carrying a specific 102-byte payload: six bytes of 0xFF followed by the target's MAC address repeated sixteen times. The destination IP is typically the subnet broadcast address (e.g. 192.168.1.255) or the global broadcast 255.255.255.255, on UDP port 7 or 9. Port 9 (discard) is the modern standard.
The receiving NIC — not the OS — listens for this pattern on the wire. It triggers a power-on signal regardless of whether the machine is in S4 (hibernate) or S5 (off). The OS never sees the packet; the NIC's wake circuit does.
RouterOS gives you two mechanisms to solve this. /tool wol generates a magic packet from the router itself — useful for scripted or scheduled wakes. /ip dhcp-server leases let you resolve a hostname to a MAC. For cross-VLAN delivery, you need to either script a /tool wol targeted at the right interface, or configure UDP broadcast forwarding so that a packet arriving on one VLAN's subnet gets relayed to another.
Some older guides use UDP port 7 (echo). Modern NICs respond to port 9 (discard). Use port 9. More importantly: some routers and Linux hosts also listen on port 7 and will process the packet themselves before it reaches the wire. Stick to port 9 unless you have a specific reason not to.
02
The simplest case: the router and the target live on the same broadcast domain. One command, done.
If the machine you want to wake is on the same subnet as one of your RouterOS interfaces, /tool wol handles everything. You specify the interface (so RouterOS knows which wire to shout on) and the MAC address. The router broadcasts the magic packet out of that interface.
[admin@MikroTik] > /tool wol interface=bridge-lan mac=AA:BB:CC:DD:EE:FF # No output on success — the packet is sent silently. # Replace bridge-lan with your actual bridge or ether interface. # MAC is the target machine's NIC MAC (check BIOS or sticker on NIC).
To avoid looking up the MAC every time, store it. If the machine has a static DHCP lease you can retrieve it programmatically:
[admin@MikroTik] > ip dhcp-server lease print where host-name="fileserver" # Flags: X - disabled, R - radius, D - dynamic, B - blocked # Columns: ADDRESS, MAC-ADDRESS, HOST-NAME, SERVER, STATUS # 0 D 192.168.1.50 AA:BB:CC:DD:EE:FF fileserver dhcp1 bound # Grab the MAC-ADDRESS value from the matching row.
interface= and mac= parameters as the CLI — useful for one-off manual wakes without opening a terminal.
A common SMB use-case: wake the NAS or backup server at 02:00 for a scheduled backup job, then let it shut itself down after the job completes.
[admin@MikroTik] > system scheduler add \ name="wake-fileserver" \ start-time=02:00:00 \ interval=1d \ on-event="/tool wol interface=bridge-lan mac=AA:BB:CC:DD:EE:FF" # interval=1d = repeat daily. interval=0 = run once.
If you specify a physical port (e.g. ether3) instead of the bridge, and that port is down (cable unplugged, SFP missing), the WoL packet is silently dropped. Always target the bridge that the port is a member of, not the physical interface, unless you are certain the port is active.
03
The real challenge: the management workstation is on VLAN 10, the server is on VLAN 20, and a broadcast will never cross that routed boundary on its own.
In a segmented network — which is the correct design for any hotel, villa, or SMB — management, servers, guest Wi-Fi, and IoT all live on separate VLANs. A magic packet sent from VLAN 10 heading for a broadcast address on VLAN 20's subnet will be dropped by the router. RouterOS does not forward raw Layer-2 broadcasts between routed interfaces by default, and you do not want it to.
The correct solution is a UDP broadcast relay: the router listens for WoL packets arriving on VLAN 10's interface, intercepts them, and re-originates an identical magic packet out of VLAN 20's interface toward VLAN 20's broadcast address. RouterOS provides this via /ip dhcp-relay in broadcast-helper mode — but for WoL specifically, the most reliable approach is a targeted /tool wol script triggered by an IP firewall rule.
Add an Input chain rule that matches WoL packets arriving from your management VLAN. This rule controls who is allowed to reach the router's input chain on UDP/9 — it doesn't automatically call /tool wol. The relay action is handled by the named script in Step 2, which the admin (or a scheduler) runs explicitly. This two-step design keeps the firewall policy separate from the relay logic.
[admin@MikroTik] > /ip firewall filter add \ chain=input \ protocol=udp \ dst-port=9 \ in-interface=vlan10 \ src-address=192.168.10.0/24 \ action=accept \ comment="Allow WoL from MGMT VLAN" # This accepts the UDP/9 packet into the router's input chain. # It does NOT auto-relay to VLAN 20 — see Step 2 for the relay script. # Without this rule, a default drop-all policy would silently discard it.
RouterOS does not natively parse magic packet payloads to extract the target MAC. For a small, known set of servers (which is the realistic SMB/hospitality case), the simplest and most reliable approach is a named script per target. An admin calls the script; the router blasts the wake packet out the correct VLAN interface.
[admin@MikroTik] > system script add \ name="wake-fileserver-vlan20" \ source="/tool wol interface=vlan20 mac=AA:BB:CC:DD:EE:FF" # To run manually: [admin@MikroTik] > system script run wake-fileserver-vlan20 # Or schedule it (same as Section 02 scheduler example). # Add one script per server — MAC is the only thing that changes.
If your VLANs are built on a bridge (the correct RouterOS v7 approach), the interface you pass to /tool wol must be the VLAN interface (e.g. vlan20) — not the physical port or the bridge. The VLAN interface is what has the broadcast domain membership. Targeting ether2 directly will send an untagged broadcast and the target NIC will never see it.
DHCP relay (/ip dhcp-relay) forwards DHCP broadcasts between subnets — port 67/68 only. It does not relay arbitrary UDP broadcasts on port 9. Configuring a DHCP relay and expecting it to carry magic packets will silently do nothing. The packets need to be re-originated by a script targeting the correct interface.
04
You're in Athens, the server is in a hotel server room in Chania, and you need it online in ten minutes. Here's the path that actually works.
Tailscale gives every node a stable 100.x.x.x address regardless of NAT, Starlink CGNAT, or dynamic IP. If your RouterOS device is running a Tailscale container (or you have a Tailscale-connected Linux jump host on the LAN), you can reach the router's script execution path from anywhere on your tailnet.
There are two patterns. Choose based on your setup:
Pattern A — RouterOS with Tailscale container: The container has a tailnet IP. You SSH into the container, which then runs a RouterOS API call or simply executes a pre-placed script. Requires RouterOS container feature (ARM/x86 devices).
Pattern B — Remote SSH into RouterOS directly via Tailscale: RouterOS SSH is exposed only on the Tailscale interface address. You SSH in and run the script. Simpler, no container needed.
First, lock RouterOS SSH so it only listens on the Tailscale-assigned interface. This is the security foundation — if SSH isn't reachable from the WAN, a compromised WoL path can't become a foothold.
[admin@MikroTik] > ip service set ssh address=100.64.0.0/10 # 100.64.0.0/10 covers the full Tailscale CGNAT range. # Adjust to your specific tailnet subnet if you want tighter control. # All other source IPs will be rejected at the service level. [admin@MikroTik] > ip service print Flags: X - disabled # NAME PORT ADDRESS CERTIFICATE 0 telnet 23 (disabled) 1 ftp 21 (disabled) 2 www 80 (disabled) 3 ssh 22 100.64.0.0/10 4 www-ssl 443 (disabled) 5 api 8728 (disabled) 6 winbox 8291 192.168.10.0/24 (mgmt VLAN only) 7 api-ssl 8729 (disabled) # Winbox stays on MGMT VLAN only. SSH locked to tailnet.
user@laptop:~$ ssh admin@100.x.x.router "/system script run wake-fileserver-vlan20" # Single command. SSH exits after the script runs. # No interactive session needed. # Wrap in a shell alias or a Makefile target for one-keystroke wakes. # Or interactively: user@laptop:~$ ssh admin@100.x.x.router [admin@MikroTik] > system script run wake-fileserver-vlan20
RouterOS does not restart Tailscale automatically after a reboot unless you have a scheduler entry that runs /container start [find name="tailscale"] on startup. If the router rebooted overnight (power cut, firmware update) and Tailscale isn't running, your SSH path doesn't exist. Add a startup scheduler or use a secondary out-of-band access method — Winbox over the LAN as fallback at minimum.
You might try running wakeonlan AA:BB:CC:DD:EE:FF from a Tailscale-connected Linux box and directing it at the target's tailnet IP or a broadcast. This fails because: (a) the target machine is off and has no tailnet presence, and (b) even if you direct it at the LAN broadcast, the Linux host has no Layer-2 adjacency to the target's subnet. The magic packet must be sent from something with physical (or bridged) access to that subnet — which is exactly what RouterOS has.
05
An open WoL relay is an open power-on vector. Lock it down before a guest VLAN or a misconfigured device abuses it.
By default, if your forward chain is permissive, any host on any VLAN could craft a UDP/9 packet to a broadcast address and power on machines they shouldn't touch. The hardening model is simple: WoL packets should only ever reach RouterOS's input chain from a defined management source, and should never be forwarded between untrusted VLANs.
[admin@MikroTik] > ip firewall filter # 1. Drop WoL from guest / IoT VLANs — before any accept rule [admin@MikroTik] /ip/firewall/filter> add \ chain=input protocol=udp dst-port=9 \ in-interface-list=UNTRUSTED \ action=drop \ comment="Drop WoL from untrusted VLANs" # 2. Drop WoL in forward chain — packets should never transit, only input [admin@MikroTik] /ip/firewall/filter> add \ chain=forward protocol=udp dst-port=9 \ action=drop \ comment="Drop WoL forward — use /tool wol relay instead" # 3. Accept WoL only from MGMT VLAN to input [admin@MikroTik] /ip/firewall/filter> add \ chain=input protocol=udp dst-port=9 \ in-interface=vlan10 \ src-address=192.168.10.0/24 \ action=accept \ comment="WoL from MGMT only" # Rule order matters. Drop untrusted FIRST, then accept MGMT. # Add these ABOVE your generic drop-all rule at the end of the chain.
Limit the blast radius. If an attacker can send a magic packet, they can power on machines — but they still need credentials to do anything useful once the machine is up. Your real exposure is the window between power-on and full boot where services start unauthenticated. Make sure your servers require authentication before accepting any connections and that boot-time services (SMB, RDP, SSH) aren't exposed to untrusted segments.
Interface lists are your friend. Create an UNTRUSTED interface list containing guest Wi-Fi, IoT, and any third-party VLANs. Drop UDP/9 from this list globally. You only need one rule, and adding a new untrusted VLAN to the list automatically inherits the protection.
WoL over port 0 / raw frames. Some tools bypass UDP entirely and send the magic packet as a raw Ethernet frame (EtherType 0x0842). RouterOS firewall filter rules only catch IP traffic. If you're on a CRS switch, ensure that untrusted bridge ports cannot inject raw frames to the servers' bridge domain by using bridge port isolation or private VLANs.
06
You want to know when a machine was woken, who triggered it, and whether it actually came up — RouterOS logging and simple ping probes cover this.
Add a logging action to your firewall accept rule so every WoL trigger leaves a trace in the RouterOS log with timestamp and source IP.
[admin@MikroTik] > ip firewall filter set \ [find comment="WoL from MGMT only"] \ action=log log-prefix="WOL-TRIGGER" \ log=yes # Or add a separate log rule just before the accept rule: # chain=input, same match, action=log, log-prefix="WOL-TRIGGER" # Log entries appear in /log print — and in your syslog server if configured. [admin@MikroTik] > log print where topics~"firewall" and message~"WOL-TRIGGER" may/02 14:33:01 firewall,info WOL-TRIGGER: in:vlan10 \ src-mac AA:BB:CC:11:22:33, proto UDP, \ 192.168.10.5:50234->192.168.10.255:9, len 102 # Source MAC + IP tells you exactly who sent the WoL.
A script that sends WoL and then pings the target a few seconds later gives you confirmation — and you can log or email the result.
[admin@MikroTik] > system script add name="wake-and-verify-fileserver" source={ /tool wol interface=vlan20 mac=AA:BB:CC:DD:EE:FF :delay 45s :local result [/ping address=192.168.20.50 count=3 as-value] :if ($result->"received" > 0) do={ :log info "WOL-OK: fileserver 192.168.20.50 responded after wake" } else={ :log warning "WOL-FAIL: fileserver did not respond after 45s" } } # as-value returns a dict in ROS v7 — use ->"received" to get the packet count. # 45s gives most machines enough time to POST and reach OS network stack. # Adjust for slow hardware or full-disk-encryption unlock prompts. # For email alerts: add /tool e-mail send in the else block (requires SMTP config).
Forward logs to a syslog server. RouterOS's on-device log is volatile and limited. Configure /system logging action to send to a remote syslog (Graylog, Loki, or even a simple rsyslog instance on your management server). Filter for WOL-TRIGGER and alert on any source outside your expected management IPs.
Unexpected WoL is a threat signal. In a hotel or SMB environment, a WoL packet from an unexpected source IP — especially from a guest VLAN if your firewall rules ever drift — means either a misconfiguration or a deliberate probe. Treat unexpected WoL events the same as unexpected port scans: investigate the source immediately.
Pair with Netwatch for state tracking. /tool netwatch monitors a host's reachability and can trigger scripts on state change. Configure a Netwatch entry for each critical server: when it transitions from down to up, log the event with timestamp. Cross-referenced with WoL logs, you get a full audit trail of who woke what and when it came online.
[admin@MikroTik] > tool netwatch add \ host=192.168.20.50 \ interval=30s \ up-script="/log info \"NETWATCH: fileserver UP\"" \ down-script="/log warning \"NETWATCH: fileserver DOWN\"" # Logs every state transition. Correlate with WOL-TRIGGER timestamps # in /log print to build a full wake-to-online audit trail.
Takeaways
/tool wol targeted at the correct VLAN interface./tool wol interface= must point to the VLAN interface, not the physical port or bridge. This is the single most common misconfiguration. If packets aren't arriving, check the interface name first.100.64.0.0/10 as a minimum before relying on this path operationally.UNTRUSTED interface list is safer and easier to maintain than per-VLAN rules. Add new untrusted VLANs to the list and the protection is automatic.NOCTIS designs and manages segmented, secure networks for hospitality properties — VLANs, firewall policies, remote management, and Starlink failover. If you're relying on a flat network or a consumer router, you're one misconfiguration away from a guest incident.
Book a 30-min Discovery Call →