WOL/LAN/VPN/Router - Issues

spydeyrch

Junior Member
Dec 3, 2014
8
0
0
Hey there y'all!

*** I don't know if this should go under router, VPN, LAN/Wireless, or some other sub-forum. Admins, please feel free to move as is needed. Thank you! ***

I am new here and hope to get some assistance with something. I have been racking my brain on this issue I am having. I have scoured the internet, forums, books, library, etc., for months now and can't seem to figure this out. By all accounts, it should be working but I can't seem to figure out why it isn't.

I have my machine, which is wired directly to the router, an Asus RT-AC68P. The machine is setup via the BIOS (UEFI) and the NIC settings in Widnows to wake (WOL) from both sleep and shutdown. It works fine internally. (Externally is another issue but to tackle at a different time, unless it has to do with my current issue.) I have tested it from other machines on the same internal network: tablets, phones, wired devices, wireless devices, etc. Wakes from both sleep and shutdown every time when the packet is sent from within my LAN (home network).

I have the router's built-in VPN server setup to use the same subnet range as my router uses for my home network IP address range. The router uses the lower end of the subnet and the VPN uses a different section.

For example, the router would use for any connected devices the following IP address range:

xxx.xxx.5.2 through xxx.xxx.5.11

with a subnet mask of 255.255.255.0

The VPN server is setup (I had to manually change it) to use the following range for any devices connected to it:

xxx.xxx.5.15 through xxx.xxx.5.19

with a subnet mask of 255.255.255.0

If I didn't change the VPN DHCP settings, then although the external device was connected to the VPN, niether it nor my internal devices could connect to each other. By doing the above, I am able to ping all devices from external to internal and vice versa.

If an external device, say in a different city, is connected to my VPN server with the above settings in place, the external device, assuming it is the only device currently connected, is assigned from the VPN server the IP address of xxx.xxx.5.15. From within my LAN (home network), I can ping xxx.xxx.5.15 and get a response and xxx.xxx.5.15 can ping my personal machine, which is on my internal network, and get a response. I can remote into the external machine and the external machine can remote into an internal machine, let it be via RDP, VNC, etc. It works just fine. No issues.

The issue I am having, which I hope has a simple fix, is: Once I have logged in to the VPN from an external device and the external device is assigned an IP address on the same subnet as my internal machines via the VPN server, I can't seem to wake my internal machine (which would normally wake from an internally sent request). Nothing happens. I send the "magic packet" as I normally would but nothing happens.

Technically, because I am logged into the VPN, the external machine should be "seen" by the VPN and router as a machine located on the internal side of things. So just as when I am at home and can wake my machine from the internal side of things, when I am logged into the VPN, and the external device has been assigned an internal IP address, it too should wake the machine I am targeting. But nothing happens.

I can't figure out why. I have checked, double checked, and triple checked the settings, etc. Tried each little thing, one by one, and can't seem to get it to work for what ever the reason.

Any ideas? Suggestions? Thoughts? Or am I completely stuck.

Thanks for your help guys and have a great holiday season!!

-Spydey
 

John Connor

Lifer
Nov 30, 2012
22,757
619
121
Wow! I don't have much of a clue. I have a built in SSH server in my router flashed with a third party firmware called DD-WRT. Well when I first entered my settings in the router for my SSH server I was able to log in from my home computers, but if I wanted to log in externally, say a hot spot I couldn't. Come to find out that I had to enable remote management in the router for external devices to gain access to the router's SSH server.

So I'm wondering if you have to enable a simple setting that you would not have otherwise thought of to WOL the computer via a VPN.

It's like the packet isn't making it through to wake the computer. TTL? I have not the fogyist.
 

John Connor

Lifer
Nov 30, 2012
22,757
619
121
This may not apply to you, but it may hold key info. on why WOL and the magic packet isn't working specificly about the MAC address. http://kb.fortinet.com/kb/documentLink.do?externalID=FD30104

For reference I Googled, "magic frame missing in vpn."

Here's another search term, "send magic packet through vpn"

Interesting information. http://serverfault.com/questions/285359/can-wake-on-lan-work-on-vpn-connection

I'm betting you read all this before.

Are you sending magic packets via VNC? I used UltraVNC once and I can't remember if it had that option.
 
Last edited:

spydeyrch

Junior Member
Dec 3, 2014
8
0
0
John,

Thanks for the reply. It was very fast!

