WOL packets across subnets?
-
I have two particular subnets. 192.168.10.0/24 for wired devices and 192.168.20.0/24 for wireless devices. I like to wake up some PCs around the house by sending WOL packets from my phone. But, now that they're on different subnets, that's not working. Is there any way to configure pfSense to route WOL packets across subnets?
-
You can send Magic Packets to any network directly connected to pfSense via Services > Wake-on-LAN in your pfSense WebGUI.
-Rico
-
Right, but I have a WOL app on my phone that no longer works because now my phone and PCs are on different subnets, so I'm hoping there's a way to get WOL packets to hop across subnets so that the app resumes working.
-
WOL is at the Ethernet level, not IP, so routers will not pass it. The best you can hope for is a relay agent, similar to what may be used with DHCP.
-
Can you go into more detail about that?
-
@dstarr3 said in WOL packets across subnets?:
Can you go into more detail about that?
Not really, as I haven't done that. A relay agent receives the Ethernet frame and transmits it on another network. DHCP relay agents are available with routers from Cisco etc., but I haven't heard of one for WOL. As mentioned above, your only option would be to have WOL originate on pfSense, as it can see all networks.
-
Yes you would need some type of relay or proxy. For example:
https://community.cisco.com/t5/small-business-switches/wake-on-lan-wol-across-different-vlans-on-sg-300-10/td-p/2013610I don't think anything included in pfSense by default can do that.
Steve
-
Come on, WOL is not that complicated and it's well documented.
- https://en.wikipedia.org/wiki/Wake-on-LAN
- AMD: Magic Packet Technology Whitepaper Rev. A (1995) (englisch, PDF; 37 kB)
The "Magic Packet" is sent on OSI L2, usually as UDP to the subnet's broadcast address and might be directed at one of a few ports. I typically use port 7. IMHO p:0 and p:9 work as well.
So if you are on 192.168.1.0/24 and want to wake a machine on 192.168.2.0/24 you sent the Magic Packet to:
UDP 192.168.2.255:7
I did that from a dedicated Crestron control system but have no experience doing so from a phone.The Magic Packet itself is darn simple. It is 6x FF followed by 16x the MAC address of the sleeping host. No spaces or whatsoever in between.
From a mobile phone your best bet might be to use the WOL page of your local pfSense.
-
Yeah, I just spent a while playing around with things in pfSense to see if I could reply/proxy it without installing anything else. But either I'm missing the right incantation or, quite likely, it is blocked somewhere I'm missing.
Steve
-
@stephenw10
Where did you sent the Magic Packet from?The rule I was using is pretty simple an allow from host "Control System" to UDP other subnet's broadcast address with destination port :7
That's on an ALIX with 2.3.2 nano IIRC, but I doubt things have changed in this regard. -
I was using the pfSense WoL client which appears to use port 40000 and also doesn't, from the GUI, allow you to specify a target IP.
More testing needed obviously...Steve
-
Mmm, yeah it won't forward traffic to the broadcast address and that seems like the correct thing to do.
I wonder if that was tightened up since 2.3.X....
-
Not necessarily ... that's Subnet Directed Broadcast.
Try a translator for this page:
https://decatec.de/software/magicpacket-unterstuetzt-nun-wake-lan-andere-subnetze/
which features a Windows .exe to WOL in other subnets. I'm on a Mac so it's not for me. -
Yeah FreeBSD doesn't do that AFAIK and hasn't for some time.
As of March 2007, FreeBSD 7.0 WILL NOT forward directed broadcasts to directly attached local networks. This behaviour is compliant with RFC 2644.
Unless I'm misreading that. It is late here and I lost an hour of sleep last night!
But that's the behaviour I'm seeing.
[2.4.4-RELEASE][root@7100.stevew.lan]/root: wol -i 192.168.126.255 -p 9 00:0e:8e:24:cd:0a Waking up 00:0e:8e:24:cd:0a...
That packet arrives at the pfSense interface the 7100 is in but never leaves the 192.168.126.X interface.
It is passed by the firewall rules and opens states but only on the incoming interface.Running that same command on the firewall between the subnets wakes the client as expected.
Steve
-
Wow horrendous workaround here: https://forum.netgate.com/post/525988
Haven't tried that. Not going to!
-
Mmm, just to confirm attempting to send those increments the counter
packets not forwardable
shown innetstat -s -p ip
.I can't see any way to enable forwarding directed broadcasts either.
This is the expected, and correct, behaviour as far as I can see.
Steve
-
@jahonix said in WOL packets across subnets?:
Come on, WOL is not that complicated and it's well documented.
From that link:
"it could be sent as any network- and transport-layer protocol, although it is typically sent as a UDP datagram to port 0,[6] 7 or 9, or directly over Ethernet as EtherType 0x0842."
Take a look at what's sent on the wire, using Packet Capture or Wireshark. If it's bare Ethernet, then it definitely won't be routed. If UDP, with a broadcast address, then you'll have to figure out how to get pfSense to route it to the correct interface, when there's no network address to route with. There's a reason why broadcasts are not routed.
BTW, when I used WoL, a few years back, it was bare Ethernet.
-
@jahonix said in WOL packets across subnets?:
The "Magic Packet" is sent on OSI L2, usually as UDP
UDP is layer 4. IP is 3 and Ethernet, 2.
-
@stephenw10 said in WOL packets across subnets?:
Yeah FreeBSD doesn't do that AFAIK and hasn't for some time.
...
It is late here and I lost an hour of sleep last night!Strange, I have it working this way, client uses is frequently with this video switcher.
Don't worry about your sleep, same with me. Just 1 hour ahead...
-
@JKnott said in WOL packets across subnets?:
@jahonix said in WOL packets across subnets?:
The "Magic Packet" is sent on OSI L2, usually as UDP
UDP is layer 4. IP is 3 and Ethernet, 2.
Correct, I was wondering how long I could get away with writing it this way.
I am using a UDP frame directed at the other subnet's broadcast address as mentioned before. No need to wireshark. And I'm not there often anymore.