Where this starts

Three articles in this series already established the ground this one stands on. You Are Not Buying Nine Products set out the two modules, the enforcement order, and the reason two log views can disagree about one transaction. The Last Any Rule and DNS Control Rules covered two of the four tabs inside the firewall module: NAT Control and DNS Control.

This one is about the tab everybody opens first and understands last. Firewall Filtering is where the outbound rulebase actually lives, and it is also where the difference between the two firewall tiers stops being a line on an order form and becomes a constraint on what anybody can write.

1. Orchestration solves a different problem

The usual case for consolidating an outbound firewall estate starts with drift. Twelve sites, twelve rulebases, identical on the day they were built, and then somebody in one country needed an exception on a Friday afternoon. None of the copies is wrong. Each is locally correct, and collectively they are no longer a policy.

That argument is worth making honestly, because in a well-run estate it does not apply. Panorama, FortiManager, FMC and their equivalents exist precisely to solve it: one policy, authored once, distributed to every device, with divergence detected and reported. Anybody who has built that has already bought the consistency the brochure is selling them, and knows it.

The enforcement point is still the site. Orchestration distributes the policy. It does not move the policy to where the user is. A person who leaves the building leaves the policy, unless their traffic is carried back to a building that still has one.

Identity stops at the perimeter. In the appliance model, user awareness comes from an IP-to-user mapping fed by domain controller activity and agents that can see it. Inside, it works. Outside, it is empty, or it depends on a VPN being up. Rules about people, applying wherever those people happen to be, is not something a management plane delivers. It is something the architecture delivers or does not.

Capacity does not travel with the rule. Push a policy that adds inspection to more traffic and the rule arrives everywhere in seconds. The headroom to execute it does not. Every site keeps its own ceiling, its own refresh cycle and its own end-of-support date, and the orchestrator has no opinion about any of them.

Feature parity is the floor of the oldest box. A capability is usable across the estate only where every device supports it. Good orchestration surfaces the version skew honestly. It does not remove it.

Correlation is across products, not across sites. A firewall manager centralises firewall logs, which is a real and useful thing, and it is not the same as being able to read a non-web session, the web transaction and the DNS query for the same person at the same moment against one identity. That is section two.

What the cloud model changes is not the expressiveness of any single rule. A 5-tuple is a 5-tuple. It is that location stops being the boundary of the policy and becomes one of its criteria, and that the rule is written against the objects the rest of the policy already uses. The group in a Firewall Filtering rule is the same directory group as the one in a URL Filtering rule. In the appliance model the network rulebase is written in addresses while the web policy is written in people, and reconciling the two is a job nobody owns and everybody assumes somebody else is doing.

One more difference is operational rather than architectural, and it is small enough to state in a paragraph. A change here is saved and activated once, and the way back is a property of the rule rather than a restore procedure: a disabled rule keeps its rule order, the service skips it during evaluation, and enabling it again puts it back exactly where it was. Rule labels, a description field that runs to ten thousand characters, admin rank constraining which rule orders an administrator can occupy, and category search across a paginated policy do the rest. None of it is exciting. All of it is the difference between a rulebase and an archaeology site.

2. Where web and non-web traffic actually land

This one rarely makes the business case and probably should, because it shows up during an incident rather than during a procurement.

A PAC file steers web traffic. Z-Tunnel 1.0 carries web traffic. Everything else the device does — the SSH session, the database client, the update agent talking on a port nobody documented — takes a different road out of the building and is handled by something else, or by nothing at all.

The security consequence is obvious. The operational one is what costs time: the two halves of the same user’s activity end up in two systems, with two clocks and no shared identifier. Reconstructing what happened becomes a correlation exercise across tools, performed by whoever is awake, against logs that disagree about time zones.

Z-Tunnel 2.0 carries all ports and protocols to the same place. That solves the forwarding asymmetry, but it does not by itself guarantee that every flow arrives with usable user and device context; identity still depends on how the traffic is forwarded and authenticated, and section five returns to that.

What it does change is where the evidence lives. The web transaction and the non-web session for the same device at the same moment are recorded inside the same service, and can be investigated through correlated Firewall and Web Insights views, with a more consistent identity, device and time context where that context is available. That does not show well in a proof of concept, and it is the difference between an afternoon and a fortnight when somebody asks what a compromised laptop actually did.

6. Where a firewall rule actually runs

