jdmtPremium
join:2002-05-06
Seattle, WA | Routing Broadcast Packets between Subnets - USG100 I'm trying to get Broadcast UDP magic packets for WOL to route across subnets. Worked fine on my zywall 35, not so on the USG100.
Trying to get them to flow between the DMZ and LAN. The logs say that the DMZ->ZyWALL rule was blocking them, so added a rule to accept and all looks good, except they're not showing up at the expected LAN host.
Any ideas? |
|
| Are they allowed by some Zywall to LAN1 rule?
kirby |
|
 DrTCPYours trulyPremium,ExMod 1999-04
join:1999-11-09
Round Rock, TX
1 edit | reply to jdmt
said by jdmt:I'm trying to get Broadcast UDP magic packets for WOL to route across subnets. Worked fine on my zywall 35, not so on the USG100.
Trying to get them to flow between the DMZ and LAN. The logs say that the DMZ->ZyWALL rule was blocking them, so added a rule to accept and all looks good, except they're not showing up at the expected LAN host.
Any ideas?
You are not going to like this but broadcast packets are not supposed to be routed. If they were being routed by ZyNOS based ZyWALLs, it was not really compliant with standards. The Linux OS on USG is more strict. Only bridge devices are supposed to forward broadcasts. For routed segments, they are supposed to stay in their own segment.
However, WoL magic packet does not need to be a broadcast packet. It can be a unicast packet. However, the sleeping device will not respond to ARP so you will have to add a static ARP entry on the interface where the sleeping device is connected.
However, on USG, I can display the ARP table but I don't know how to add static arp entries. Perhaps IP-MAC binding could help but I did not test it. |
|
 GorkOu812ic
join:2001-10-06
Bountiful, UT | My USG 20W has a bridge interface, but I'm not yet smart enough to know if this interface would offer anything to allow this to happen without opening up other security holes.
So, DrTCP  , it sounds like you're saying that being able to use WoL through the Internet to boot up one of any number of computers on a LAN behind a router is not compliant with standards? You have to pick a only a single computer to wake with a magic packet? It seems WoL was designed to be broadcast to an entire subnet so you could easily choose a single computer to start up. I'm assuming your explanation would be that WoL wasn't truly designed to be utilized to start up computers from a different network like from WAN to LAN in the case of a router?
I 'spose there are work-arounds, but certainly nothing as easy. |
|
| reply to jdmt
I always considered that "feature" of ZyNOS to be a bug.... But since people used it for good, who am I to rock the boat 
--
"Perl is executable line noise, Python is executable pseudo-code."
|
|
Reviews:
 ·Fairpoint Commun..
 ·Verizon FiOS
