Wake-on-LAN from WAN without forwarding to broadcast

snack · 2024-11-14 11:11:32

I'm trying to understand if it is possible to wake a device in my home network if my router does not support forwarding ports to broadcast. As far as I understood up to now, WoL from WAN can be achieved by redirecting router ports 7 and 9 to the broadcast address of the internal network, something that my router does not support. But in the wiki page about WoL I read:

The router needs to be configured using one of these two options:

   - Forward a different port to each target machine. This requires any target machine to have a static IP address on its LAN.
   - ...

The first option suggests to me that forwarding to broadcast is not strictly required, and that I could simply configure forwarding to the static IP of the device to be awakened. Could this work?
I cannot easily test this option since my router is behind the NAT of my ISP; I could ask for a public, not NATed IP address but I would prefer to understand if the above strategy could work before doing so.
Thanks in advance for any help.

cryptearth · 2024-11-14 11:40:28

if you are behind a cg-nat anyway the capabilities of your router don't really matter - as whatever you would try to send to yourself would get there but filtered by the cg-nat
even if it would highly depend on if the router keeps arp tables and other level-1/-2 stuff or if the forwarding is done on level-3 only - as in the latter case nothing would happen as the router would have no target to forward the wol packet to

due to the cg-nat I recommend get some cheap singleboard computer like a raspberry pi or some cheap clone and a cheap vps at some hoster of your choice
from the sbc you then open a tunnel to tge vps as an outboubd reverse proxy so you can connect to the vps instead which forwards the wol to the sbc which can do a proper level-2 broadcast
for the tunnel make sure to have some hearbeat traffic to keep it open - otherwise it will break because the nat tables gets flushed - but that's a topic when you have a sbc and a vps

Last edited by cryptearth (2024-11-14 11:42:16)

seth · 2024-11-14 14:55:16

Have you tried to send a WOL to the WAN IP of the router from within the LAN?
Depending on whether and how hairpinning and forwarding are implemented, that might make the router treat it like an external package (and forward it) but side-step the CGNAT.

snack · 2024-11-14 18:07:01

@cryptearth I'm not a network expert so I'm not sure I understand all of your points. Anyway as I wrote the NAT issue can be solved by asking the ISP to put my account on a static non-NATed address. Would this solve the issue you are mentioning with the cg-nat?

@Seth I found the WAN address of my router (the one behind the ISP NAT I guess, since it's different from what I get from whatismyipaddress.com), forwarded port 9 UDP to the static IP address of my device, then sent the WOL packet from inside the LAN with `wol -i <wanip> -p 9 <macaddress>` but it didn't work. I guess the router does not forward packets to disconnected IP addresses, since when I save the forwarding rule the IP is automatically changed to the MAC address and the box becomes red. I guess this is sort of error message telling me that what I am attempting does not work... but which anyway answers my question.

Thanks for your help!

seth · 2024-11-14 20:45:31

You could test that theory by trying to forward somthing to an active host this way and try to access it through the WAN IP - can be some netcat or you can also just wireshark the traffic.

cryptearth · 2024-11-15 09:43:29

Sorry, not meant to lose someone on the way.
Yes, if your ISP can switch your contract from cg-nat to direct public it would remove the need for ehat I proposed.
But: Usually such switch isn't free if it's not the default: It's either a premium option or rserved for business customers. So be aware that you may have to pay more for this option.
My idea involves additional cost, too: If not already available a SBC for somewhat between 20 and 200 bucks and the monthly rent for the VPS. So in the end it comes down to math but often a sbc and a vps gets cheaper the longer you use it as the sbc is a one-time cost and a cheap rely vps are available from 0,99 per month - where as the premium option of your isp maybe starts at 5 or 10 bucks (if available for you and if it has a premium fee - if you're able to get the option from your isp for free (I doubt that) I would recommend that, of course).

--- cut here ---
NAT usually works in a somewhat one-way trapdoor: Replies to established outgoing connections are passed through to the originating endpoint - while unknown incoming traffic is blocked. Hence it's often wrongly referred to a "nat firewall" (wrong because a firewall has a different purpose and works differently - just the result is tge same: unknown uncoming traffic is rejected).
So if a customer is behind a cg-nat only replies to already established outgoing connections get routed back to them. Anything that arrives at the cg-nat which isn't a reply but initial income doesn't get further as the cg-nat doesn't known where to forward it to - the very same with the nat in your end-user router, it's basically two routers cacaded.

Also: Outgoing connections can't be hold open forever - at least not without traffic: When an outgoing connection is established the nat adds an entry into the nat table with the two tuples source-ip:source-port and destination-ip:destination-port - along with a timeout how long this entry should be held without traffic.
Each time a packet is routed - no matter if outbound or inbound - this timeout gets reset. But if no traffic flows this timer runs out and closes the connection.
So why is a heartbeat required? In order to keep the timeout from run out and the nat entry be removed a small packet has to be send within the timeout like once every second or so. This way the tunnel from a device within your network to an external server is kept open in order to allow commands to come in from the server into your network.
With such a reverse-proxy it's possible to get around restrictions like cg-nat or similar like on a shared campus wifi. But care must be taken to secure the public endpoint on the public VPS - someone braking into it can take over control of your home network - that's a real danger - had it happen to me twice already. Wasn't fun to change several keys, certificates and passwords.

Last edited by cryptearth (2024-11-15 10:19:31)

Arch Linux

#1 2024-11-14 11:11:32

Wake-on-LAN from WAN without forwarding to broadcast

#2 2024-11-14 11:40:28

Re: Wake-on-LAN from WAN without forwarding to broadcast

#3 2024-11-14 14:55:16

Re: Wake-on-LAN from WAN without forwarding to broadcast

#4 2024-11-14 18:07:01

Re: Wake-on-LAN from WAN without forwarding to broadcast

#5 2024-11-14 20:45:31

Re: Wake-on-LAN from WAN without forwarding to broadcast

#6 2024-11-15 09:43:29

Re: Wake-on-LAN from WAN without forwarding to broadcast

Board footer