Welcome to the Tweaking4All community forums!
When participating, please keep the Forum Rules in mind!
Topics for particular software or systems: Start your topic link with the name of the application or system.
For example “MacOS X – Your question“, or “MS Word – Your Tip or Trick“.
Please note that switching to another language when reading a post will not bring you to the same post, in Dutch, as there is no translation for that post!
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.
Hi Ben!
Here a reference to the conversation that triggered this post.
I've added a reference to how to use the broadcast address, for those interested.
Short version: Ben wants to send a WOL over a Wireguard/VPN tunnel.
Maybe this helps for reference:
PC 1 -> LAN 1 -> Wireguard 1 -> Internet -> Wireguard 2 -> LAN 2 -> PC 2
Technically this comes with a few challenges, so any network expert out there: please chime in! 😉
Most solutions mentioned out there, mention a WOL server on the other side.
So in LAN 2 there will be a device that can be connected to, which then can send a WOL inside LAN 2.
That device could be the Wireguard peer (Wireguard 2), in Ben's situation a Raspberry Pi.
Project like this one (same content here) could be a good start.
Note:
Elsewhere I had read that certain more complex routers could potentially handle this as well, or even allow routing of the WOL signal.
However, I suspect that may not be an option for Ben's setup
It is actually:
Internet -> LAN3 -> LAN2 -> Wireguard 2 -> LAN 3 -> PC 2
And I can see the WOL package coming in and out of eth0 on the Wireguard 2. So I think it is just not delivered to LAN3 upstream again.
OK, I'm officially confused haha ...
Can you make a full sketch of the infrastructure?
I really "drew" it. :) After some reading I think it is basically wrong to use my second (own) router the way I do it (with NAT). It is just a means to have a fixed route for all clients in this router's LAN to the tunnel. The clients know about the route because I put it into the router. I am unable to add this static route to the main router from the ISP because it does not offer this option.
So, if I just put the clients in the main LAN they never know about the wireguard forwarder client that is able to route to the server side throught the tunnel.
(uploaded it here for future reference - after a few approved posts you will be able to upload attachments)
Maybe it's me, but I'm a little confused about your drawing haha.
Oh wait, I just need more coffee. The wobbly line is over the Internet I assume.
Well, stacking two routers that use NAT, can indeed cause issues.
I'd set the ISP modem/router in bridge mode as well, or skip your own router (I always prefer using my own router or firewall).
Did you set your own router (on the left) in the DMZ of the ISP router (also on the left)?
Thanks for uploading the file, Hans! Yes, the wobbly line is over the internet.
I don't want to bridge the ISP router because it has a very good wifi6.
No, I did not set my own router in the DMZ, not sure if it is possible. I also don't think it is necessary since I can connect to the router, just not through it.
Yes, NATing here is probably the wrong way to go. Maybe my private router can be set to act more like a switch between two physically seperate LANs with the same IP range and maybe I then still can put something "behind" that router/switch and I am still able to put a static route in the router/switch and a packet that is trying to find the correct IP from "behind" this router/switch will travel accross it and while doing so will get pointed directly to the device I mentioned in the static route.
On the other hand I am currently trying to eliminate this extra LAN completely by using a Pi as a secondary DHCP server which will then be hardcoded to server IPs to some of the clients and will have a wireguard tunnel in it so the clients will be able to connect directly.
This way I should also be able to wake up clients from the other side.
Good that I did upload it - I did run into a bug of the forum which prevented uploading even for me haha 😜
I think double NAT may be an issue indeed. No guarantees, but definitely not helping either. 😉
When looking at my own setup: my second router functions like a switch by disabling DHCP and such.
But by the looks of it, nothing new for you.
You're off to some cool experiments for sure. Nice!
You did make me think about using Raspberry Pi's as well, also for Wireguard, so family can share a NAS for backup purposes.
Oh well, like I didn't have enough projects on my table already haha.