| reply to DrTCP
DrTCP:
In nearly a thousand pages of USG50 manual, the acronym ARP appears once, in a specification table on page 796. Given the phrasing of the MAC table entry below it, I wouldn't be surprised if your speculation is correct -- adding an entry to the IP-MAC table should make the router aware of the association so that it doesn't need to send out an ARP request. It seems to me that one would want this property anyway to minimize effects of potential ARP spoofing.
kirby |
|
GorkOu812ic
join:2001-10-06
Bountiful, UT
3 edits | reply to dslpartner
There are other routers as well which give you the option to turn this ability on or off with options labelled "filter multicast" or similar.
EDIT
said by DrTCP:
Perhaps IP-MAC binding could help but I did not test it.
I've tried this figuring if I can at least get one computer to wake up I wake the others from there. But no go, unless I'm doing something wrong. I even tried disabling the firewall to test. I tried forwarding directly to the IP address of the machine as recorded in my IP/MAC binding, and tried creating an object to address the computer I want to wake up as well. And as far as *.255 goes, the web interface in the USG takes that but it appears packets aren't being forwarded. (I don't have a sniffer or anything set up to check for sure what's going on though.)
As far as ARP, I've never worked with ARP. But I don't understand how doing something with ARP would work where IP/MAC binding wouldn't.
Btw, I have my cable modem is hooked to the WAN port of the USG and the LAN1 port of the USG goes to a switch. All my network devices are hooked to the switch. The switch was properly broadcasting *.255 traffic with my ZyWALL 2W so my assumption at this point is that the router is not forwarding to *.255 when an appropriate NAT rule is in place, even though the web interface in the device accepts the entry. |
|
|
|
DrTCPYours trulyPremium,ExMod 1999-04
join:1999-11-09
Round Rock, TX | I did not think IP-Mac binding would work but it was worth a shot. Basically, to wake up a single computer behind ZyXEL, you need a static ARP entry since firewall needs to resolve IP (layer-3 address) to MAC address of the interface (layer-2 address) for delivery to take place.
I guess we need to ask ZyXEL to at least add a CLI command to manipulate the ARP table. ZyNOS has this capability. It is missing from USG although the underlying Linux provides such tools. |
|
DrTCPYours trulyPremium,ExMod 1999-04
join:1999-11-09
Round Rock, TX | reply to Gork
said by Gork:So, DrTCP , it sounds like you're saying that being able to use WoL through the Internet to boot up one of any number of computers on a LAN behind a router is not compliant with standards? You have to pick a only a single computer to wake with a magic packet? It seems WoL was designed to be broadcast to an entire subnet so you could easily choose a single computer to start up. Yes, broadcast messages are intended to stay in their physical segment. A unicast message received at one interface is not supposed to be forwarded to a broadcast address. That was a design bug in ZyNOS. WoL does not care broadcast or unicast. The packet is only supposed to look like a WoL magic packet in payload, irrespective of how that payload is delivered. NIC however will only look for its own MAC and broadcast addresses (and perhaps multicast addresses as well) |
|
GorkOu812ic
join:2001-10-06
Bountiful, UT
4 edits | reply to DrTCP
The CLI reference document for the USG 20W indicates {arp IP mac_address} "edits or creates an ARP table entry." I haven't tried it though - I'm still trying to wrap my head around it. I just can't understand how associating an IP address with a MAC address via ARP would work when associating it via MAC binding would not. My inability to understand is probably due to my lack of knowledge.
And now I've just found out my VPN through the USG 20W to an OpenVPN server from the WAN isn't working either, though it was on the ZyWALL 2WG. My other servers are accessible just fine. /sigh But that one's for another thread...
EDIT:
The console on my router indicates there is already an ARP entry for the IP/MAC for the computer I'm trying to wake using WoL... (The command is {show arp-table}.) At this point I assume entering a MAC/IP binding created the entry because there's nothing else I've done which would have populated this ARP entry.
So I'm left wondering if the only way you can send a WoL packet from the WAN interface to a computer on the LAN is if the computer is already turned on. (Now isn't THAT super helpful?!) |
|
GorkOu812ic
join:2001-10-06
Bountiful, UT
2 edits | reply to DrTCP
said by DrTCP:you need a static ARP entry Yeah, the ARP entry I indicated was already there was not static - it disappeared after the computer was turned off for awhile. While it was there, though, I was able to get WoL to work WAN to LAN, but only for that short period of time. /sigh
EDIT:
The CLI PDF file that is available for the 20W indicates the arp command is valid, but the console doesn't recognize it as a valid command. So much for that idea as well. Ridiculous. It looks like I may be putting the 2WG back into place and taking the 20W over to Mom's instead of the other way around as I had planned. |
|
| reply to jdmt
Well technically the USG is doing the right thing, while the ZyNOS device did not. It was a bug that turned into a feature....
Have you looked into running a WOL Proxy on an always on host on your LAN? Or maybe ask ZyXEL to implement a WOL proxy on the USG?
--
"Perl is executable line noise, Python is executable pseudo-code."
|
|
DrTCPYours trulyPremium,ExMod 1999-04
join:1999-11-09
Round Rock, TX | reply to Gork
said by Gork:said by DrTCP:you need a static ARP entry Yeah, the ARP entry I indicated was already there was not static - it disappeared after the computer was turned off for awhile. While it was there, though, I was able to get WoL to work WAN to LAN, but only for that short period of time. /sigh EDIT: The CLI PDF file that is available for the 20W indicates the arp command is valid, but the console doesn't recognize it as a valid command. So much for that idea as well. Ridiculous. It looks like I may be putting the 2WG back into place and taking the 20W over to Mom's instead of the other way around as I had planned. 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.
You see ZyNOS had matured over the years based on customer and beta tester feedback and USG platform is still young. |
|
 AnavSarcastic Llama? Naw, Just AcerbicPremium