I think that the issue is that the directed broadcast isn't being sent from the VPN to the local LAN. Why, I don't know. I think that it is the same issue that I have with using WOL from the WAN side of things. I can't get it to work. My network sniffer catches the WOL packet from the WAN side of things, so I know it is getting through, but it doesn't activate the computer like it should.

I just have to figure it out someway or another.

Also, I am sending the WOL packet via an android app and/or also from a windows stand-alone app. They both work internally and can be setup to work externally.

Also, depicus.com has a web based utility that you can use to send WOL from the WAN side of things.

I will keep looking and try to figure this out.

Thanks again John.

-Spydey
 

serpretetsky

Senior member
Jan 7, 2012
642
26
101
I'm not familiar with WOL or it's settings. So assuming you've exhausted troubleshooting general settings I'd probably recommend installing wireshark on the computer to wake and having it stay on. Send the WOL packet from both internal source and VPN'd source and see if there's any glaringly obvious difference.
 

JackMDS

Elite Member
Super Moderator
Oct 25, 1999
29,563
432
126
Try to flash the firmware in the Router to Tomato and use its internal WOL.


:cool:
 

VirtualLarry

No Lifer
Aug 25, 2001
56,587
10,227
126
Tried setting up a port forward for (UDP?) to 192.168.2.255 (broadcast), and sending the WOL packet that way? I don't know if that would work. WOL is layer2, right? You would want to send a broadcast frame.

Or maybe you need to set up a static ARP for the machine to be woken up too, so that it keeps it's IP even when off, so that you can send a packet to it's MAC to wake it up?
 

Genx87

Lifer
Apr 8, 2002
41,091
513
126
I'd assume this wakeup packet is a broadcast? The VPN may not allow a broadcast to the other side. I am surprised you are even able to ping either side of the VPN since both sides are on the same subnet.
 

Bird222

Diamond Member
Jun 7, 2004
3,641
132
106
I'd assume this wakeup packet is a broadcast? The VPN may not allow a broadcast to the other side. I am surprised you are even able to ping either side of the VPN since both sides are on the same subnet.

I'm suspecting something like this. What vpn server are you running? Is it openvpn?
 

spydeyrch

Junior Member
Dec 3, 2014
8
0
0
Try to flash the firmware in the Router to Tomato and use its internal WOL.


:cool:

I could do that, but the Asus RT-AC68P already has a built in WOL. I can access it via the public IP (secure remote admin session), using my Dynamic DNS via asuscomm.com (feature of the router), or via the mobile AiCloud app. The only thing is that all of these are cumbersome compared to a simple: VPN login & send magic packet. I have timed the the options with the machine in sleep (S3). So I have to wake it and remote into the desktop, all from a remote location.

Methods & Approx Amt of Time:

Via Public IP (secure remote admin session) --> Use WOL function --> connect VPN --> Remote In = 5 - 7 minutes (depending on internet connection)

Via asuscomm.com (basically it is a web version of the mobile app) --> WOL function --> Connect VPN --> Remote In = 5 - 7 minutes (depending on internet connection)

Via Mobile App --> WOL function --> Connect VPN --> Remote In = 5 = 7 minutes (depending on internet connection)

Desired method: Connect VPN --> WOL via mobile app (different than Aicloud app) or Windows app --> Remote In = 1 -2 minutes

So with my desired method, I don't have to go through so many steps. It is basically keeping it simple and efficient. The other options are cumbersome because I have to do too many steps to achieve the same thing. More to do but nothing more gained.
 

spydeyrch

Junior Member
Dec 3, 2014
8
0
0
Tried setting up a port forward for (UDP?) to 192.168.2.255 (broadcast), and sending the WOL packet that way? I don't know if that would work. WOL is layer2, right? You would want to send a broadcast frame.

So interesting question ..... This whole started because I was trying to do this differently before, like months ago. Back then I had a different router, ISP supplied. It coudl do VPN Passthrough but didn't have its own VPN server, like my new router does.

So, I setup my machine to accept incoming connections, assigned an account specifically for just VPN connections. I setup the router (ISP provided) to port forward any incoming VPN requests from a non-standard port to the correct standard port to the assigned machine. The machine had a static IP assigned from the router, I also had to set it up in the NIC settings to match and also assign the subnet mask, if I didn't, things didn't work correctly. The VPN server on the machine was manually set to use a different range of IP addresses in the same subnet as the router was set to use, so they were on the same subnet but didn't assign conflicting IP addresses.

