Recently, I discovered an interesting topic. I try to send a WOL packet into a different subnet. In my case the subnet is also further complicated because it is actually located over the internet and I am connected through a wireguard server and client tunnel. I know that a WOL is normally just broadcast in the local LAN and not forwardet into other LANs but since you provide the option to set an IP address additionally to the MAC I suspect you might be knowledgeable in this area. :)
What I actually CAN do is send a WOL back FROM THE CLIENT side of my tunnel.
It will travel from the client device to the wireguard client where it has to leave the LAN and go into the tunnel LAN. It will then travel over the internet. From there it will reach my other internet connected ISP router, then into my edge router which acts as DHCP, and from there it will go to the wireguard server where it will leave the tunnel IP range and go into the (third) LAN range and will then wake up a client device in that (third) LAN.
I am not shure which device will actually send the broadcast into this LAN.
Maybe it is the edge router which is the gateway for it.
Or maybe it is the wireguard server, which is a Raspberry Pi, a client in that LAN.
Since subnet directed broadcasts are by default deactivated on routers I suspect the Raspberry might be doing it due to a failure in its configuration: When turning it into a wireguard server it will be set to forward packages.
Now, what I CANNOT do is waking up a device the other way around, FROM THE SERVER's LAN to the client's LAN.
Somewhere in this chain a router will not forward the broadcast from the wireguard server’s side into the wireguard client’s side. I did not find any settings on the TP-Link which is involved. But it might also be that the TP-Link delivers the package upstream to the ISP router (after it left the wireguard tunnel) and the ISP router is not broadcasting it.
This explanation sounds complicated but it is actually very straightfoward: The package comes in from the internet but inside the wireguard tunnel. Because of this it will travel through the incoming router until it reaches the wireguard client. On this client it will leave the tunnel and then will have to find the actually correct destination LAN for the WOL broadcast. But this client is one LAN "behind" this target LAN. Therefore it has to find the gateway, travel "upstream" so to speak and then the router between those two LANs has to broadcast it (probably. But maybe it will travel even further to the gateway of the destination LAN and this second router will broadcast it).
Well, maybe someone have something to say to it. :)
After your comments on my initial post I was able to send the WOL over the internet already by giving it the broadcast address "192.168.300.254" in the settings. It will be shown in the wireguard client (this is already on the remote LAN) on eth0 as “wol b8:27:eb:80:e4:60 -> 74:d4:35:fb:22:cc”. It will be shown twice and the source mac changes. So I think it is going out. However, it is not reaching the destination, probably, because from there it would have to travel upwards one LAN still and the TP-Link router over there is not forwarding it.
So I have to solve this.