RV340 and Broadcast from WAN for WOL

Edgard666 · ‎04-02-2021

Hi,

I have a new RV340 router, but could not find a way with the GUI to broadcast a packet from WAN. With the CLI, I could add a static ARP entry with an IP having a MAC address ffff-ffff-ffff. But since the CLI is disabled, I didn’t find a way to do it.

Adding the ARP entry was something easily done with my previous Zyxel router and even with a 50$ Ubiquity router. And by doing so, I was able to create a port forwarding rule which would send a packet from WAN to that fake IP address and therefore broadcast it on the LAN…

In this case, the packet being a “magic packet”, used to wake some computers from WAN.

Did I by any chance miss a way to do that using the GUI, or is that router really so limited that it’s not something possible?

Or would someone have another method to wake computers from WAN? A method not using a third-party software or a VPN?

Thanks for your help.

Edgard666 · ‎04-15-2021

No one has an alternative?

Sky Walker · ‎07-14-2021

Try "Block MAC address on the list with wrong IP address" option in the DHCP's list. This should be the ARP Binding.

nagrajk1969 · ‎07-26-2021

Hi Edgar

One query?

- why are you trying to bind a mac-addr of ffff-ffff-ffff (which is a broadcast mac-address) for a lan-host which needs to be woken uo by the WoL magic-packet? Shouldnt it be the actual-mac-address of the lan-host to which the magic-packet is destined for?

If your deployment is as below:

HostPC(192.168.1.10/24)----1.1/vlan1[RV340]wan(200.200.200.22)------{internet}----[Host-WoL]

Iam assuming that the WoL-Host is the one which sends the "magic-packet" for waking up Lan-hostPC(192.168.1.10)

Iam also assuming that when you send a WoL magic-packet you will be using UDP-port 9 (which is the standard dst-port used generally for WoL traffic)

So say suppose we do the below on RV340

1. In services, we create/define a service name udpWoL with UDP protocol and start-port and end-port as 9

2. In Port-forwarding, we add a port-forwarding rule on wan port (wan1 or wan2 whichever is configured with the ipaddr 200.200.200.22 as per diagram above) and select "udpWoL" as the service for external and internal and configure the internal-host as 192.168.1.10 on wanX port

3. Now i suggest you try this next steps too on RV340 before you start sending the WoL packets from the wan-host(Host-WoL)

a) In the Security page, there is the feature "Ip Source Guard" - So add a static-ip-mac binding entry for the lan-host ipaddr 192.168.1.10 with the mac-addr of the lan-host, which could be lets say for example "00:17:9a:b3:92:4d"

b) apply and save

4. Now from the wan-host-wol, send the WoL magic-packet (which has the lan-host mac-addr 00:17:9a:b3:92:4d configured into the wol payload as required) to 200.200.200.22 using dst udp-port 9

From here on i would suggest, you capture (by using port-mirroring) on the lan-side of RV340 and check whether after processing the inbound magic-packet on wan interface, the RV340 is forwarding the magic-packet further on vlan1/lan-interface TO THE MAC-ADDRESS OF THE LAN-HOST

In my understanding, once the lan-host is "asleep" (and configured to be up with WoL signalling received on the NIC), the ipaddr of the lan-host does not come into picture as its not up and hence will therefore ONLY RESPOND TO L2 TRAFFIC SENT TO THE MAC-ADDRESS

- But then again on RV340, once it received the WOL packet on WAN and since the port-forward rule says send it further to internal-host 192.168.1.10...it would do a ARP lookup to get the mac-address of 192.168.1.10...and this is where the ip-source-guard binding entry of static-ip-to-mac for 192.168.1.10 will help in getting the mac-address available in the arp-cache so that RV340 can simply forward it to the mac-address of the specified port-forwarding-internal-ipaddr of 192.168.1.10 (even-though the lan-host is asleep)

Hopefully this above points should help in your further debugging

thanks & best regards

Edgard666 · ‎08-03-2021

@nagrajk1969 wrote:
Hi Edgar

One query?
- why are you trying to bind a mac-addr of ffff-ffff-ffff (which is a broadcast mac-address) for a lan-host which needs to be woken uo by the WoL magic-packet? Shouldnt it be the actual-mac-address of the lan-host to which the magic-packet is destined for?

If your deployment is as below:

HostPC(192.168.1.10/24)----1.1/vlan1[RV340]wan(200.200.200.22)------{internet}----[Host-WoL]

Iam assuming that the WoL-Host is the one which sends the "magic-packet" for waking up Lan-hostPC(192.168.1.10)
Iam also assuming that when you send a WoL magic-packet you will be using UDP-port 9 (which is the standard dst-port used generally for WoL traffic)

So say suppose we do the below on RV340

1. In services, we create/define a service name udpWoL with UDP protocol and start-port and end-port as 9
2. In Port-forwarding, we add a port-forwarding rule on wan port (wan1 or wan2 whichever is configured with the ipaddr 200.200.200.22 as per diagram above) and select "udpWoL" as the service for external and internal and configure the internal-host as 192.168.1.10 on wanX port

3. Now i suggest you try this next steps too on RV340 before you start sending the WoL packets from the wan-host(Host-WoL)
a) In the Security page, there is the feature "Ip Source Guard" - So add a static-ip-mac binding entry for the lan-host ipaddr 192.168.1.10 with the mac-addr of the lan-host, which could be lets say for example "00:17:9a:b3:92:4d"
b) apply and save

4. Now from the wan-host-wol, send the WoL magic-packet (which has the lan-host mac-addr 00:17:9a:b3:92:4d configured into the wol payload as required) to 200.200.200.22 using dst udp-port 9

From here on i would suggest, you capture (by using port-mirroring) on the lan-side of RV340 and check whether after processing the inbound magic-packet on wan interface, the RV340 is forwarding the magic-packet further on vlan1/lan-interface TO THE MAC-ADDRESS OF THE LAN-HOST

In my understanding, once the lan-host is "asleep" (and configured to be up with WoL signalling received on the NIC), the ipaddr of the lan-host does not come into picture as its not up and hence will therefore ONLY RESPOND TO L2 TRAFFIC SENT TO THE MAC-ADDRESS

- But then again on RV340, once it received the WOL packet on WAN and since the port-forward rule says send it further to internal-host 192.168.1.10...it would do a ARP lookup to get the mac-address of 192.168.1.10...and this is where the ip-source-guard binding entry of static-ip-to-mac for 192.168.1.10 will help in getting the mac-address available in the arp-cache so that RV340 can simply forward it to the mac-address of the specified port-forwarding-internal-ipaddr of 192.168.1.10 (even-though the lan-host is asleep)

Hopefully this above points should help in your further debugging

thanks & best regards

Hi,

Thanks a lot for your response, it may be a solution to the problem in some cases, but unfortunately not in mine.

Not in mine because of two reasons :

1. It may not work in cases like mine, where there are some Switches between the router and the host to wake up. Switches which doesn't have a static mac address like the router. That is why WOL are broadcasted from in an internal network, and not using the IP directly. The packet may reach the switch, but will probably not go any further than that.

2. Because it will block any unknown device to connect to the network in the future, which is not an option in a lot of cases.

With the ffff-ffff-ffff entry, Switches or not, the packet being broadcasted to all the hosts, it will work, and that without blocking any unknown device to connect to the network

In any case, thanks again for your help.