Back
Lesson 2 of 6

Clientless ZTA on Secure Firewall

Objective

Configure clientless Zero Trust Access (ZTA) for web applications on a Secure Firewall so users can reach internal web apps from a browser without a VPN client. We will expose a single internal application (the finance web server) to browser-based access via a proxy-style architecture (clientless ZTA). This matters in production because it reduces attack surface (no full network access), simplifies UX (no VPN client), and allows per-application access control and inspection. A common real-world scenario: contractors or remote employees must access an internal finance portal (finance.lab.nhprep.com → 192.168.1.10) from unmanaged devices where installing a VPN client is not possible.

Quick Recap

Reference the topology deployed in Lesson 1. This lesson does not add new devices: we continue to use the Secure Firewall as the perimeter headend and the internal finance server.

ASCII Topology (referencing the same devices from Lesson 1; new/used IPs shown where required):

Internet (user browser) | | HTTPS / MASQUE over QUIC to firewall headend | Secure Firewall (headend / proxy) | | Reverse-proxied HTTP/HTTPS | Internal LAN | |-- finance.lab.nhprep.com — 192.168.1.10 (internal finance web server)

Note: The only exact IP from the reference used in this lesson is the internal host 192.168.1.10.

Key Concepts (theory + packet flow)

Before touching the CLI, understand these foundational points:

  • Proxy architecture (clientless ZTA): Clientless ZTA delivers access via a proxy rather than giving direct IP-level connectivity. In production, this means user browsers communicate with a proxy endpoint (the headend) that mediates and forwards requests to the internal app. The internal server never sees the user's original source IP unless the proxy preserves it.

  • MASQUE + QUIC transport: MASQUE provides multiplexed application transport on top of QUIC or TLS. QUIC is UDP-based (commonly UDP 443) and reduces latency — it supports connection migration and avoids TCP head-of-line blocking. For clientless access, the browser-to-proxy leg can use MASQUE/QUIC; if QUIC is blocked, traffic falls back to HTTP/2 over TCP 443.

  • Per-connection isolation: ZTA ensures each application/process gets a discrete proxied connection. Practically, that permits fine-grained policy (per-app, per-process, per-user) and prevents lateral network access from a client that only needs a single web app.

  • Firewall role in clientless ZTA: The Secure Firewall headend typically provides three responsibilities: advertise or resolve the public application name, accept external MASQUE/HTTP connections, and forward/proxy requests to the internal server (or integrate with cloud-based MASQUE proxy). In production, you must allow the transport (UDP 443 for QUIC and TCP 443 for fallback) and ensure NAT and access control are correct.

Step-by-step configuration

Step 1: Create a DNS host mapping for the finance app

What we are doing: Add a static host mapping so the application name resolves to the internal server IP for internal verification and documentation. This step helps testing and ensures consistent name-to-address mapping used by the proxy or firewall policy logic.

configure terminal
dns host finance.lab.nhprep.com 192.168.1.10
end
write memory

What just happened: The firewall now contains a local DNS host entry that maps finance.lab.nhprep.com to 192.168.1.10. This is useful for internal name resolution and for administrative checks — the firewall can use this mapping when resolving policies or generating logs.

Real-world note: On production headends the canonical name you expose externally may be a public name resolved by external DNS; the firewall's local mapping is useful for lab verification and split-DNS scenarios.

Verify:

show running-config | include dns host
dns host finance.lab.nhprep.com 192.168.1.10

Expected output:

dns host finance.lab.nhprep.com 192.168.1.10

Step 2: Create a network object for the internal finance server and configure NAT

What we are doing: Define the internal server as a network object and create a NAT rule so the firewall can forward/proxy traffic appropriately. NAT is often necessary when the headend needs a stable mapping to an internal resource.

configure terminal
object network OBJ-FINANCE-SRV
 host 192.168.1.10
 nat (inside,outside) static 192.168.1.10
end
write memory

What just happened: We defined an object named OBJ-FINANCE-SRV representing the internal host 192.168.1.10. The NAT statement maps the inside host to the outside address (static identity NAT in this lab). In a clientless ZTA architecture, NATing can be used to present a consistent destination to external clients or proxies; the firewall uses NAT entries when deciding forwarding behavior.

Real-world note: In production, NAT configuration depends on whether the proxy terminates TLS and re-originates connections to the internal server. If the headend performs reverse proxying, NAT might not change the DB server's address, but firewall policies still need to allow the proxy-to-app path.

Verify:

show running-config object network OBJ-FINANCE-SRV
object network OBJ-FINANCE-SRV
 host 192.168.1.10
 nat (inside,outside) static 192.168.1.10

Expected output:

object network OBJ-FINANCE-SRV
 host 192.168.1.10
 nat (inside,outside) static 192.168.1.10

Step 3: Permit external HTTPS (and QUIC fallback) to the headend for clientless connections

What we are doing: Allow inbound HTTPS (TCP 443) and the UDP transport used by QUIC (UDP 443) so client browsers can reach the headend via MASQUE/QUIC or fallback to HTTP/2. This is essential: if QUIC/TCP 443 are blocked, clientless ZTA cannot be established.

configure terminal
access-list OUT_TO_IN extended permit tcp any host 192.168.1.10 eq 443
access-list OUT_TO_IN extended permit udp any host 192.168.1.10 eq 443
access-group OUT_TO_IN in interface outside
end
write memory