join:2001-07-16
Dartmouth, NS
kudos:3 | said by DrTCP:said by Gork:said by DrTCP:you need a static ARP entry Yeah, the ARP entry I indicated was already there was not static - it disappeared after the computer was turned off for awhile. While it was there, though, I was able to get WoL to work WAN to LAN, but only for that short period of time. /sigh EDIT: The CLI PDF file that is available for the 20W indicates the arp command is valid, but the console doesn't recognize it as a valid command. So much for that idea as well. Ridiculous. It looks like I may be putting the 2WG back into place and taking the 20W over to Mom's instead of the other way around as I had planned. 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. You see ZyNOS had matured over the years based on customer and beta tester feedback and USG platform is still young. Oh good a chance to debate. I take issue with the last statement. All the feedback input from the past should not have to be reborn each time. They should build on past knowledge not discard it.........
--
Ain't nuthin but the blues! "Albert Collins".
Leave your troubles at the door! "Pepe Peregil" De Sevilla. Just Don't Wifi without WPA, "Yul Brenner"
LlamaWorks Equipment |
|
| said by Anav:Oh good a chance to debate. I take issue with the last statement. All the feedback input from the past should not have to be reborn each time. They should build on past knowledge not discard it.........
On the budgets and time limits that a new product needs to be delivered, that's wishful thinking Unless you want to buy seriously high-end stuff.
But its ZyXELs goal to get ZLD to do all that ZyNOS did and much much more. It just takes time, because not only do they need to get it on par on ZyXELism stuff,but they need to keep up with everybody when it comes to new features etc. And engineers are a scarce resource and you need prioritize customers that screams for the new stuff. Its a very difficult balance todo, personally I like that they dump all dumb ZyNOS stuff and give me IPv6 :P
--
"Perl is executable line noise, Python is executable pseudo-code."
|
|
GorkOu812ic
join:2001-10-06
Bountiful, UT
2 edits | reply to dslpartner
said by dslpartner:Well technically the USG is doing the right thing, while the ZyNOS device did not. It was a bug that turned into a feature.... Either way, it is kind of sad that the bug turned feature is an option which can be de/activated in much lower end units released by other companies.
said by DrTCP:If the manual is showing that ARP command is available and it is not working, open a defect ticket with ZyXEL. This would be a wise idea and I'll try to get up off my keester and do it. But, my guess is that this command WAS at one time available and was removed - that happened with a few commands in the NBG334W and the 2WG as well.
I did notice that people have been asking for this "multicast" ability since 2009 and it wasn't added in suqsequent releases, nor could I find a post by XyXEL that their stance was that it wouldn't be added. This lets the wind out of my sails a bit as far as opening tickets with them. But I realize sitting back on my haunches certainly won't get anything done.
said by Anav:All the feedback input from the past should not have to be reborn each time. They should build on past knowledge not discard it. When I purchased this router I did so under the assumption this would be the case. Silly me! I can't say as I'm surprised, what with all the bugs with the NBG334W.
So, before switching back to the 2WG (/cry) I put an an allow all firewall rule to capture what the router was doing with incoming WoL request sent through NAT to x.x.x.255:9, the broadcast address for my LAN subnet (and port for WoL.) The log indicated the firewall allowed the packet through, WAN to ZYWALL. I found that to be a bit odd - I expected it to show WAN to LAN1, or perhaps nothing if the packet was lost by the NAT rule before even hitting the firewall. |
|
| Does anything actually go from WAN to LAN without passing through the ZYWALL (which I think of as the core of the glorified IPtables functionality of the USG)?
kirby |
|
DrTCPYours trulyPremium,ExMod 1999-04
join:1999-11-09
Round Rock, TX | reply to Anav
It is unavoidable. The new routers are built on new platform. ZyXEL takes advantage of open source now. Whenever you change the OS platform, some features do not translate easily or needs to be developed independently. |
|
AnavSarcastic Llama? Naw, Just AcerbicPremium
join:2001-07-16
Dartmouth, NS
kudos:3 | True enough and dslpartner hit the nail on the head about the engineering resource issue. My experience of late is that what engineers would like to provide (quality) is more often thant not, blocked thwarted subverted, de-scoped, hamstrung, premature, by incompetent managers.
I concur with the poster however, that it is reasonable to expect some sort of continuity of functionality across product replacments (all that plus more..........). I cannot comment about porting to a diff OS, but its being done all the time, depends on the capabilities of staff I suppose. |
|
GorkOu812ic
join:2001-10-06
Bountiful, UT | reply to Kirby Smith
said by Kirby Smith:Does anything actually go from WAN to LAN without passing through the ZYWALL According to the manual, there is a difference between packets going through the router and packets destined for the router. And I tested... If you set up a firewall rule to allow a normal (not broadcast) through to LAN1 and log the activity, the log indicates the packet goes from WAN to LAN1, not from WAN to ZYWALL. |
|