Before writing anything, it is worth recalling where in the sequence a Firewall Filtering rule sits, because almost every surprise in this policy comes from forgetting it. The enforcement order was set out in full in You Are Not Buying Nine Products, and the part that matters here is short.

The firewall module makes the foundational network and transport decision about whether a flow may proceed at all. With Advanced, it can also identify network applications at Layer 7 through deep packet inspection, which section ten covers. What it does not do is replace the transaction-level controls of the web module: which URL, which action inside an application, which file, are all decided afterwards and elsewhere. DNS Control governs a separate transaction again — name resolution, where it traverses the service — which will often precede the application flow without being another stage inside the same session.

This is not an interpretation. It is the reason Zscaler’s own recommended policy exists in the shape it does: a high-order Allow rule carrying HTTP, HTTPS and DNS as network services, so that traffic which will be governed more granularly by the web proxy and by DNS Control passes the Layer 3 and Layer 4 checks and gets judged in the modules that can actually see it. A firewall rulebase that tries to make those decisions by itself is competing with a module that has more information.

Two consequences follow and both return later in this article. A transaction can be allowed by the firewall and blocked by the web module, which is why the two log views can disagree about the same event. And the firewall can record a block it did not make, using an implicit rule that section twelve explains.

7. The rules you did not write

Readers of the DNS article will recognise the shape of this section, and the parallel is deliberate: a tenant in which nobody has ever written a firewall rule is not a tenant with no firewall policy.

The rest of the published best practice is short enough to state in full. Keep the default rule enabled, blocking, at the lowest order. Keep Block Malicious IPs and Domains enabled at a very high order. Block ICMP and QUIC with the Block/ICMP action, which for QUIC produces a fast failover to a protocol the proxy can inspect rather than a user watching a spinner. Consider blocking SMB outbound. And write every Allow rule with at least three conditions.

8. Microsoft 365, and the list nobody wants to maintain

Somewhere in every firewall project there is a meeting about Microsoft 365, and it is usually longer than anybody planned. The reason is in Microsoft’s own documentation, and it is worth looking at before deciding how much effort this deserves.

Microsoft 365 URLs and IP address ranges lists dozens of endpoint sets across four service areas, each classified as Optimize, Allow or Default, each with its own FQDNs and wildcard domains, its own IPv4 and IPv6 ranges, and its own ports. The ports are not all 443: Teams media runs on UDP 3478 to 3481, mail clients need 587, 993, 995 and 143, and mail protection needs TCP 25. The data is republished at the start of each month, with new addresses and URLs published thirty days before they go live, and Microsoft reserves the right to update mid-month for support escalations, security incidents or other immediate operational requirements. On top of that the target is moving: Microsoft is consolidating services onto a small set of dedicated domains under the .microsoft top-level domain, and those have to be reachable too.

Written by hand into a firewall rulebase, that is not a configuration task. It is a subscription to somebody else’s release calendar, for the applications the company cannot work without.

The One Click configuration is the alternative, and what it actually does is larger than its name suggests. Enabling one setting creates predefined rules across four separate policies: a Firewall Control rule allowing Microsoft 365 traffic whose destination matches the Microsoft 365 categories, a DNS Control rule allowing DNS traffic destined to Microsoft 365, an SSL/TLS Inspection rule exempting selected Microsoft-published FQDNs and IP ranges, and predefined Cloud App Control rules for selected Microsoft 365 applications, including OneDrive under File Sharing, Microsoft Azure under Hosting Providers and Outlook under Webmail. It also configures authentication exemption for the Microsoft domains without being asked. And Zscaler keeps the mapping current by reading the same REST web service Microsoft tells network vendors to use.

The performance side comes with it rather than being configured separately. DNS optimisation is applied automatically, the destination IP is overridden with the closest CDN endpoint for the application, and resolution is served by the DNS servers in each data centre. Zscaler states that its peering partnership with Microsoft means fewer hops into the Microsoft backbone. The traffic is fingerprinted along the way and lands in a dedicated Microsoft 365 dashboard.

It is worth being precise about what is and is not distinctive here, because this is the part of the story that usually gets oversold. Zscaler participates in the Microsoft 365 Network Provider Program, which identifies partner solutions validated for alignment with Microsoft’s networking principles for Microsoft 365 and which Microsoft has since closed to new network providers; Palo Alto Networks and Cloudflare announced membership of the same programme in 2022 and 2021 respectively. Peering with Microsoft is also more ordinary than the marketing suggests: Microsoft offers optimised public connectivity through Azure Peering Service partners, including ISPs, internet exchanges and cloud interconnect providers.

