1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Need advice re "Block WAN Request" setting

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by trwd, Jul 5, 2007.

  1. trwd

    trwd Network Guru Member

    I am trying to get WOL Magic Packets through my RV082 from the Internet.

    Because this router will not allow forwarding to the broadcast address of (“out of range†error), I made an arp entry in the router’s shell and now “arp –vn†displays what I believe are the proper settings: ether FF:FF:FF:FF:FF:FF CM ixp0

    After doing that the magic packet still wouldn't go through the router. I'm using Depicus' WOL Monitor to tell me if the packet is reaching my subnet (in addition to simply seeing if the target PC wakes up).

    In the RV082 I set up forwarding of UDP port 2304 to My router's address is The subnet is

    I created a dyndns.org address, which I've tested and know that I'm able to reach my LAN via that FQDN.

    Then I used the router’s logging function to see if there was any evidence of the packets arriving. There was: it said they were rejected because of some sort of policy setting. That’s when I went into the router’s “Firewall†general settings and disabled “Block WAN Requestâ€. I also created an Access Rule to allow any source to send to through port 2304. These two steps are purely stabs in the dark.

    (Why did I use port 2304? I started using Wireshark to examine network activity when running the various WOL “packet senders†(e.g. Depicus' WOLGUI, WOL.exe from Simply-ware.com, etc.). I noticed that each seems to send to a different port, and not always the 7 or 9 like one might assume. I also found that the aforementioned WOL.exe is able to wake up the target PC whether I gave it the PC’s local IP address or my DynDNS FQDN. So I’m pretty sure Wireshark says WOL.exe is using port 2304.)

    I’d appreciate advice on whether "Block WAN Request" and the access rule addition are appropriate AND do they present any great liability (there’s no point in using them if they have no bearing on letting Magic Packets get through.)

Share This Page