What just happened: We created an access-list named OUT_TO_IN that allows TCP/443 and UDP/443 from any external host to the finance server IP (through the proxy headend/NAT mapping). Binding the ACL to the outside interface enables the firewall to permit the external connections needed for MASQUE/QUIC and the HTTP/2 fallback.

Real-world note: In production, you generally restrict source addresses or rely on the proxy cloud/provider to authenticate users before allowing traffic to the app. Opening TCP/UDP 443 to any source is for lab verification only.

Verify:

show access-list OUT_TO_IN
access-list OUT_TO_IN; 2 elements
access-list OUT_TO_IN line 1 extended permit tcp any host 192.168.1.10 eq 443 (hitcnt=0) 0x0
access-list OUT_TO_IN line 2 extended permit udp any host 192.168.1.10 eq 443 (hitcnt=0) 0x0

Expected output (example):

access-list OUT_TO_IN; 2 elements
access-list OUT_TO_IN line 1 extended permit tcp any host 192.168.1.10 eq 443 (hitcnt=0) 0x0
access-list OUT_TO_IN line 2 extended permit udp any host 192.168.1.10 eq 443 (hitcnt=0) 0x0

Step 4: (Lab) Document the proxy expectation and prepare inspection policies

What we are doing: Configure the firewall’s inspection/monitoring placements or documentation entries to indicate that the headend will act as a proxy for the finance app, and ensure inspection engines allow HTTP/2/3 characteristics and logging. Many Secure Firewall deployments perform TLS termination and apply inspection/policy at the proxy.

configure terminal
!--- For lab purposes, annotate the configuration with a description showing intent
object network OBJ-FINANCE-SRV
 description Proxy-target for clientless ZTA (finance.lab.nhprep.com -> 192.168.1.10)
end
write memory

What just happened: We added a description to the network object that documents the proxy intent. In production, you would configure an application-layer policy or integrate with the Secure Access service (MASQUE proxy) and enable TLS inspection or certificate handling as required. The annotation clarifies that the firewall-side configuration is prepared for a clientless proxy flow.

Real-world note: The actual clientless ZTA proxy behavior (MASQUE termination, user auth, and per-app policy enforcement) is often managed by the Secure Access service or dedicated proxy module. The firewall must allow the required transports and connect to the proxy service.

Verify:

show running-config object network OBJ-FINANCE-SRV
object network OBJ-FINANCE-SRV
 description Proxy-target for clientless ZTA (finance.lab.nhprep.com -> 192.168.1.10)
 host 192.168.1.10
 nat (inside,outside) static 192.168.1.10

Expected output:

object network OBJ-FINANCE-SRV
 description Proxy-target for clientless ZTA (finance.lab.nhprep.com -> 192.168.1.10)
 host 192.168.1.10
 nat (inside,outside) static 192.168.1.10

Verification Checklist

  • Check 1: DNS mapping exists — verify with show running-config | include dns host and expect the finance.lab.nhprep.com → 192.168.1.10 mapping.
  • Check 2: Network object and NAT are present — verify with show running-config object network OBJ-FINANCE-SRV and expect the host and nat lines.
  • Check 3: ACLs allow TCP/UDP 443 inbound — verify with show access-list OUT_TO_IN and expect permit lines for TCP and UDP 443.

Common Mistakes

SymptomCauseFix
Browser cannot reach the app via headendAccess-list missing or bound to outside interfaceEnsure ACL includes permits for TCP 443 (and UDP 443 for QUIC) and is applied to the correct interface (access-group ... in interface outside)
QUIC connections fail while HTTPS worksUDP 443 blocked upstream or firewall inspection drops UDPAllow UDP 443 in ACL and verify any DPI/inspection does not block QUIC; ensure fallback to TCP 443 is allowed
Internal server receives raw client IP but proxy expectedProxy termination not configured or proxy is doing direct pass-throughVerify proxy configuration: if the headend should terminate TLS and re-origin, adjust NAT/forwarding and X-Forwarded-For headers accordingly
Certificate errors in browserTLS termination or certificate not configured on proxy/headendEnsure the headend or proxy presents a certificate valid for finance.lab.nhprep.com and that the certificate chain is trusted by clients

Key Takeaways

  • Clientless ZTA uses a proxy architecture (MASQUE over QUIC / HTTP/2 fallback) to provide per-app access without a device-wide VPN. Think of the proxy as a secure translator: it terminates client-facing connections and creates controlled sessions to internal apps.
  • QUIC (UDP 443) improves latency and robustness (connection migration, no head-of-line blocking); always allow UDP 443 as well as TCP 443 for full functionality and graceful fallback.
  • On the firewall/headend the essential tasks are: ensure name resolution (DNS host mapping), prepare NAT/object definitions for the internal app, and permit the required transports. The actual authentication and per-user policy enforcement typically occur at the proxy service.
  • In production, never expose broad “permit any” rules; restrict access by source or rely on the authentication layer in the ZTA proxy to validate users and devices before granting application access.

Tip: Think of clientless ZTA as a hotel concierge: the user tells the concierge (proxy) what service they want, the concierge validates the request and credentials, and then fetches only that service for the guest — the guest never gets unrestricted access to the hotel's back office.

If you completed these steps in the lab environment, you have prepared the Secure Firewall headend to accept and forward clientless ZTA-style browser connections to the finance application. In Lesson 3 we'll walk through integrating authentication (SAML/IdP) and per-user policy so the proxy enforces which users can access finance.lab.nhprep.com.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security