Some features/changes I would like to see in the router, balancing SOHO and Corporate.
LAN Side Routing.
The feature IS there, verified by looking at the source. At least what the img.bin would let me see in a hex editor. It's just disabled/hidden. Grabbing some hidden URL's, also pointed that routing to the LAN ports IS possible and a choice.
VLAN support
Limited by 3 virtual VLAN's. Understanding how a router works, I want to try and increase throughput on the lan side. For example, VOIP hardware on it's own VLAN, gaming systems on their own VLAN, and regular computers on it's own VLAN. This would reduce unessessary "talk" to every device on the network, therefore increasing bandwidth to those devices, as marginal as it may be.
Better implimentation of rules
The rules I talk about is for restricting upstream traffic by ports. For example, The only way to restrict web browsing is to create multiple rules to apply to one policy.
Policy name: Allow WEB Only
Ports to Dis-Allow
Filter: block 1 to 52 (allowing port 53 for dns)
Filter: block 54 to 79 (allowing port 53 for dns)
Filter: 81 to 442 (allowing port 80 for web)
Filter: 444 to 65535 (allowing SSL on port 443 for web)
It would be more efficient to also include an drop down of allow/disallow in the port range area. IE:
Name: Allow Port 80 Port Range: 80 - 80 Method:TCP Access: Allow
Name: Allow DNS Port Range: 53 - 53 Method:TCP Access: Allow
Name: Allow HTTPS Port Range: 443 - 443 Method: TCP Access: Allow
We *could* even go one step cleaner and have something like this for commonly used ports.
Name: Allow Web Access Service Type: HTTP/HTTPS can be a variable Access: Allow (choices: Allow/Deny)
So from this, we are allowing HTTP/HTTPS traffic. If HTTP being a choosable option from a pull down menu, which would actually be a variable as well to set the appropriate ports, it would allow port 80,443, AND DNS traffic on port 53.
DENY rules will ALWAYS have priority. So if one were to DENY Service Type: HTTP/HTTPS it would take precedance over the allow rule, in which case, we may stillwant DNS. Then we would have to create a custom RULE to DENY only port 80 and 443. The rule would then look like this:
Name: Deny Web Access Service Type: HTTP/HTTPS Access: Deny Allow DNS: Yes (determined by a check box or radio element.)
This would free up all the extra entries in the policy so we can apply other restrictions under that same policy if needed, without creating an additional policy.
(http://hpzdfa.bay.livefilestore.com/y1pp3ym62UD7SYH_ErsvQWh5ueRQi8ZFRZYsMySt1F_TYRwczr0T4ptcedW8v7_OjqeimXGcRgaXjmEmUgqGgczGA/port%20rules.PNG)
The old way.
(http://hpzdfa.bay.livefilestore.com/y1pDc-rFDuN_5imq-_gaBd41r-YhYmxgisEHUptPU8NBUO-3P7vnqwSkOWG00ldRV-MYo4U4v8zYxUh0jRlVG1KJg/new%20port%20rules.png)
The new way.
Ignore the last column. It would no longer be there. I had a brain fart and forgot to edit that out. The explaination is a little off as well. I changed the Allow DNS to Include DNS, meaning whether or not to include DNS as part of that rule, seeing that the otherway around would be a conflict with allow/deny scenerio when deny takes precedence over allow.
New Submenu type under Status:
Connection List.
This will list all computers connected to the network, both LAN and Wireless. With an identifier to associate the two methods. From here, because it is now under the new Admin menu, we can now logically administer these connections. Kill a wireless client, revoke/reserve IP addresses.
This would be a lot easier than jumping from one page to another between stat's and administration, for wireless and wired computers. We would be able to see ALL connections in one place and eliminate the duplicate entries in their current placement.
Support for OpenDNS
Would be great to add support for OpenDNS in the DDNS settings. (yay!)
Seperate Rules for 2nd SSID
For those that make use of the second SSID regardless if it's encrypted or open, it could be benefitial to have separate policies apply to that second SSID. As of current, it allows all web access, but not access to the internal network. However, this means that these clients can still hog all the bandwidth and do as they like using HTTP. It would be great if a policy could be constructed to allow only http/https/dns, restricting these clients from using p2p services and other services that could harm the WAN traffic.
Portal for 2nd SSID
A landing page for those who connect to the 2nd SSID informing them of the restrictions. With a "continue" button the sends them to a pre-determined URL configurable by the admin.
Network filtering / Website Filtering
Include a feature to read from a list of ip addresses to disallow incoming communication. As well as reading from a list of unsafe website addresses. All this as opposed to entering everything in manually. This way, one could download a list from the internet that has already been generated, usually by 3rd party applications. This would also effectivly block those addresses that embed advertising in their pages, that may or may not be offensive.