1 edit | reply to lorennerol
Re: 2013 USG SHOULD ADD FUNCTIONALITY said by lorennerol:Bidirectional BWM/QoS for SIP that actually works. The current "Check the box and hope for the best" system is worthless, in my experience.
How should it just work, in general its hard to QoS/BWM incoming traffic from upstream ie down to you, since its the upstream node that really is the only one that can do it "right". At your point, it can always only be best effort, since the SIP traffic might have been delayed/dropped before it gets to your Firewall anyway.
It should be done on the CMTS, DSLAM, OLT or Switch that you are connected to. But that only helps if the ISP's MAN actually has enough bandwith, if not the QoS/BWM needs to be applied to all nodes in the ISP MAN. And then we have the variabels that is the Internet, same issue in regards to Bandwith applies for each node the traffic flows through there.
--
"Perl is executable line noise, Python is executable pseudo-code."
|
|
| reply to Anav
said by Anav:Presumably Zyxel will had some beef to the lean cuisine of zyxel CPU prowess (lets admit they are underpowered with regard to the services they want all to pay extra for). Not content with more brawn, what more brain power can be added to the lineup. That Italian Hippie has given me pause for thought to start up a list of highly ESSENTIAL new functioinality the USG should acquire (so at least the stuff they have matches the bugs they never fix).
Dont know if these are actually plausible but here goes:
(1) Ability to bridge layer 2 traffic
(2) Ability to tag packets with 802.1p at layer 2
(3) Ability to turn off permanently the update popup
(4) Allow URLs in rules vice simply IP addresses.
(5) Actually auto-update dyndns type services
(6) Ability to group Schedules for rules (like other objects damnit).
(7) Ability to ENFORCE schedule rules so that when it hits a block time the cache-tables whatever are flushed and the rules actually in place
(8) Ability to have both UDP and TCP in rules (especially so as to not have to create extra virtual server rules.*
(9) Better control of DNS and specifically if only want OPEN DNS available so users cant get thru on ISP.
(10) Ability to put group service rules into Virtual Server.
(11) packet trace test tool like as in CISCO ASDM (and shhh dont tell Hellfire)
Your turn!!
Quick feedback/reply
2. You should clarify this by writing frames, since its not packets that get 802.1p settings. (BTW doesnt the USG support DSCP -> 802.1p translation in the QoS)
4. See other posts
--
"Perl is executable line noise, Python is executable pseudo-code."
|
|
 mozerdLight Will Pierce The DarknessPremium,MVM
join:2004-04-23
Nepean, ON
3 edits | reply to lorennerol
said by lorennerol:Bidirectional BWM/QoS for SIP that actually works. The current "Check the box and hope for the best" system is worthless, in my experience.
When configuring BWM for VoIP I found that by following the Video example provided by ZyXEL in the USG Manuel titled ZYWALL USG 100_v3-00_Ed1 Page 51 very helpful.
Its not just "Check the box and hope for the best" --- its only step 1 "you" have to follow with additional steps to prioritize other traffic classes to be effective. I also dedicate one zone to VoIP traffic exclusively then apply Policies that manage what all other Zones can do with their allocated bandwidth. I do not use the SIP ALG. Check out the Video example --- its a good tutorial as a starting point.
[EDIT to correct reference] Then Check the same guide specifically Managing Traffic on page 104 section 5.1.1 titled Bandwidth Allocation Example which discuses a 10 person office and 7 classes of traffic. I found this to be very appropriate and works great for me in every instance I've applied it.
--
David Mozer
IT-Expert on Call
Information Technology for Home and Business |
|
| said by mozerd:said by lorennerol:Bidirectional BWM/QoS for SIP that actually works. The current "Check the box and hope for the best" system is worthless, in my experience.
When configuring BWM for VoIP I found that by following the Video example provided by ZyXEL in the USG Manuel titled ZYWALL USG 100_v3-00_Ed1 Page 51 very helpful. Its not just "Check the box and hope for the best" --- its only step 1 "you" have to follow with additional steps to prioritize other traffic classes to be effective. I also dedicate one zone to VoIP traffic exclusively then apply Policies that manage what all other Zones can do with their allocated bandwidth. I do not use the SIP ALG. Check out the Video example --- its a good tutorial as a starting point. [EDIT to correct reference] Then Check the same guide specifically Managing Traffic on page 104 section 5.1.1 titled Bandwidth Allocation Example which discuses a 10 person office and 7 classes of traffic. I found this to be very appropriate and works great for me in every instance I've applied it. I called tech support and set it up per their instructions. First on a ZyWALL 5, then on a USG 100. Spent hours over months working on it and finally threw in the towel and switched to a PRI. Tech support told me, "That's the best we can do."
My understanding is that there is way to control downstream by delaying acks on incoming packets. I haven't seen it work, but others say it does.
My item #3: Add a way to permanently turn off the nag to purchase filtering services; the 'remind every 30 days' setting is typical of cheap, Linksys-grade consumer gear, not $1000 business-class routers. |
|
| reply to Anav
The CLI section for timeouts is section 40.
k |
|
| reply to lorennerol
said by lorennerol:My understanding is that there is way to control downstream by delaying acks on incoming packets. I haven't seen it work, but others say it does.
Maybe it could have worked, IF all packets needed to be ACK'ed. Which for instance UDP doesn't, so if your pipe is filled with UDP traffic, delaying acks on incoming packets will have no effect what so ever.
Once again, its the point upstream from you that needs to do the QoS if you want it work correctly.
--
"Perl is executable line noise, Python is executable pseudo-code."
|
|
| reply to mozerd
said by mozerd:said by lorennerol:Bidirectional BWM/QoS for SIP that actually works. The current "Check the box and hope for the best" system is worthless, in my experience.
When configuring BWM for VoIP I found that by following the Video example provided by ZyXEL in the USG Manuel titled ZYWALL USG 100_v3-00_Ed1 Page 51 very helpful. Its not just "Check the box and hope for the best" --- its only step 1 "you" have to follow with additional steps to prioritize other traffic classes to be effective. I also dedicate one zone to VoIP traffic exclusively then apply Policies that manage what all other Zones can do with their allocated bandwidth. I do not use the SIP ALG. Check out the Video example --- its a good tutorial as a starting point. [EDIT to correct reference] Then Check the same guide specifically Managing Traffic on page 104 section 5.1.1 titled Bandwidth Allocation Example which discuses a 10 person office and 7 classes of traffic. I found this to be very appropriate and works great for me in every instance I've applied it. Since I'm now digging back into this, here is what the manual says right above the SIP BWM config example (Section 5.1.4), in section 5.1.3:
"The most effective way to ensure the quality of SIP calls is to go to the Configuration > BWM screen and enable BWM and select Enable Highest Bandwidth Priority for SIP Traffic. See the following section if you prefer to configure specific bandwidth management rules for SIP instead."
This seems quite clear to me. And I haven't found it to be effective at all.
Section 5.1.2 discusses setting the egress speed on WAN1 (equivalent to upstream Internet). Ingress is listed in the UI and 'for future use'. |
|
| reply to Anav
(Spreadsheet, row 7) DNS Server Control, Originator U475700, Ability to have finite control over router and user access to any DNS server
...how is this an issue? I'm doing it...
Rule 1) From:LAN1, To:WAN, Source:(your internal DNS server) Destination:Any, UDP 53 = allow
Rule 2) From:LAN1, To:WAN, Source:Any Destination:Any, UDP 53 = deny
Rule 3) From:LAN1, To:WAN, Source:Any Destination:Any, UDP 5353 = deny
...result is no clients inside the LAN can reach any outside DNS server except that which is specified in the first rule.
Granted, the licensing 'checks' to ZyXEL are annoying and not appreciated, but I'm pretty sure such traffic is not simply DNS traffic to a hard-coded source, nor does it effect clients behind the firewall.
(This post, listed 4) Allow URLs in rules vice simply IP addresses.
...this can be done under Content Filter > General + Filter Profile > Custom Service, Forbidden Websites
It will do HTTP traffic inspection on any of the ports specified (default of 3128, 80, 8080) so it is not really limited to just websites but any software making an HTTP request.
It works without any additional licensing, although the pages are worded kind of strangely to suggest it does. |
|
 AnavSarcastic Llama? Naw, Just AcerbicPremium