I could connect to the VPN server from an external device, ping back and forth, just like I can now, and everything was awesome. The only issue back then was that, if the machine with the VPN server was asleep, I would have to wake it from an external source, and my ISP router didn't allow broadcast frames to pass through ... at least as far as I could tell. So my whole setup was null if the machine was shutdown or asleep. And leaving it on 24/7 was not something I wanted to do.

So I decided to invest in a router that has a VPN server built in. I thought that I could log into the VPN and WOL the machine(s) I needed. Sound in idea, just not playing out as I had hoped.

Or maybe you need to set up a static ARP for the machine to be woken up too, so that it keeps it's IP even when off, so that you can send a packet to it's MAC to wake it up?

The more I read and research things, the more I think that this is the route I may need to go. But I haven't ever dealt with ARP ... yet. So I don't even know where to begin!!!

So, the Magic Packet that is used in WOL uses the MAC address to wake it. The IP really isn't used. But I don't know if that matters when using ARP or not.

Dr. Wiki says:

Principle of operation

Ethernet connections, including home and work networks, wireless data networks and the Internet itself, are based on packets of data sent between computers. Wake-on-LAN ("WOL") is implemented using a specially designed packet called a magic packet, which is sent to all computers in a network, among them the computer to be woken up. The magic packet contains the MAC address of the destination computer, an identifying number built into each network interface card ("NIC") or other ethernet device in a computer, that enables it to be uniquely recognized and addressed on a network. Powered-down or turned off computers capable of Wake-on-LAN will contain network devices able to "listen" to incoming packets in low-power mode while the system is powered down. If a magic packet is received that is directed to the device's MAC address, the NIC signals the computer's power supply or motherboard to initiate system wake-up, much in the same way as pressing the power button would do.

The magic packet is sent on the data link layer (layer 2 in the OSI model) and when sent, is broadcast to all attached devices on a given network, using the network broadcast address; the IP-address (layer 3 in the OSI model) is not used.


It is a common misconception that because Wake-on-LAN is built upon broadcast technology it can only be used within the current network subnet. While this is generally the case, there are some exceptions, and Wake-on-LAN can operate across any network in practice, given appropriate configuration and hardware, including remote wake-up across the Internet.

In order for Wake-on-LAN to work, parts of the network interface need to stay on. This consumes a small amount of standby power, much less than normal operating power. Disabling wake-on-LAN when not needed, can therefore very slightly reduce power consumption on computers that are switched off but still plugged into a power socket.[5]
Thanks for your input, keep it coming!! I hope to get this figured out. It would be awesome!!

-Spydey
 

spydeyrch

Junior Member
Dec 3, 2014
8
0
0
I'd assume this wakeup packet is a broadcast? The VPN may not allow a broadcast to the other side. I am surprised you are even able to ping either side of the VPN since both sides are on the same subnet.

Yes, the WOL packet, aka magic packet, works on level 2 and is a broadcast. That is my thought, that the VPN isn't allowing the broadcast to get through in it's entirety. Part of it shows up sometimes. The packet sniffer I am using catches that the packet got through ... sometimes, yet the machine it is targeting doesn't respond. So that leaves me to believe that part of the packet is missing ... which happens.

As far as the ping goes, it didn't used to work ... back when I was doing this on the VPN I setup in windows on my machine. But then I realized that the windows VPN was assigning random IP addresses and was using a different subnet mask then the router. Also, for the Widnows VPN, I had to set the gateway setting in the VPN as the router's IP: ex. 192.168.1.1 So by changing not only the VPN gateway, the subnet mask, and the IP range of the VPN server, I was able to get all machines on my local network and external devices (logged into the VPN) to communicate (ping) with no issues. Cool thing is I can have multiple devices signed into the VPN and they can communicate too!! So I could have my mom up north and my dad down south log into my VPN and he can help her with her machine ... just an example.

The benefit by doing it now with the router's VPN server is that I don't have to open any ports or anything for the VPN to work.

Here is a blurb from depicus.com regarding WOL:

What is Wake On Lan ?

Introduction
It's all about money or maybe just to make life easier but either way Wake on Lan has something to offer you.

