ENDIAN Firewall - Multiple zones with VLAN

While you are absolutely right (timupci) about VLANs and ZONEs being different, I think I would tend to agree more with Nir1978. EFW completely marries the two when it comes to what is commercially accepted as the "standard" way of using VLAN. Also, by the protocol's very nature, each VLAN has its own subnet as well (at least when I use them).

The average product (OTHER THAN EFW) that offers VLAN capabilities, also offers the following abilities:

1. Assigning a direct IP to the VLAN interface (not bridged / br0), allowing for each VLAN member to be assigned a default gateway that ACTUALLY EXISTS in the router. While this could be done with a bridge (e.g. br0.10 for VLAN 10), the bridge would then requires additional firewall rules due to the GAPING security hole it introduces. The firewall rules would then waste valuable resources (CPU, memory, etc.). This seems like a wasteful method to me. It's worth noting here that the bridging technique is what EFW uses.

2. Creating multiple subnets in the DHCP pool to support as many VLANs as needed. EFW Zones are brought up often in the VLAN/DHCP subject, as they are currently the only way (I believe) to assign different DHCP subnets to the VLANs.

3. Security / Firewall rules for VLANS.

4. and a lot more.

The only way that I understand to get these capabilities in EFW is to use the zones outside of their intended use case (i.e. DMZ, Wi-Fi, etc.) Furthermore you could really only do it for up to four VLANs (including WAN). As an example of how truely moronic this can be, I'm currently working on a job at a university that would greatly benefit from the firewall and content filtering in EFW. However, they have 96 trunked VLANs (in standard Cisco style configs), making EFW basically useless as a standalone solution. Keep in mind that I could always hack the config files; using vconfig, brctrl, and ip/ifconfig to set the VLAN interfaces, while (more or less) completely destroying the dhcp.conf file (template) to accommodate them all, but alas, I would also destroy the ability to manage the EFW from the web interface, meaning that my customer(s) would have no recourse.

To be fair, it's like the most important parts of VLAN is directly in conflict with the zones. This leads to one of two options (in my opinion):

1. Allow for the creation of additional zones. This would be a band-aid, as all it would accomplish is giving the capabilities back VLAN, the very ones they should have had all along.

OR

2. Pull the EFW fork even further away from IPCop by finally (once and for all) abandoning the zone concept all together. I know I'm speaking blasphemy here, but think about it. We could actually have all of the incoming, outgoing, and inter-zone (though would now be called interface to interface) rules, configs and capabilities that we have now, but multiplied by however many physical or virtual interfaces that we have. This would also require the ability to edit IP Addressing (and other configs) out side of the Network Configuration Wizard, but I believe that as an "advanced" option, this would be a welcome change too.

All in all, IPCop's zone concept was great for it's time, but is now the monolithic and thick headed 800 pound gorilla holding us all back. Until then, EFW will never be able to perform as a true gateway device in the real enterprise. It is also worth noting that 85% of most VLANs that I've created or encountered would technically be considered the GREEN zone. Just saying.

Please hold your flaming, but I welcome disagreement here. I would love to learn that I'm flat wrong, so teach me!