This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

WOL over the Internet

I know this topic has been discussed in the past, however, in each case there has not been an actual detailed solution tabled, only alternative workarounds.

I am wanting to send a WOL packet via my Android smartphone to my home PC.  I have the latest Astaro v8 free running on a dedicated machine.  I can do this successfully for ~60 seconds after the machine is put to sleep but this then fails to work due to the ARP cache entry expiring.  Astaro is setup with a DNAT forwarding port 9 to my PC as it seems that it will not transmit a broadcast via NAT.

There are a number of potential solutions to this problem:
1) Setup a static ARP entry
2) Setup bridging

I am not sure if #1 is possible with Astaro, does anyone know this?

#2 was suggested in a couple of the previous WOL discussions, however I am unsure of the theory of how this would work in conjunction with the existing NAT setup or the repercussions of doing so (in particular with respect to security).  Is anyone able to enlighten me on the details of this particular setup?

Any info would be greatly appreciated.

Cheers,

Sam.


This thread was automatically locked due to age.
  • OK. 
    Check your DNAT for that service, and if it looks OK, you could run 
    tcpdump dst port 5555 
    (as root) and see if you can see both the incoming packet from the internet, and the packet being forwarded to your PC.

    However, I notice that your log shows UDP port 5555 but the discussion above mentions UDP port 9; I'm not sure which is correct.

    Barry
  • Ok, here's the log from the capture:

    14:50:26.871399 IP .dyn.cust.vf.net.nz.60717 > PhatWall.rplay: UDP, length 102


    As for the port, I believe that the port used is moot, the PC NIC will listen for the WOL packet on any port.  Port 5555 has worked fine over the Internet in the past and it's working fine over the LAN at the moment.

    Edit:  Ha!  On a hunch I disabled and re-enabled the WOL DNAT rule and now everything is working perfectly!!  The only other thing I did was disable the initial packet logging setting, but I doubt that did anything.  The fix stuck after a reboot as well!  Weird!
  • Note that this configuration is a bit of a nasty hack and opens the entire LAN subnet to incoming port 9 UDP traffic, but at the moment, it's the only config which enables you to have a one click WOL over Internet solution.


    Hi,

    1. you can use the machine's actual MAC address instead of the broadcast MAC.
    (I've found that my Intel/Dell NICs require the actual MAC anyways when sent in a UDP WOL magic packet)

    That would limit the packets to a single target (also meaning you can't wake up more than one target, but you could put one DNAT on port 7 and one one port 9)

    2. some NICs allow a WOL password to be set for added security, but if your NIC already requires the MAC to be sent, I don't see why you'd need another password.

    Barry
  • All of this is working for me on Astaro 9.005, except the S99wol script (from https://community.sophos.com/products/unified-threat-management/astaroorg/f/55/t/44967) doesn't seem to be getting run at boot time (according to ip -d neigh, there is no static/permanent arp entry).

    If I run the script manually, it works.

    The script is in /etc/rc.d/rc3.d/S99wol, and permissions are 755.

    Any ideas?

    Thanks,
    Barry
  • Any possibility of integrating WOL into the Sophos UTM UI like they've done with pfsense?  I forgot how nice and easy this feature was in pfsense.  Thanks! [:D]
  • Has anyone come up with a solution to this in UTM 9.x?

  • Well, just for the hell of it I tried the old method and amazingly it worked (ie; was executed correctly at boot time)!

    I'm not sure what the difference is between what I did and what BarryG did, but perhaps it was a one-off failure for Barry (or a one-off success for me!).

    I didn't do anything out of the ordinary, although I use a different port to the standard port 9, but that shouldn't make any difference.

    Go figure!?