Wake-On-Lan from Public Network (MikroTik practical example)

Some network devices and PCs can listen for incoming special packets on their ethernet interfaces even when shutdown, and this is used to allow them to be powered up with a special magic packet, which is used by Wake-On-Lan (from now WOL). Let’s see how we can use WOL from Public Network on our home RouterOS-based Mikrotik Router.

WOL is usually done by generating a packet with destination IP address the broadcast address of the network (in a common 192.168.0.0/24 network, it is directed to 192.168.0.255 or 255.255.255.255), which produces an ethernet frame with FF:FF:FF:FF:FF:FF destination mac address. This broadcast frame is processed by all the hosts on the lan segment. What does it make this packet magic? The fact that it must contain the Mac Address of the device to be woken up, repeated 16 times. When the powered off device’s ethernet card detects this special frame, it powers up the device.

Usually the magic packet is an UDP packet with destination port 0, 7 or 9, but this is not mandatory. BTW, I will use UDP port 9 in the examples.

You can find more info on WOL on Wikipedia.

Using WOL from the Internet

Suppose that you have a NAS in your home network that you would like to power on only when needed, to get some documents you have stored on it, and that you don’t have other devices active on the home network to which you can connect in order to use WOL, wouldn’t it be useful to be able to use WOL from the Internet? How can we produce a broadcast frame on the internal LAN from the public network?

I’ve build this simple setup in Eve-NG network simulator, with a virtual MikroTik router that simulates our home router, with eth1 as WAN interface (I’m using private IP addressing in 192.168.60.0/24 but consider it a public address exposed on the Internet) and eth2–3–4 grouped in a bridge called lan_bridge with IP address 192.168.1.1/24 and a DHCP server enabled with 192.168.1.10–192.168.1.50 pool of addresses available for clients on the internal LAN.

We could generate a magic packet directed to the public IP address of our home router, but then how can we force it to change it to a broadcast packet? The first simplest solution that came into my mind was to use destination NAT to change the magic packet destined to 192.168.60.141 to 192.168.1.255 but on MikroTik or Linux-based routers this doesn’t work (I think that directed broadcast forwarding is not supported) and the packet is discarder.

So, how can we generate the magic packet on the 192.168.1.0/24 lan to power up our devices? We can implement the following trick:

1. Allocate an unused IP address in 192.168.1.0/24, such as 192.168.1.100
2. Define a static ARP resolution on MikroTik router, setting FF:FF:FF:FF:FF:FF as 192.168.1.100 mac address
3. Implement a pre-routing destination-nat rule on MikroTik router in order to change incoming traffic directed to its Internet-facing interface and to UDP port X (let’s choose 9999) by changing the destination address to 192.168.1.100 and the destination port to 9

Et voilà, now when you’ll send a magic packet to 192.168.60.141 with destination port 9999/UDP, MikroTik pre-routing NAT processing will change the destination address to 192.168.1.100. Then MikroTik will route the packet toward lan_bridge, which is on that subnet, and when it will prepare the ethernet frame that will contain the forwarded packet it will put FF:FF:FF:FF:FF:FF as destination Mac Address, thus producing a broadcast packet on the internal LAN, even if the destination IP address is a unicast IP.

Security Warning: a packet sent with 9999/UDP port on the public address of your router will generate a broadcast packet on your internal network, so it is highly reccomended to rate-limit the number of packets that are forwarded.

MikroTik configuration

Basic configuration

# Bridge eth2-3-4
/interface bridge
add name=lan_bridge
/interface bridge vlan
add bridge=lan_bridge vlan-ids=1
/interface bridge port
add bridge=lan_bridge interface=ether2
add bridge=lan_bridge interface=ether3
add bridge=lan_bridge interface=ether4

# Enable DHCP client on eth1 (WAN interface)
/ip dhcp-client
add disabled=no interface=ether1

# Setup internal network and enable DHCP Server
/ip address
add address=192.168.1.1/24 interface=lan_bridge network=192.168.1.0
/ip pool
add name=dhcp_pool ranges=192.168.1.10-192.168.1.50
/ip dhcp-server
add address-pool=dhcp_pool disabled=no interface=lan_bridge name=dhcp_server
/ip dhcp-server network
add address=192.168.1.0/24 gateway=192.168.1.1 netmask=24

ARP resolution “trick”

/ip arp add address=192.168.1.100 interface=lan_bridge mac-address=FF:FF:FF:FF:FF:FF

Firewall NAT and Forwarding rules

As suggested before, we will implement a forwarding rule that allows the traffic directed to 192.168.1.100 but with a rate-limiting check that will allow 1 packet every 10 seconds from a specific public source address, with a burst of 3 (this effectively allows 4 packets to be forwarded, this could be due to how MikroTik dst-limit works, I did not dig into this very much since the practical effect is the same for the purposes of this HowTo).

/ip firewall nat
add action=dst-nat chain=dstnat dst-port=9999 in-interface=ether1 log=yes log-prefix=PRE-RT: protocol=udp \
    to-addresses=192.168.1.100 to-ports=9