join:2001-07-16
Dartmouth, NS
kudos:3 | thanks imanon,
two points.
a. what is the default DNS setting by the router and if the one you made in rule one is not available what happens. I was under the impression that the router will go down your DNS list to find the next one that works including down to the default. I believe the entry was aimed at stopping the default one being used by the router in lieue of any other. I believe we cannot control this.
As for the second point perhaps I was not clear, URLs in NAT and firewall rules. THis is removed in an update (thanks to JP) Im working on because it is only possible in enterprise gear of much higher costs due to the processing power and fidelity required.
--
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 |
|
| a. It's true that ZyXel USG series will pull the ISP (WAN interfaces) DNS servers by default (if obtained through DHCP or PPPoE) and use them, but you can simply change the LAN1/LAN2/DMZ interfaces to use whatever DNS server IP you specify (rather then the router itself, which forwards onto whatever if got from WAN) and then restrict these interfaces to only allow UDP port 53 to the IPs you specify. This restriction works regardless of if the DNS server is internal to the LAN (like an Active Directory domain controller) or external (such as OpenDNS, NortonDNS, etc.) Personally, I would never let the router act as a forwarding DNS server (by handing itself out as the DNS server to clients behind the LAN1/LAN2/DMZ interfaces) but that's neither here nor there. I think that's where this "request" really comes from. Now if you put such restriction in-place, which I assure you works great, what I'm not confident about is if the router itself (for time update and licensing checks) will dis-regard what DNS server's you specified in there, and continue to use some built-in/secret DNS server - that remains to be sniffed out with Wireshark, and I do not have a spare USG to play with at the moment.
b. URLs in NAT. I concur that this is more of a DPI kind of thing, but such feature is not normally found under the firewall ruleset even in those more expensive enterprise devices that offer it. What I'm pointing out is that the USG series can infact do it (basically DPI) when configured through the Custom Service, Forbidden Websites ruleset - as what's really going on there is an inspection and re-write of any URL passing through the device (so long as it's on one of the ports indicated) The only limitation is that any URL "found" to match can only be configured as "re-written" to 1 location, and it can't "peek" inside of any HTTPs URLs (as it shouldn't cause those are supposed to be secured). I remembered where I found how I learned about this, it's here: »dnsredirector.com/sample/Zyxel/ |
|
AnavSarcastic Llama? Naw, Just AcerbicPremium
join:2001-07-16
Dartmouth, NS
kudos:3 | reply to Anav
Thanks for the info! |
|
 janderso1JimPremium,MVM
join:2000-04-15
Saint Petersburg, FL | reply to Anav
Share drives on USB ports For each USB port let the user set not shared (default for security), read only, or read/write. User would also need to be able to set the Windows work group. These would be Windows (samba) shares. User should also be able to set an idle time to put the drives in standby.
--
Jim Anderson |
|
 GorkOu812ic
join:2001-10-06
Bountiful, UT
 ·magicjack.com
| reply to Anav
Re: 2013 USG SHOULD ADD FUNCTIONALITY Multicast from WAN to LAN:
Allow an option to enable multicast from WAN to other interfaces as many lesser SOHO routers (and pre-USG routers as well) will do. My use would be to allow WoL packets from the WAN (over the Internet) to wake individual computers on the LAN.
User defined DDNS |
|
| said by Gork:Multicast from WAN to LAN:
Allow an option to enable multicast from WAN to other interfaces as many lesser SOHO routers (and pre-USG routers as well) will do. My use would be to allow WoL packets from the WAN (over the Internet) to wake individual computers on the LAN.
I thought that WoL used Broadcast? The way it was done on ZyNOS was to forward the WoL port to .255 to send it to all devices on LAN.
Which I guess technically was in breach of how things are supposed to work and the reason it was not supported on USG. But this was way back when.
--
"Perl is executable line noise, Python is executable pseudo-code."
|
|
| New ZyWALL USG 100-PLUS datasheet is out now:
»ftp://ftp.zyxel.com/ZyWALL_USG_50/data···50_6.pdf
The new USG 100-PLUS seems to have a much higher throughput. |
|
AnavSarcastic Llama? Naw, Just AcerbicPremium
join:2001-07-16
Dartmouth, NS
kudos:3 | reply to Anav
Yes and no, its spi throughput is beefed up but then it miserably falls back to below par levels for the services. In other words, they do not seem to understand that folks are not willing to pay for services that have such a performance hit. |
|
| reply to AndreSt
Looks to me like they took a USG 50 and added memory. Even the housing is the same. Should have called it the 50 plus. Maybe the UTM processing chip is not the same as the firewall processing chip and they only speeded up the firewall chip.
As Avav implies, the point of a unified security gateway is unified security, so boosting firewall rates without boosting UTM rates is missing the point of the device.
kirby |
|
| reply to Anav
said by Anav:Yes and no, its spi throughput is beefed up but then it miserably falls back to below par levels for the services. In other words, they do not seem to understand that folks are not willing to pay for services that have such a performance hit.
You misunderstand, because people are not willing to pay for the services, they are not putting effort into improving services that nobody wants anyway 
That is the way of the chinese :P
--
"Perl is executable line noise, Python is executable pseudo-code."
|
|
|
|
AnavSarcastic Llama? Naw, Just AcerbicPremium
join:2001-07-16
Dartmouth, NS
kudos:3 | Is this a guess JP or gleaned from conversations?? |
|
| said by Anav:Is this a guess JP or gleaned from conversations??
Guesstimate
--
"Perl is executable line noise, Python is executable pseudo-code."
|
|
