NexusSec.Most people meet zones the first time they open a modern firewall and find that rules ask for a source zone and a destination zone before anything else. It looks like an extra step. It is actually the idea that makes a firewall policy survive years of changes.
The idea in one paragraph
A zone is a group of network segments that share a level of trust: the staff network, the servers, the guest Wi-Fi, the internet. The firewall stops thinking about individual cables and starts thinking about boundaries. A connection that stays inside one zone is not its concern. A connection that crosses from one zone into another is checked against the rules written for that pair of zones, in that direction.
The parts
- Zones. Named groups of interfaces, VLANs or tunnels, such as Staff, Servers, DMZ, Guest, IoT and Internet.
- Zone pairs. A source zone and a destination zone, for example Staff to Servers. Policy is attached to the pair, not to a port.
- Direction. Staff to Servers and Servers to Staff are separate pairs with separate rules. Allowing one does not allow the other.
- Default deny. If no rule allows a crossing, it is dropped and logged.
- State. The firewall remembers connections it has allowed, so reply traffic for an allowed session gets back without a rule of its own.
How vendors treat traffic inside a zone
The default for traffic that stays inside one zone is where products differ, so it is worth checking on yours. On Cisco's zone-based policy firewall for IOS routers, traffic between interfaces in the same zone is allowed by default and traffic between different zones is dropped unless a policy permits it. Palo Alto Networks firewalls ship with two default rules, one allowing intra-zone traffic and one denying inter-zone traffic. Other platforms let you choose. If devices in the same zone should not reach each other, as on guest Wi-Fi, split the zone or use isolation on the switch or access point.
Zones compared with per-interface rules
| Question | Per-interface rules | Zone-based policy |
|---|---|---|
| Where rules live | On each interface, inbound or outbound | On zone pairs, in one policy |
| Adding a new VLAN | Write a new set of rules for it | Put it in the right zone; it inherits that zone's policy |
| Reading the policy | Reconstruct intent from many lists | Each rule names where traffic comes from and goes to |
| Default for new paths | Depends on how each list ends | Denied between zones until a rule allows it |
Per-interface rules are not wrong. Firewalls such as pfSense and OPNsense write rules per interface, and a well-run one is perfectly secure. The difference is how well the policy holds up when the network changes and the person who wrote it has moved on. Grouping interfaces, which both of those platforms support, gets most of the benefit.
What zones do not do on their own
A zone boundary decides whether a connection may cross. It does not, by itself, look inside the connection. Application control, intrusion prevention, malware scanning and TLS inspection are applied to the traffic a zone-pair rule allows. That is why a good rule names the application and the users as well as the zones, and why the inspection settings belong on the rule rather than being switched on globally and forgotten. For what to decrypt, see TLS inspection: what to decrypt and what to leave alone.
Where to go from here
If you are planning zones for an existing network, zones first is the practical version of this article, with a starting set of zones and a way to move an existing firewall onto them in phases. If the network is flat today, one laptop should not reach everything explains why that matters most.
NXSgate, the firewall NexusSec is building, is designed around this model from the start: zones, default deny between them and a rule for each direction. It has not been released yet.
