# [Solved] How to Wake-On-LAN from Different Subnet

## solamour

```
com1

    | 192.168.0.1

    |

    |

    | 192.168.0.254

gentoo

    | 192.168.1.254

    |

    |

    | 192.168.1.1

android

```

"gentoo" has 2 network interfaces (192.168.0.254 and 192.168.1.254). I can do Wake-On-LAN from "gentoo" to "com1" with "wakeonlan -i 192.168.0.255 MAC_ADDRESS_OF_COM1". Now, I'd like to do the same from "android", which is in a different subnet, but so far nothing seems to work.

Q1) Should I use the same command (i.e. "wakeonlan -i 192.168.0.255 MAC_ADDRESS_OF_COM1") or something else?

Q2) How should I configure "gentoo", so that the magic packet is passed to 192.168.0.255? "gentoo" is using shorewall, if that makes any difference.

__

solLast edited by solamour on Thu Jul 10, 2014 3:50 am; edited 1 time in total

----------

## eccerr0r

The WOL packets are ethernet raw packets and these are not "routable" so you can't traverse the router, which is what I think you're doing with the Gentoo machine.

You'll have to either write a repeater program on the Gentoo box to recreate the WOL packet on the other network.  There should be a way to get Shorewall to replicate the packet on the other network, which unfortunately I'm not familiar with.  Or you could write an http cgi script of sorts to create a WOL packet on that side of the net.

Since this is a firewall I'm not sure this is a solution but if you bridge the two LAN segments to one big segment, this also gets around the routing issue.

----------

## szatox

According to wiki

 *Quote:*   

> The magic packet is a broadcast frame containing anywhere within its payload 6 bytes of all 255 (FF FF FF FF FF FF in hexadecimal), followed by sixteen repetitions of the target computer's 48-bit MAC address, for a total of 102 bytes.
> 
> Since the magic packet is only scanned for the string above, and not actually parsed by a full protocol stack, it may be sent as any network- and transport-layer protocol

 

So, it doesn't matter what kind of packet you send as long as it reaches target device and contains proper sequence.

Now, to send packet across a router, you must assign target IP from the other network. Unfortunately that's not enough yet.

Before IP4 packet is sent,  router sends broadcast ARP request asking to what MAC that particular IP is assigned. And here we hit the wall, as no device would respond. To get response, you must target an existing, active device. Unfortunately, in switched network, once IP is assigned to MAC, it is also assigned to a particular socket.  Hubs do not perform such sophisticated operations, so in this case it could work  :Laughing: 

Well, while not completely impossible, it's not a very effective way to handle it. I suppose it would be easier to login into router and trigger magic packet from there. Or, replace router with a switch. (Yes, several physical devices enslaved in a bridge will act as a switch) - obviously it would no longer be a firewall.

However, there is one more thing that MIGHT be worth checking: IPv6

Can anyone give a hint if it's possible to route IPv6 packet into the void?

----------

## papahuhn

One can hardwire the broadcast mac address (all F's) to some free IP on the router with arp -s and perform NAT to that IP. It's how I do WoL from WAN.

----------

## solamour

 *papahuhn wrote:*   

> One can hardwire the broadcast mac address (all F's) to some free IP on the router with arp -s and perform NAT to that IP. It's how I do WoL from WAN.

 

After some investigation and experiments, here is how I made it work.

1) Pick an address that is not currently used in "192.168.0.x" and set its MAC address to all FFs. In this example, I picked "192.168.0.9".

```
arp -s 192.168.0.9 FF:FF:FF:FF:FF:FF
```

2) Make sure the new bogus address is correctly defined.

```
arp
```

3) Let the magic packet go through from "wlan" (192.168.1.x) to "loc" (192.168.0.x).

```
/etc/shorewall/rules

    ...

    ACCEPT              wlan    loc     udp     9
```

4) From "192.168.1.x" side, I send the magic packet to the bogus address (192.168.0.9) with the MAC address of the target device I'd like to wake up.

5) If I ever want to remove the bogus address and stop Wake-on-Lan, I use "-d" flag. For my case, "enp0s14" is the network interface name for "192.168.0.254".

```
arp -i enp0s14 -d 192.168.0.9
```

I think I can also use "ip" instead of "arp". The result is the same.

```
ip neigh add 192.168.0.9 lladdr FF:FF:FF:FF:FF:FF nud permanent dev enp0s14

ip neigh show

ip neigh del 192.168.0.9 dev enp0s14
```

Thanks everyone for taking time to respond.

__

sol

----------

## szatox

 *Quote:*   

> 1) Pick an address that is not currently used in "192.168.0.x" and set its MAC address to all FFs. In this example, I picked "192.168.0.9". 

  why not 192.168.0.255?

IP broadcast will never be occupied by a client so there is no reason not to bind it to arp broadcast, so you don't have to reserve it or guess every time you want it. Unless router cuts it short of course. But then, why would router drop incoming broadcast?  :Smile: 

----------

## papahuhn

 *szatox wrote:*   

>  *Quote:*   1) Pick an address that is not currently used in "192.168.0.x" and set its MAC address to all FFs. In this example, I picked "192.168.0.9".   why not 192.168.0.255?
> 
> IP broadcast will never be occupied by a client so there is no reason not to bind it to arp broadcast, so you don't have to reserve it or guess every time you want it. Unless router cuts it short of course. But then, why would router drop incoming broadcast? 

 

DNAT has to be performed in the PREROUTING chain on a router. Then, however, it is processed as a local destined packet by the routing logic, as the trace shows:

```

 3)               |            ip_rcv_finish() {

 3)   4.353 us    |              ip_route_input_noref();

 3)               |              ip_local_deliver() {

 3)               |                iptable_mangle_hook() {

 3)   0.248 us    |                  ipt_do_table();

 3)   0.719 us    |                }

 3)               |                iptable_filter_hook() {

 3)   0.389 us    |                  ipt_do_table();

 3)   0.944 us    |                }

 3)               |                ip_vs_reply4() {

 3)   0.246 us    |                  ip_vs_out.part.22.constprop.25();

 3)   0.792 us    |                }

 3)               |                ip_vs_remote_request4() {

 3)   0.240 us    |                  ip_vs_in.constprop.23();

 3)   0.784 us    |                }

 3)   0.165 us    |                nf_nat_ipv4_fn();

 3)   0.093 us    |                ipv4_helper();

 3)   0.473 us    |                ipv4_synproxy_hook();

 3)   0.105 us    |                ipv4_confirm();

 3)   1.636 us    |                ip_local_deliver_finish();

 3) + 10.972 us   |              }

 3) + 16.930 us   |            }

```

----------

