Wake-on-LAN using directed broadcast
-
Hi!
I am currently trying to set up a way to wake a host (B) from a host (A) located on a different network.
┌───────────╮ 192.168.Y.1 192.168.Y.2 ┌───────────╮ │ pfSense A ├────────────────────────────┤ pfSense B │ └─────┬─────╯ 192.168.Y.0/30 └─────┬─────╯ 192.168.X.1 │ │ 192.168.Z.1 │ 192.168.X.0/24 192.168.Z.0/24 │ 192.168.X.2 │ │ 192.168.Z.2 ┌─────┴─────╮ ┌─────┴─────╮ │ Host A │ │ Host B │ │ │ │ │ │ ¯\(°_o)/¯ │ │ (-_-)zzz │ │ │ │ │ └───────────╯ └───────────╯When I send the magic packet (UDP/9) from host A to the broadcast address of host B's network, I can see that it gets transmitted up to pfSense B. However, I can find no traces of it on the last mile even though the counter of the rule on pfSense B permitting this kind of traffic gets incremented with each new packet.
What could I be missing here?
The problem seems to be related to the one encountered in this post.
-
@inperpetuammemoriam Maybe try adding a static ARP entry for Host B on pfSense B? Or, just make a shell script on pfSense B to send the WOL packet and run that script via SSH.
/usr/local/bin/wol -i 192.168.2.1 <mac-addr-of-hostB> -
@luckman212 Host B already has a static ARP entry. I currently have a workaround in place that requires regular users to use the functionality provided by pfSense's WebUI. I have restricted the permissions granted to these users to the required minimum but I think that this kind of workaround is still pretty bad as it opens a management port to hosts that shouldn't have this access level.
-
@inperpetuammemoriam Oh I see. Well I'm not sure exactly what you're trying to achieve. You have a handful of local hosts that are sleeping and have a corresponding group of users who individually need to be able to remotely wake them up? Or- something else?
I had a client who had a funny problem: they had a few users who would VPN in and connect to their computers with remote desktop. Some of the less savvy users had a tendency to accidentally shut down their office PC when using RDP. They asked me for a solution and I ended up using a Fingbox which has a nice feature to automatically wake up specified devices if they go offline, and provides a mobile app to manually trigger the WOL and a bunch of other stuff.
You could also write a small PHP script to send the WOL packets, stick it in /usr/local/www, and just share that with your users if you don't want them logging in to the webGUI. If all it does is send a WOL packet it should be reasonably safe, especially if you use a firewall rule to restrict access to a certain set of source IPs.
-
@luckman212 said in Wake-on-LAN using directed broadcast:
@inperpetuammemoriam Oh I see. Well I'm not sure exactly what you're trying to achieve. You have a handful of local hosts that are sleeping and have a corresponding group of users who individually need to be able to remotely wake them up? Or- something else?
Sort of. The hosts that need to be woken up are on a remote site. The /30-subnet is a site-to-site tunnel.
@luckman212 said in Wake-on-LAN using directed broadcast:
I had a client who had a funny problem: they had a few users who would VPN in and connect to their computers with remote desktop. Some of the less savvy users had a tendency to accidentally shut down their office PC when using RDP. They asked me for a solution and I ended up using a Fingbox which has a nice feature to automatically wake up specified devices if they go offline, and provides a mobile app to manually trigger the WOL and a bunch of other stuff.
I also had that problem. In order to ensure that host B is never completely shut down, I had to modify the shutdown behavior of the OS.
@luckman212 said in Wake-on-LAN using directed broadcast:
You could also write a small PHP script to send the WOL packets, stick it in /usr/local/www, and just share that with your users if you don't want them logging in to the webGUI. If all it does is send a WOL packet it should be reasonably safe, especially if you use a firewall rule to restrict access to a certain set of source IPs.
That would still expose a web service running on that firewall. The solution I am using (Apache Guacamole) is able to automatically wake up the remote host when a user initiates a connection. If only I could get the firewall to pass that damn packet...
-
@inperpetuammemoriam I haven't done anything with wol in years and years.. But directed broadcast might be difficult to route and or forward, etc.
But see this solution, where you setup a static arp of specific IP using the broadcast mac, and then send your wol to specific IP on your port 9
-
@johnpoz said in Wake-on-LAN using directed broadcast:
But see this solution, where you setup a static arp of specific IP using the broadcast mac, and then send your wol to specific IP on your port 9
I tried this workaround but I could not get the host to wake up. I will try it once more in order to ensure that I have not become a victim of my own stupidity.
@johnpoz said in Wake-on-LAN using directed broadcast:
@inperpetuammemoriam I haven't done anything with wol in years and years.. But directed broadcast might be difficult to route and or forward, etc.
Why is that so difficult? I remember using a similar approach on another site using a Cisco ASA. I do not remember the directed broadcast being a problem at all.
-
@inperpetuammemoriam directed broadcast is not a unicast IP, it is a IP that points to a broadcast mac.
Forwarding or even routing to something requires to know what mac to send it too. Allowing the sending to broadcast mac through a router/firewall could be seen as a security issue, and might not just be coded for, etc.
It might be possible that some devices/software specifically designed for that function.
I have not done anything with wol for years, and never through pfsense that is for sure. But I could see where some traffic that you want to send to all FFs as the mac could be a problem.
As to your first router sending it through the transit to your 2nd router - that is fine, since its not an IP on that router, so it could just send it on to the next hop mac address.
I think the trick of assigning a specific IP to the all ffs mac might work.. I would set that up, and then see if pfsense sends on the traffic to all ffs. If so and your client doesn't wake up, something there is the problem.
If it was me, I would just ssh to something on the remote network and send the wol from that device. Or just access the 2nd pfsense gui and send the wol.
My only experience with pfsense and wol was vpn to my network, use the pfsense gui to send wol to my PC that I had set to go to sleep.. That would sometimes work, but sometimes the PC just wouldn't wake up... I finally just stopped the PC from going to sleep ;) Since it coming out of standby/sleep was always problematic and the couple of pennies I might save a month wasn't worth the hassle of it not working when I needed to do something.
It could be also that sending to say 192.168.1.100 with all ffs as mac, might not be enough for that client to wake up? Maybe it wants to see its IP and mac in the WOL packet?
Can you get your port 9 forwarding thing to work, if you use a directed IP and then static arp on pfsense for that specific IP?
-
@johnpoz said in Wake-on-LAN using directed broadcast:
Can you get your port 9 forwarding thing to work, if you use a directed IP and then static arp on pfsense for that specific IP?
I just managed to get it working using the aforementioned workaround. I guess that the ARP entry has to be static. Otherwise the final router would probably not forward the magic packet to the destination interface.
@johnpoz said in Wake-on-LAN using directed broadcast:
It could be also that sending to say 192.168.1.100 with all ffs as mac, might not be enough for that client to wake up? Maybe it wants to see its IP and mac in the WOL packet?
It is enough that the packet contains the right MAC address and gets spewed out of the right interface. The IP address serves just for routing the packet through the network to the final router.
