 DrTCPYours trulyPremium,ExMod 1999-04 join:1999-11-09 Round Rock, TX 2 edits | reply to DrTCP
ARP command works! said by DrTCP:If the manual is showing that ARP command is available and it is not working, open a defect ticket with ZyXEL. It might be addressed in a future firmware update. Actually, I found that the command is working with my USG 300. ZyWALL needs to be in configure mode however.
Log-in to console (web console, ssh or serial).
enable configure terminal arp ip_address mac_address show arp-table write
show running-configuration or write terminal to display config file
Note: IP address is in the form a.b.c.d (eg. 192.168.1.2), MAC-Address is in the form aa:bb:cc:dd:ee:ff
Note2: I was able to add broadcast IP address with broadcast MAC address to the table as well. If your subnet is 192.168.1.0/24 the broadcast address would be 192.168.1.255 and the broadcast MAC address is ff:ff:ff:ff:ff:ff. I am not sure if this would make WoL packet forwarded from WAN to LAN broadcast address to wake multiple hosts (or work at all) Virtual Server address using LAN subnet broadcast address does not work. You need to setup only one host to receive magic packet. But you can assign different port numbers for each of your LAN host and wake them up one by one. |
|
|
|
 BranoI hate VogonsPremium,MVM join:2002-06-25 Burlington, ON kudos:3 Reviews:
·Bell Fibe
3 edits | It's interesting that WoL works over IPSec (don't have to tinker with arp cache at all). I'm normally waking my PCs on the other side of the tunnel. My concrete example, sending magic packet from 192.168.10.3 on USG side of IPSec tunnel to 192.168.9.255:9 on Prestige2602 side.
This is using subnet broadcast address, I've not tried limited broadcast address 255.255.255.255 (which should not be routed as already mentioned). |
|
 GorkOu812ic join:2001-10-06 Bountiful, UT | reply to DrTCP You know, I don't think I ever tried the ARP command after using the ENABLE command. (And didn't even think about then using the CONFIGURE TERMINAL command.) I read the CLI guide and the ARP command wasn't listed in the table as one of the commands available after using ENABLE. So I think I just moved on and didn't bother trying.
I did try creating a MAC/IP Binding rule with 00:00:00:00:00:00 and 192.168.1.255 (192.168.1.0/24) just to see what would happen, but that didn't work. I learned since then that the MAC/IP Bindings don't stay active in the ARP table when the computer is turned off - not static.
So two questions DrTCP , if you don't mind. First, is ff:ff:ff:ff:ff:ff a known "broadcast MAC address" or is it just something you put in as a filler to create a "multicast" broadcast to *.255? And also, were you by chance able to determine if using the ARP command creates a static entry?
I see I'm going to have to get the 20W back out of the box to play around with it some more. I was out of ideas, but now have a possible direction to check again. If I were able to get this working it'd give me the umph I need to work on getting the VPN tunnel through (not to) the router working as well. (I think I mentioned previously it works fine through the 2WG but the same settings don't work on the 20W. There are more details but that's for another thread.)
In looking back at the CLI reference document, the arp command is listed under the following sentence: "Here are maintenance tool commands that you can use in configure mode." Probably part of what made me brush over the "configure mode" part though is the command SHOW ARP-TABLE is also listed in the same table, but you don't have to be in configure mode to use that one.
@Brano I've read posts (possibly yours?) that people have gotten WoL to work with a USG when using VPN through a tunnel. But i assume you are using VPN to connect to a computer through the router, correct? A computer which always has to be on?
Thanks |
|
 DrTCPYours trulyPremium,ExMod 1999-04 join:1999-11-09 Round Rock, TX | reply to Brano said by Brano:It's interesting that WoL works over IPSec (don't have to tinker with arp cache at all). I'm normally waking my PCs on the other side of the tunnel. My concrete example, sending magic packet from 192.168.10.3 on USG side of IPSec tunnel to 192.168.9.255:9 on Prestige2602 side.
This is using subnet broadcast address, I've not tried limited broadcast address 255.255.255.255 (which should not be routed as already mentioned). Well that is a good idea as well. Since this scheme does not use NAT/Virtual Server mechanism, subnet broadcasts probably goes through. |
|
 DrTCPYours trulyPremium,ExMod 1999-04 join:1999-11-09 Round Rock, TX | reply to Gork said by Gork:You know, I don't think I ever tried the ARP command after using the ENABLE command. (And didn't even think about then using the CONFIGURE TERMINAL command.) It says in the USG 3000 manual that ARP command needs configuration mode.
