Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1911
  • Last Modified:

Cisco VPN tunnels and Wake on LAN Magic Packet

We have a project in our company to introduce Wake on LAN to the network. Currently our network design is utilizing LAN-to-LAN tunnels with a Cisco VPN3030 Concentrator at our core and Cisco PIX501/ASA5505 at the remote site. We cannot get the broadcast traffic for the 'Magic Packet' to pass to the remote site, but if I send a WOL packet to a computer where the MAC and IP address are still in the ARP table it works.

Does anyone know how I can allow the Magic Packet to pass through the tunnel? Any help is greatly appreciated.
0
FFNetAdmins
Asked:
FFNetAdmins
1 Solution
 
Nothing_ChangedCommented:
It works when the ARP is still in the table since the concentrator knows where to push the traffic. THe only way I know of to make this work would be to either configure static ARPs (bad idea) or to enable proxy arp on the concentrator (aslo a bad idea but a bit less so). Eitehr way you are likely to have a number of tough to track down intermittent problems.

Depending on your config, you MAY be able to direct your console issuing the WOL packets to send them as a directed broadcast as opposed to a flat out broadcast, and config your network gear to allow directed broadcasts (generally not allowed as a security precaution). Your console sending the packets would need to be able to remember what subnet the target PC is on, and then direct the broadcast appropriately. You really don't want your network gear holding any ARP or bridge table info longer than default, so it's got to be the console app.
0
 
kuohCommented:
Have you considered using a packet relay application on a server or permanently on workstation in the LAN?  You simply configure the relay to redirect all UDP packets of specific ports, typically 0, 7 or 9 for WOL, to the LAN broadcast address, then have the users send the WOL packet to the server.  The application will redirect the packets to the broadcast address and the workstation should wake up regardless of the state of ARP cache.  The only things the users have to know is the server IP and the MAC of their workstation, so the security risk should be minimal.  I've tried it with the application below and it works perfectly.  There's even a "run as service" version to allow full hands off functionality after the initial configuration.

http://www.manualends.com/Download/idxMERLY.html
0
 
FFNetAdminsAuthor Commented:
We are testing this solution in our lab to confirm that it will work for our application.
0

Featured Post

How to Use the Help Bell

Need to boost the visibility of your question for solutions? Use the Experts Exchange Help Bell to confirm priority levels and contact subject-matter experts for question attention.  Check out this how-to article for more information.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now