RV042 - wake on LAN magic packet from a PPTP connected remote client

[stevemowbray]

Hi

Is it possible to get WOL magic packets into a small LAN behind an RV042 router from a PPTP connected remote client - seems like the trick will be to get the client WOL sender application to use the IP network broadcast address associated with the PPTP connection but I have not seen any clear guidance on the net for this or come close to it working.

Thanks

Steve

[mpyhala]

Robert,

Please see the following thread:

https://supportforums.cisco.com/message/3810965#3810965

- Marty

[stevemowbray]

Aye read that thread before posting but not sure if it applies since it does not mention VPN connection specifics and besides in my application there are multiple PC's to WOL behind the router so the router port mappings would not be flexible enough I dont reckon.

My confusion is this - when the remote client is VPN connected to the work network the host exists on a virtual LAN segment connected through the PPTP tunnel - my understanding is any traffic to/from the remote client is in effect as if the PC was locally connected - for instance you can ping workplace hosts etc.

Any further guidance would be great

Regards

Steve

[mpyhala]

Steve,

You are correct, you can access devices as if you are in the same LAN. The problem is that you are actually in a different broadcast domain separated by the router. WOL uses a broadcast packet to reach the device that you are trying to wake so the router just drops it. It would be the same if you tried to wake a machine from one VLAN to another. I wonder if you can send a magic packet directly to the LAN IP of the machine that you want to wake instead of a broadcast? It has been more than 10 years since I played with WOL so I need to refresh my knowledge.

- Marty

[stevemowbray]

Ok here is where I show my networking ignorance - I had imagined that the VPN tunnel was also a broadcast domain with broadcast packets being encapsulated and transmitted through the PPTP tunnel as if the VPN client host was physically connected - for instance ARP requests on the VPN virtual LAN from the client somehow get through. So to my inexperienced understanding all traffic including broacast/multicast through the PPTP link should just appear on the other side of the PPTP server and not be just dropped otherwise is not a true virtual LAN. The question is how to formulate the packet at the client end I guess.

Apologies for my networking ignorance

Steve

[SamirD]

One way around this would be to use the pptp connection to remote desktop or vnc into another system on the lan that IS in the broadcast domain and then just send the magic packet from that system.  Of course, if nothing is awake in the lan, this won't work because you have to wake it first.

Huntsville's Premiere Car and Bike e-magazine: www.huntsvillecarscene.com

[stevemowbray]

bingo - no actual PC's always on but there is a NAS server which being QNAP type Linux based has open source installable packages one of which being the Optware package which has - low and behold - wakelan:

http://forum.qnap.com/viewtopic.php?t=13927

would have been nice if the RV042 had a built in WOL source

[stevemowbray]

still really keen to understand why cant wake on lan over PPTP even though got a workable solution for now - my basic understanding is the VPN client is on the LAN albeit virtually. This from wikipedia:

"If the magic packet can be made to reach a computer, it can originate anywhere (e.g., from the Internet). This can be achieved by a virtual private network (VPN), which makes the remote computer appear to be a member of the local area network (LAN). In the absence of a VPN, a computer connected to a router can be woken if a magic packet sent over the Internet is routed to it. This requires any firewall to be set up to allow entry of the Wake-on-LAN signal to a specified port."

(http://en.wikipedia.org/wiki/Wake-on-LAN#Wake_on_Internet)

I have the nagging feeling that this could be down to the classic multi-homed windows host network programming glitch where simplistic network apps struggle to choose the appropriate connection if it is not the primary NIC/WiFi connection which is the case with PPTP client connections