ZLD command line is loosely designed to look similar to Cisco routers. So, you have enable to switch to privileged mode and configure terminal for configuration mode and write to save changes. Unfortunately, unlike Cisco, ZLD CLI does not auto-complete when you tab or interpret command when you shorten keywords such as "config t"
I learned since then that the MAC/IP Bindings don't stay active in the ARP table when the computer is turned off - not static. MAC/IP bindings are not used for ARP. The bindings are used for static DHCP and possibly to optionally block hosts that does not have a binding.
So two questions DrTCP , if you don't mind. First, is ff:ff:ff:ff:ff:ff a known "broadcast MAC address" or is it just something you put in as a filler to create a "multicast" broadcast to *.255? ff:ff:ff:ff:ff:ff is a special mac address used to broadcast on the LAN segment. Any broadcast IP packet (local or subnet llimited) must use this mac address. Multicast IP packets use a MAC address in the range 01:00:5e:00:00:00~01:00:5e:7f:ff:ff. These latter group also has the broadcast bit set in the MAC address (least significant bit of first octet of MAC address)
And also, were you by chance able to determine if using the ARP command creates a static entry? Appears to be static.
Anyway, forget about what I said about adding ARP for broadcast address. It did not work. However, with static ARP entry in place for the host I am trying to wake, I was able to wake up my LAN desktop computer from Internet using this service here.
»www.depicus.com/wake-on-lan/woli.aspx
This service (or their free utility tools) allows arbitrary port numbers. Thus, as an alternative to broadcast, you should create a different virtual servers using different port numbers to map to different internal hosts you would like to wake up. Make sure you add WAN-LAN firewall allow rules as well. For each hosts that you would like to wake up, you will also have to add a static ARP entry. |
|
 GorkOu812ic join:2001-10-06 Bountiful, UT | said by DrTCP: MAC/IP bindings are not used for ARP. The bindings are used for static DHCP and possibly to optionally block hosts that does not have a binding.
I guess what confuses me about this is that there is an ARP entry (using the SHOW ARP-TABLE command) for every MAC/IP binding I entered into the web interface of the router.
That said, I manually entered an ARP entry via the ARP command after entering configure mode and it took the command. (After I finally figured out you must use lower case letters only in the MAC address, that is.) I've have the same results you described - seems to be static, the command is entered into the config file and appears to be permanent.
Though it's not exactly what I'd prefer, as long as I can use WoL to boot up one computer on my network from the WAN (Internet in my case) side I can get any other computer up and running without too big a hassle. In my case there's just one computer I really need to be able to boot in most cases. Pretty much the only time I'll need to boot other computers is when I have a power loss and the UPS devices don't work "properly." (Power goes down, computer turns off, power comes back on before the UPS shuts down -- in this case the UPS doesn't shut down so there's nothing to trigger the computer to boot back up when the power comes back.) It doesn't happen often, but when it does and I'm not near the network it's definitely a problem.
Too bad what you said about adding the ARP for a broadcast address doesn't work after all - you definitely got my hopes up! You probably ran into the same wall I did - the broadcast address is accepted but the result doesn't actually work.
I think all the posts in this thread answer the OP's question - we pretty much covered all the angles I think. Thanks to all for the help, and an extra big gold star goes to DrTCP .
I guess I can start trying to figure out what I need to do to get OpenVPN working properly through the router. Chances are you'll hear from me again, in a brand new shiny thread. And I may need a few days off work to nail that issue down - who knows when that'll happen. |
|
 jdmtPremium join:2002-05-06 Seattle, WA | reply to DrTCP Hi DrTCP,
Quick question...will the broadcast MAC entry work for DMZ to LAN traffic, or should I just put static entries in for each client I want to wake up? Any major security concerns you can think of with all of this?
I am using the Depicus DOS client to generate the packet, so I am specifying IP, Port and MAC, so always assumed I was avoiding the broadcast mechanism, but I guess that wasn't correct... |
|
 DrTCPYours trulyPremium,ExMod 1999-04 join:1999-11-09 Round Rock, TX | said by jdmt:Hi DrTCP,
Quick question...will the broadcast MAC entry work for DMZ to LAN traffic, or should I just put static entries in for each client I want to wake up? Any major security concerns you can think of with all of this?
I am using the Depicus DOS client to generate the packet, so I am specifying IP, Port and MAC, so always assumed I was avoiding the broadcast mechanism, but I guess that wasn't correct... I did not try DMZ to LAN. I think the problem lies with Virtual Server/NAT mechanism. Since DMZ -> LAN is not NAT'ed, just firewalled and routed, it has a chance. If it does, the odds are you will not need a static ARP for broadcast address.
Regarding security concerns (for WAN to LAN), remember that the pin-hole will remain when the host is up. Any vulnerable service there will be reachable but you can reduce the attack vector.
1) The default in Depiscus tool is UDP port 7 (echo) but you can change the port and port is actually irrelevant for WoL (the NIC detects the payload of the packet).
2) If you already have a UDP service exposed to the internet on the internal server, you can use that port instead of opening another one.
3) If you have to open a port, you might want to open one that no service is actually running on the internal host and if you even want better have software firewall block that port so host would not send ICMP port unreachable back.
4) You can even restrict the source IP of the internet hosts able to reach this port via your Firewall rule. For example, you can only let packets from Depiscus and a couple of alternate sites (your work) and drop other packets. However, if the IP addresses change you will need to update the Firewall rule. |
|
 2 edits | reply to jdmt
Re: Routing Broadcast Packets between Subnets - USG100 Missed the solution above so removed my comments. |
|