What is Wake-on-Lan
It depends on who you are, there are two companies who are claim credit, and maybe Al Gore and Microsoft will claim credit soon, for the technology behind Wake on Lan (WoL). Both AMD and IBM claim on their web site that WoL was their idea but thankfully we all benefit from the idea. WoL is both a hardware and software solution to allow a computer to be woken up remotely. Much like a modern television set, a computer that is Advanced Configuration Power Interface (ACPI) compliant can be turned on remotely, note that while you can currently only turn your television set on from within a certain distance WoL (and our WoL for ASP) allows you to remotely start a computer from anywhere in the world, that is as long as it has an internet connection.

Unlike Wake on Modem, which doesn't require any special software, WoL requires a special software program to send a signal to the network card to make it work.

About Magic Packet
The Magic Packet is at the heart of Wake on Lan although it is not as magic as would first appear. The basic premise is that a specifically formatted packet send over a network is send to every network card and identifying features in this packet allow the network card to identify that the magic packet is intended for it. All the other cards therefore reject or rather dispose of the packet. It is analogous to standing in a crowded room of people and shouting out somebody's name, where nobody in the room has the same name, although everybody would hear you hopefully the only person to answer would be the person who's name you have just called out.

Wake-on-Lan Hardware
To use Wake on Lan you will need at minimum a motherboard and a network card that support Wake on Lan.

Network Cards
We currently use the Intel P100+ and 3Com cards although this is by no means a recommendation.

Motherboards
There are two types of motherboard that support Wake on Lan

Cabling
The two main things to remember about cabling are:

1. The majority of WoL cards require a cable connection between the motherboard and the network card. This is a three pin connection although some older cards and motherboards have two pin connections. To send the signal from the network card to the motherboard this cable has to be connected. There is a specification that would allow the card itself to pass the signal through the PCI bus but we have yet to see or test these cards or motherboards.

2. Your network card must be cabled into some form of network. This can be BNC, RJ45 or even Fibre, indeed the WoL protocol is topology and transport protocol independent so TCP/IP or IPX/SPX could be used to send the magic packet.

Technical Issues aka Problems with Wake on Lan
The Key Stages of Wake on Lan and the Magic Packet

Wake on Lan (WoL) relies on a WoL enabled network card, we currently use Intel Pro 100 cards, and a motherboard with a WoL connector. With these items when you power down your computer a small charge remains on the motherboard, enough to power the network card. Your computer is now ready to be woken up. A "Magic Packet" is sent from our WoL enabled programs, run on another machine or from an internal web server, to the network card which then powers on the computer. Great for starting machines before people get to work...

WoL technology can be very beneficial to your business but please remember that this technology relies on many factors to work properly. Because of this you should be aware of the following points.

Software
Once the machine is on do not turn it off with the power switch. Some cards require a flag to be set which only happens when the operating system is allowed to power down the machine.

Hardware
Always check for the latest Network Card Bios updates - while testing we noticed that both Intel and 3Com cards sometimes needed a flash update for WoL to work.

Make sure you enable the WoL in the motherboard bios and on the Network card. Check your manufacturers web site or manual for further details on how to do this.

Make sure you connect the cable to the board - you would be surprised !
A handy hint is, if the machine is off and the light on your hub is not on then the computer does not have the standby power for the card enabled. Without this the computer cannot receive a WoL command.

Wake on Lan over the Internet (or why is it such a pain in the ****)

"IP directed broadcasts are used in the extremely common and popular "smurf" denial of service attack, and can also be used in related attacks.

An IP directed broadcast is a datagram which is sent to the broadcast address of a subnet to which the sending machine is not directly attached. The directed broadcast is routed through the network as a unicast packet until it arrives at the target subnet, where it is converted into a link-layer broadcast. Because of the nature of the IP addressing architecture, only the last router in the chain, the one that is connected directly to the target subnet, can conclusively identify a directed broadcast. Directed broadcasts are occasionally used for legitimate purposes, but such use is not common outside the financial services industry.

In a "smurf" attack, the attacker sends ICMP echo requests from a falsified source address to a directed broadcast address, causing all the hosts on the target subnet to send replies to the falsified source. By sending a continuous stream of such requests, the attacker can create a much larger stream of replies, which can completely inundate the host whose address is being falsified.

If a Cisco interface is configured with the no ip directed-broadcast command, directed broadcasts that would otherwise be "exploded" into link-layer broadcasts at that interface are dropped instead. Note that this means that no ip directed-broadcast must be configured on every interface of every router that might be connected to a target subnet; it is not sufficient to configure only firewall routers. The no ip directed-broadcast command is the default in Cisco IOS software version 12.0 and later. In earlier versions, the command should be applied to every LAN interface that isn't known to forward legitimate directed broadcasts."

