Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 37 replies
  • Subscribers 3 subscribers
  • Views 196837 views
  • Users 0 members are here
Options
Suggested
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

Sambo
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.
  • 0
    No, thats why they're called "static". They stick until reboot ;-)
  • 0 in reply to trollvottel
    Right, figured, but your previous comment confused my poor little brain [[:)]]  I apologize for my ignorance, but I'm a novice when it comes to *nix [[:)]]

    So if I create a file called 's99wol' in '/etc/init.d/rc3.d/' with the following contents: 


    #!/bin/bash

    

    # At the ASG, create a DNAT for UDP Traffic Port 9 to $DNATDST

    

    # Configuration

    NIC=eth0

    DNATDST=10.12.28.2  #Fake IP on my subnet

    

    # Map Traffic going Fake-IP being flooded broadcasted

    ip neigh change $DNATDST lladdr ff:ff:ff:ff:ff:ff nud permanent dev $NIC > /dev/null 2>&1

    ip neigh add    $DNATDST lladdr ff:ff:ff:ff:ff:ff nud permanent dev $NIC > /dev/null 2>&1


    ..and then make it executable with: 
    chmod u+x s99wol


    It should execute that script on boot automatically and do what I'm wanting it to do?
  • 0 in reply to Sambo
    Yes, exactly. But I'd call the script 'S99wol' (uppercase 'S') because that's how all other init scripts are linked like and it may not work otherwise. You also still need to create the mentioned DNAT rule: SRC any, DST WAN (Addr), SERVICE: UDP DST Port 9, translated to DST 'Fake IP' (Addr).

    To wakeup the PC, send the WOL packet containing the MAC address of the PC that should be waken up from any internet host to the WAN IP of the ASG (use dyndns?).
  • 0
    Great!  Thanks Mario, I really appreciate your assistance with this!  I'll give it a try and let you know how I go.
  • 0 in reply to trollvottel
    Ok, I've set that script up and it executes correctly; an 'ip -d neigh' results in:

    [LAN].30 dev eth1 lladdr 00:0c:29:a8:50:58 DELAY
    [LAN].10 dev eth1 lladdr 00:1b:21:1b:20:73 STALE
    [LAN].33 dev eth1 lladdr 00:1b:21:28:81:e4 REACHABLE
    [WAN].254 dev eth0 lladdr 00:90[:D]0:74:e1:ea REACHABLE
    [LAN].20 dev eth1 lladdr 00:0c:29:3c:2e[:D]0 REACHABLE
    [LAN].32 dev eth1 lladdr ff:ff:ff:ff:ff:ff PERMANENT
    [LAN].202 dev eth1 lladdr 00:21:6b:29:33:52 REACHABLE
    [LAN].100 dev eth1 lladdr 00:1c:10:c3:6b:88 STALE


    The only change I made to the script in my previous post was to change the NIC to eth1 as this is my LAN NIC which I'm assuming is what was intended (I tried with eth0 (WAN) as well but no change.

    I have setup the DNAT rule and it works fine if I direct it to my PC's real IP address, but not if I direct it to the 'fake' IP.  I'm using a WOL packet monitor to test.

    I turned on logging on the DNAT rule but got only the following:

    2011:09:12-17:19:14 PhatWall ulogd[5170]: id="2000" severity="info" sys="SecureNet" sub="packetfilter" name="Packet logged" action="log" fwrule="60021" initf="eth0" srcmac="[Source]:ea" dstmac="[Dest]:57" srcip="[Source].50" dstip="[WAN].1" proto="17" length="130" tos="0x00" prec="0x00" ttl="57" srcport="56781" dstport="9"


    The live firewall log shows the following entry:

    18:28:42 Connection using NAT UDP [Source].229:55988 → [WAN].1:9 len=130 ttl=61 tos=0x00 srcmac=[Source]:ea dstmac=[WAN]:57


    Anyone have any ideas what the problem might be here?
  • 0 in reply to Sambo
    Hm. Normally it should work that way - will try today on my Home-ASG.

    The logged packet you posted is only informational, it wasn't dropped. The 'log' checkbox only means 'log initially matching packets', so every initial packet of a connection through the DNAT rule will be logged.
  • 0 in reply to trollvottel
    I just tried it and for me it works how I described it. Did you forget to tick the 'automatic firewall rule' for the DNAT?

    I used that page to remotely wake my Home PC: http://wakeonlan.me/
  • 0
    Hmm, added the packet filter rule & checked that 'automatic firewall rule' was enabled (it was).  Used the website you suggested, but no go.

    Which logs should I be looking at to see what's going on here?

    I'll double check everything is correctly setup as well...
  • 0
    You can remove that packet filter rule again, as I updated my post because it's not necessary and false anyway, sorry.

    For debugging this, please do some tcpdump captures at your ASG (I assume eth0 is your WAN interface?):

    For incoming WOL packets: 'tcpdump -i eth0 -n udp dst port 9'
    For outgoing broadcasts: 'tcpdump -i eth1 -e -n udp dst port 9'

    while sending the packet.

    You should see the incoming packet to the WAN IP, then an outgoing packet as broadcast. The site sends multiple WOL packets (I counted 20!), so don't get confused.

    Also please check that the ASG packetfilter.log does not contain dropped WOL packets: Best would be to open several SSH shells at the same time, two for the tcpdumps and one for 'tail -f /var/log/packetfilter.log | grep "dstport=\"9\""'.

    This is how it looks like for me when it works:

    asg120:/root # tcpdump -i eth1 -n udp dst port 9
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
    09:40:08.104322 IP 208.77.98.204.41308 > A.W.A.N.9: UDP, length 102
    [19x...]


    asg120:/root # tcpdump -i eth0 -n -e udp dst port 9
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
    09:36:36.346745 00:90:fb:33:22:e7 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 144: 208.77.98.204.40967 > F.A.K.E.9: UDP, length 102
    [19x...]


    My Internal is eth0 and WAN is eth1, though.
  • 0
    Ok, tcpdump shows the following sequence:


    IP 208.77.98.204.41458 > 192.168.1.1.9: UDP, length 102
    IP 208.77.98.204.41458 > 10.10.10.32.9: UDP, length 102
    which looks about right.  The packetfilter.log looks to be indicating that the website is sending the WOL packet to port 7? (despite that the site says it's using port 9).


    2011:09:12-19:48:58 PhatWall ulogd[5170]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="0:90[:D]0:74:e1:ea" dstmac="[WAN]:57" srcip="208.77.98.204" dstip="[WAN].1" proto="17" length="130" tos="0x00" prec="0x20" ttl="45" srcport="41934" dstport="7"


    Changing the WOL port to 7 on the ASG results in dropped packets to port 9, so it must be sending on both 7 & 9.

    Whatever port I have open is not dropped in any case.

    One thing which may have a bearing on this issue is the fact that I have my ADSL router configured to use NAT (long story).  But we're getting the WOL packets so I guess it shouldn't really be an issue.

    Also, just to confirm, I should definitely be using my LAN NIC in the static ARP entry right (which is eth1 in my case)?
Unfiltered HTML