/ip firewall filter
add action=accept chain=forward dst-address=192.168.1.100 dst-limit=1/10s,3,src-address in-interface=ether1 log=yes \
    log-prefix=FWD: out-interface=lan_bridge
add action=drop chain=forward log=yes log-prefix=DROP:

Note: in the configuration above I log all the drops for testing purposes, in a real setup I suggest you to ratelimit the drops per src-address, to avoid flooding your log collector if someone floods you from the Internet.

Here you can see the whole configuration in a more readable format with the syntax highlighting in Sublime Text:

RouterOS Configuration

Testing MikroTik setup

In order to test what I’ve implemented, I’ve downloaded on my MacBook Pro the wakeonlan software package (from MacPorts) and I’ve generated 10 magic packets in row with the following command (sudo asks for the password only the first time, so the command is repeated 10 times very quickly):

% for i in $(seq 1 10) ; do sudo wakeonlan -i 192.168.60.141 -p 9999 aa:bb:cc:dd:ee:ff ; done
Sending magic packet to 192.168.60.141:9999 with aa:bb:cc:dd:ee:ff
Sending magic packet to 192.168.60.141:9999 with aa:bb:cc:dd:ee:ff
Sending magic packet to 192.168.60.141:9999 with aa:bb:cc:dd:ee:ff
Sending magic packet to 192.168.60.141:9999 with aa:bb:cc:dd:ee:ff
Sending magic packet to 192.168.60.141:9999 with aa:bb:cc:dd:ee:ff
Sending magic packet to 192.168.60.141:9999 with aa:bb:cc:dd:ee:ff
Sending magic packet to 192.168.60.141:9999 with aa:bb:cc:dd:ee:ff
Sending magic packet to 192.168.60.141:9999 with aa:bb:cc:dd:ee:ff
Sending magic packet to 192.168.60.141:9999 with aa:bb:cc:dd:ee:ff
Sending magic packet to 192.168.60.141:9999 with aa:bb:cc:dd:ee:ff

I’ve chosen aa:bb:cc:dd:ee:ff as Mac Address of the device to be woken up. Let’s have a look at the MikroTik logs to see what happens:

Logs on Mikrotik Router

As you can see, the Pre-Routing NAT (src-nat chain) rule is triggered 10 times due to the 10 packets above, but the forwarding rule that allows the traffic to pass is triggered only 4 times, the other 6 times we have a drop.

I’ve also started a packet capture on PC interface Fa0/0 (its a virtual router, this is why the interface has such a name). The Fa0/0 interface is connected to the MikroTik lan_bridge through eth2 MikroTik interface, in fact it gets an IP address via DHCP:

PC#sh dhcp lease
Temp IP addr: 192.168.1.49 for peer on Interface: FastEthernet0/0
Temp sub net mask: 255.255.255.0
DHCP Lease server: 192.168.1.1, state: 5 Bound
DHCP transaction id: 18AE
Lease: 600 secs, Renewal: 300 secs, Rebind: 525 secs
Temp default-gateway addr: 192.168.1.1
Next timer fires after: 00:04:53
Retry count: 0 Client-ID: cisco-c202.0c94.0000-Fa0/0
Client-ID hex dump: 636973636F2D633230322E306339342E
303030302D4661302F30
Hostname: PC

Fa0/0 interface receives the magic packet due to it’s FF:FF:FF:FF:FF:FF destination mac address, but then it ignores the packet because it does not contain traffic destined to its IP address. The only purpose of the PC is to make the lan segment active in the lab and show the magic packet reception on the internal lan. In the following image you can see the 4 magic packets containing aa:bb:cc:dd:ee:ff mac address 16 times:

Wake-On-Lan Magic Packet Capture

You can generate the magic packet also via phone with apps like WOL on IOS:

IOS WOL App Interface

You can configure your home router to register its public IP address on a service like No-IP and then configure your WOL app with the FQDN you registered (such as myhomenetwork.no-ip.org).

Conclusions

Credits for this idea go to my boss G.D. which pointed me in the right direction when I was thinking about how to trigger the broadcast packet on my internal LAN from the public network. I hope this will be the first of some quick MikroTik How-Tos that will show you the flexibility of these incredible low-cost but powerful routers. I’ve spent about 70 euros for a MikroTik Hap² router that is able to manage my 1Gbps internet connection, with 4–500 Mbps wireless data rate peaks on 5Ghz, with tens of firewall rules, two pppoe connections (one in a specialized vrf, maybe this will be the topic of the next article) and scripts running in the background to manage dynamic Access Control Lists (I check the IP address of some well-known FQDNs and I add them to a trusted sources list with an expiration time, in order to allow only some public IP addresses to access services in my home network). If you like to experiment, have a look at MikroTik site and if you want to experiment without spending an euro, just download the virtual image of the MikroTik Cloud Router and launch it in EVE-NG Network Simulator to have some fun! 😉

Originally published at http://networkingpills.wordpress.com on June 14, 2020.