Quoted from Cisco.

Packets and Ports used by Wake On Lan's Magic Packet
Below is a trace of the packet sent using a packet sniffer. Note that we specified port 8900 the source port is 2182 and the destination port is 8900 so if you are using a firewall you would need to open the port you use for UDP traffic.

wake-on-lan-packet-trace.gif


How to calculate the subnet-directed broadcast address

1) Convert machine address to binary e.g. 10.208.20.1 = 00001010.11010000.00010100.00000001

2) Convert the Subnet Mask to Binary e.g. 255.255.240.0 = 11111111.11111111.11110000.00000000

3) Invert the Binary Subnet Mask e.g. 11111111.11111111.11110000.00000000 becomes 00000000.00000000.00001111.11111111

4) Or the machine address and the inverted subnet mask e.g. 00001010.11010000.00010100.00000001 Or 00000000.00000000.00001111.11111111 = 00001010.11010000.00011111.11111111 = 10.208.31.255

Hopefully with all this info and more, plus the mental power of everyone here, we can figure this out.

Also, thanks to everyone so fare. I posted the same exact question in 3 or 4 other forums and haven't gotten a single response yet. So you guys are awesome for responding. Thank you a ton!!

-Spydey
 

spydeyrch

Junior Member
Dec 3, 2014
8
0
0
I'm suspecting something like this. What vpn server are you running? Is it openvpn?

It is the built in VPN server that comes with the Asus RT-AC68P (updated version of AC68U). It is using a PPTP VPN connection. I could go with OpenVPN but the majority of the time, I will be using my tablet to log in to the VPN, and OpenVPN for android only gives you a certain amount of data, like 100MB, (ridiculous!!!!) unless you buy data from them. At least that is what I read when I went to research it.

Any thoughts? would OpenVPN allow me to send the magic packet as a broadcast and not lose anything? Maybe I should at least try it.

-Spydey
 

John Connor

Lifer
Nov 30, 2012
22,757
619
121
Just to let you know PPTP isn't as secure and OpenVPN is slower unless you use UDP. But like you said with your phone or whatever you may have no choice but to use PPTP unless there is an app.
 

spydeyrch

Junior Member
Dec 3, 2014
8
0
0
Just to let you know PPTP isn't as secure and OpenVPN is slower unless you use UDP. But like you said with your phone or whatever you may have no choice but to use PPTP unless there is an app.

Yes, I realize that PPTP is not as secure as the other VPN options. But the router only has options for PPTP or OpenVPN. With OpenVPN, I have to have a certificate and software installed on the machine/device. Which requires that the machine/device be pre-configured. If I am somewhere, a family member's house or friend's house, I am not going to have that machine, their computer, pre-configured with my OpenVPN cert.

But, the majority of devices have PPTP VPN client ability. Although PPTP isn't as secure as IPSec or the other VPN options, it is still more secure than opening a RDP port (port 3389) and forwarding it to the computer. Standard Windows RDP has not security. I don't like VNC that much (too laggy). But adding a PPTP and then RDP works fun .... for now.
 

spydeyrch

Junior Member
Dec 3, 2014
8
0
0
Ok, I think if solved it!!!! I have gone through several different settings and tried different things. I enlisted the help of my father from his location. He was able to log into my router's VPN, no issues. We could PING each other's machines, no issues. Then the moment of trial(s).

I had him send a WOL packet from his location to an active machine, running a packet sniffer. He sent it using a program I am familiar with and know works internally. I got the packet, and it looked to be completely intact!!! I had him change a few things and tried it again, to the already active machine. Still got the packet.

Then I had him change it to my sleeping machine. I had him send it, with my fingers crossed!!!!

So he was remotely logged into my VPN. His remote machine had an IP assigned from my VPN server that was in my LAN's subnet. He used the WOL program I know works internally, but has options to send from internal to internal or external to internal. I had him change the MAC address and IP address to my sleeping machine.

Then I had him send the packet. And on the first try ... my machine sprang to life!!!!!!!!!!

IT WORKED!!!!!!!!

I was so excited.

Now I just have to check, and double check my settings. Try a few different scenarios and then I will post my results!! Hopefully they will help someone in the future who is trying to do the same thing that I am doing.

Here's hoping to getting it working 100%!!!!


-Spydey
 

meat2

Junior Member
Jul 18, 2015
1
0
0
@Spydey - I am facing a nearly identical situation. Any feedback on the final solution?