Which is the point for a firewall article. The alternative to One Click is not one rule. It is dozens of destination objects across several policies, reviewed monthly, for SharePoint, OneDrive, Teams, Exchange and everything that authenticates them — and a change window every time Microsoft moves something. That work does not make the company safer. It makes somebody responsible for a spreadsheet.

Two limits sit alongside that and are worth stating, because they cut in opposite directions. The mapping is deliberately partial: Zscaler documents mapping several but not all Microsoft address ranges and domains, for most rather than all Microsoft 365 applications. And endpoints Microsoft classifies as Default are excluded from One Click precisely so they can be treated as ordinary destinations and receive whatever controls the organisation wants to apply to them. The exemption is narrower than “Microsoft 365 is exempt”, and the coverage is narrower than “Microsoft 365 is handled”. Both sentences need testing against a real tenant before either goes into a design document.

Underneath all of that sits a decision worth naming even though this article is not the place to argue it: a checkbox that defines what counts as Microsoft 365, and removes it from inspection, is an act of trust in a vendor’s judgement about a list it does not publish. That is a reasonable trade for most organisations and a real one. It deserves its own article, and it will get one.

9. Anatomy of a rule

Criteria are grouped into five tabs. The relationship between tabs is AND, while relationships inside them vary: users, groups and departments are alternatives to each other, and so are the source and destination selectors. An empty field is not a narrow condition, it is an absent one, which is the commonest way a rule turns out to match far more than its author intended.

The choice between silence and a signal is the same decision that appears in the DNS article, and it has the same consequence. A silent block does not generate a report of being blocked. It generates a ticket saying an application is slow or will not start. End user notification exists for firewall blocks and closes part of that gap, on Windows endpoints with a recent Client Connector over Z-Tunnel 2.0, and it is one more capability behind the Advanced licence.

One boundary before writing a destination-based rule: the firewall examines the host portion of a URL and ignores the path. A rule blocking a category containing a specific page blocks everything bound for that host. The path lives in the web module, and so does any rule that needs it.

Sources and references

• Zscaler Help — Understanding Firewall Capabilities
• Zscaler Help — About Firewall Filtering
• Zscaler Help — Configuring the Firewall Filtering Policy
• Zscaler Help — Editing the Default Firewall Filtering Rule
• Zscaler Help — Understanding Predefined Firewall Filtering Rules
• Zscaler Help — About Microsoft One Click Options
• Zscaler Help — Recommended Firewall Control Policy
• Zscaler Help — Best Practices for Firewall Control Policy
• Zscaler Help — About Network Applications
• Zscaler Help — About Forwarding Control
• Zscaler Help — Enabling the Firewall for Locations
• Zscaler Help — Firewall HTTP Tunnel Connectivity
• Zscaler Help — Configuring Advanced Settings
• Zscaler Help — Firewall Insights Logs: Filters
• Zscaler — Cloud Firewall Deployment and Operations Guide
• Zscaler Zenith Community — Best practice for CFW rules with network application (DPI) detections as condition
• Microsoft Learn — Microsoft 365 URLs and IP address ranges
• Microsoft Learn — Microsoft 365 Network Provider Program
• Microsoft Learn — Azure Peering Service overview
• Palo Alto Networks — Prisma Access joins the Microsoft 365 Networking Partner Program (January 2022)
• Cloudflare — Cloudflare joins the Microsoft 365 Networking Partner Program (December 2021)
• Zero Trust Navigator — You Are Not Buying Nine Products. You Are Configuring One Decision.
• Zero Trust Navigator — The Last Any Rule: Bringing DNS Under Inspection
• Zero Trust Navigator — DNS Control Rules: The Policy That Runs First
• Zero Trust Navigator — The Location Is Not a User: How ZIA Decides Who Sent the Traffic
• Figures 1 to 9: original Zero Trust Navigator diagrams.

Behaviour described here follows Zscaler’s and Microsoft’s published documentation except where explicitly noted otherwise. Licensing boundaries move with the packaging, partner programmes change, and product behaviour changes; verify against current documentation and against your own entitlement before relying on any of it in a design.