Back
Lesson 1 of 6

Zero Trust Architecture Concepts

Objective

Understand the core principles of Zero Trust and Zero Trust Network Access (ZTNA), how proxy-based ZTNA uses transport protocols like QUIC and MASQUE, and how basic network configuration supports a ZTA deployment. We will configure a simple edge proxy/router to allow/proxy traffic from a remote user to a corporate application, demonstrate the required UDP/TCP port allowances that enable QUIC and TCP fallback, and verify connectivity. This matters in production because remote and hybrid workforces must be granted least‑privilege, audited access to specific resources without exposing the entire corporate network.

Real-world scenario: A London-based user needs secure access to a corporate web application hosted in the data center. The organization uses a proxy-based ZTNA model: clients connect outward to an access proxy (no inbound firewall holes), the proxy enforces identity and posture, and only proxied application flows reach the app servers. In production this reduces lateral movement risk and allows continuous validation of sessions.

Topology & Device Table

ASCII topology (all IPs are inside 10.0.0.0/8 as used in the reference material):

Client-London (User) -- GigabitEthernet0/0 -- Edge-Proxy -- GigabitEthernet0/1 -- App-Server (Corporate)

Network Topology Diagram

Device Table

DeviceInterfaceIP AddressSubnet MaskRole
Client-Londoneth010.10.10.10255.255.255.0Remote user host
Edge-ProxyGigabitEthernet0/010.10.10.1255.255.255.0External-facing ZTNA edge
Edge-ProxyGigabitEthernet0/110.20.20.1255.255.255.0Internal-facing to DC
App-Servereth010.20.20.10255.255.255.0Protected corporate application

Tip: Using addresses inside the 10.0.0.0/8 space matches the example corporate addressing in the reference. In production, these would be your actual DC and user subnets.

Key Concepts (theory before CLI)

  • Zero Trust / ZTNA (What it means): Zero Trust means "never trust, always verify." For network access, ZTNA enforces per-session, per-application access using identity, device posture, and context rather than implicit network location. In production this reduces blast radius by preventing direct inbound access to servers.

  • Proxy-based access (traffic flow): In proxy architectures, clients initiate outbound connections to an access proxy. The proxy terminates the client session, enforces policy, and establishes a separate proxied session to the resource. This ensures no direct inbound firewall openings to internal apps — the proxy is the only egress/ingress point.

  • QUIC & MASQUE behavior: QUIC (UDP/443) is the preferred transport: it provides reduced latency, connection migration across IP changes, stream multiplexing, and avoids TCP head-of-line blocking. MASQUE enables multiplexing multiple proxied streams (TCP, UDP, even IP) inside QUIC or TLS. Because UDP/443 can be blocked, implementations fall back to TCP/443 (HTTP/2) — ZTNA must permit both UDP 443 and TCP 443 for full interoperability.

  • Identity & posture: ZTNA decisions are made based on authenticated user identity (IdP, SAML), group membership (fed via SCIM/AD), and device posture (patch level, endpoint telemetry). In production, these signals are evaluated continuously — not just at session start.

  • Why ports and ACLs matter: Even with a sophisticated ZTNA control plane, the underlying network must allow the transports (UDP 443 and TCP 443) between client and proxy and between proxy and application. Misconfigured ACLs or NAT can break proxy tunnels or force fallback modes.

Step-by-step configuration

We will configure the Edge-Proxy router to (1) assign interface addresses, (2) create DNS host mapping, (3) permit QUIC (UDP/443) and TCP/443 through an access list applied on the external interface, and (4) enable basic logging to observe connection attempts.

Each step shows commands, what they do and WHY, and verification commands with expected output.

Step 1: Configure Edge-Proxy interfaces and enable them

What we are doing: Set the IP addresses on the external and internal interfaces on the Edge-Proxy so the device can receive traffic from the client and forward/proxy traffic to the app server. Interfaces are foundational; without correct addressing the proxy cannot participate in the network.

Edge-Proxy# configure terminal
Edge-Proxy(config)# interface GigabitEthernet0/0
Edge-Proxy(config-if)# ip address 10.10.10.1 255.255.255.0
Edge-Proxy(config-if)# no shutdown
Edge-Proxy(config-if)# exit
Edge-Proxy(config)# interface GigabitEthernet0/1
Edge-Proxy(config-if)# ip address 10.20.20.1 255.255.255.0
Edge-Proxy(config-if)# no shutdown
Edge-Proxy(config-if)# exit
Edge-Proxy(config)# end

What just happened: Each interface block assigned the configured IPv4 address and brought the interface up. no shutdown moves the interface from administratively down to up, allowing Layer 3 packet exchange. The Edge-Proxy now has reachability on both the user-facing subnet (10.10.10.0/24) and the DC subnet (10.20.20.0/24).

Real-world note: In production, interfaces facing the internet may be NATed behind provider addresses or located behind additional firewalls. Always coordinate with NAT and routing teams so the proxy's advertised addresses are reachable.

Verify:

Edge-Proxy# show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0     10.10.10.1      YES manual up                    up
GigabitEthernet0/1     10.20.20.1      YES manual up                    up
Loopback0              unassigned      YES manual administratively down down

Step 2: Create internal host mapping for the application (DNS shortcut)

What we are doing: Add a host table entry on the Edge-Proxy so it can resolve lab.nhprep.com to the internal app server IP without querying an external DNS. This is a simple operational step for labs and sometimes used to ensure the proxy resolves internal FQDNs to private addresses.

Edge-Proxy# configure terminal
Edge-Proxy(config)# ip host lab.nhprep.com 10.20.20.10
Edge-Proxy(config)# end

What just happened: The ip host command creates a static hostname-to-IP mapping in the device's local resolver table. When the Edge-Proxy or local clients (if configured to use the device for name resolution) resolve lab.nhprep.com, they will get 10.20.20.10. This prevents split-DNS problems during testing.

Real-world note: Production setups normally rely on authoritative internal DNS. Local static hosts are useful for lab validation or for bootstrap scenarios.

Verify:

Edge-Proxy# show hosts
Default domain is not set
IP address for lab.nhprep.com: 10.20.20.10

Step 3: Permit QUIC (UDP/443) and TCP/443 from users to the application via an ACL

What we are doing: Allow incoming UDP/443 and TCP/443 to the app server through the Edge-Proxy. QUIC uses UDP/443; proxies also require TCP/443 for fallback. An ACL applied on the external interface simulates the minimal network-layer allowance required for ZTNA transports.

Edge-Proxy# configure terminal
Edge-Proxy(config)# ip access-list extended ZTA_IN
Edge-Proxy(config-ext-nacl)# permit udp any host 10.20.20.10 eq 443
Edge-Proxy(config-ext-nacl)# permit tcp any host 10.20.20.10 eq 443
Edge-Proxy(config-ext-nacl)# deny ip any any
Edge-Proxy(config-ext-nacl)# exit
Edge-Proxy(config)# interface GigabitEthernet0/0
Edge-Proxy(config-if)# ip access-group ZTA_IN in
Edge-Proxy(config-if)# exit
Edge-Proxy(config)# end

What just happened: The access-list ZTA_IN explicitly permits UDP/443 and TCP/443 destined to 10.20.20.10, which are the transports used by QUIC/MASQUE and HTTP/2 fallback respectively. The ACL is applied inbound on the user-facing interface so packets from the client must match the permit statements to be processed. The implicit blocking of other traffic reduces exposure.

Real-world note: In production, ACLs would be combined with identity-based policy enforcement — the network ACL is a coarse filter; the ZTNA proxy enforces per-user, per-app policies.

Verify:

Edge-Proxy# show access-lists ZTA_IN
Extended IP access list ZTA_IN
    10 permit udp any host 10.20.20.10 eq 443
    20 permit tcp any host 10.20.20.10 eq 443
    30 deny ip any any (implicit)

Step 4: Enable logging to observe connection attempts and inspect QUIC fallback behavior

What we are doing: Turn on buffered logging so the Edge-Proxy records connection attempts for UDP/443 and TCP/443. This helps verify whether clients reach the proxy on UDP (QUIC) or are forced to TCP fallback.

Edge-Proxy# configure terminal
Edge-Proxy(config)# logging buffered 4096 debugging
Edge-Proxy(config)# ip inspect name ZTA_INSPECT udp tcp
Edge-Proxy(config)# interface GigabitEthernet0/0
Edge-Proxy(config-if)# ip inspect ZTA_INSPECT in
Edge-Proxy(config-if)# exit
Edge-Proxy(config)# end

What just happened: logging buffered configures local logging storage so we can later show logging. ip inspect creates a stateful flow inspector named ZTA_INSPECT for UDP and TCP; applying this inbound builds state entries for forwarded flows and can help observe whether UDP sessions were established or whether TCP fallback was used. Note: in a production ZTNA proxy the flow inspection is frequently performed by the access proxy itself and deeper application-layer telemetry is available.

Real-world note: Stateful inspection for UDP is limited — proxies typically use tokenized sessions and application layer multiplexing (MASQUE) to manage UDP-based QUIC flows.

Verify:

Edge-Proxy# show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
    Console logging: disabled
    Monitor logging: level debugging, 0 messages logged
    Buffer logging: level debugging, 10 messages logged
    Trap logging: level informational
Log Buffer (4096 bytes):
*Mar  1 00:00:01.000: %PKT_DROP-6-UDP_DROP: Dropped UDP packet from 10.10.10.10 to 10.20.20.10:443
*Mar  1 00:00:02.000: %PKT_ALLOW-6-TCP_ALLOW: Allowed TCP packet from 10.10.10.10 to 10.20.20.10:443

(Example log entries above show both a UDP drop and a TCP allow — useful for diagnosing QUIC fallback in labs.)

Step 5: Test connectivity from the Client (conceptual verification)

What we are doing: From the client, attempt to reach lab.nhprep.com on UDP/443 (QUIC) and TCP/443 to validate transport behavior. In a lab without application-layer QUIC clients, we at least test that traffic is permitted by the ACL and that the Edge-Proxy logs reflect the attempts.

# On Client-London (conceptual)
# Test TCP 443
> telnet lab.nhprep.com 443
# Test UDP 443 (use a UDP test tool or ping-like UDP tool; represented conceptually)
> sendudp lab.nhprep.com 443 "QUIC-TEST"

What just happened: The telnet to TCP/443 will establish a TCP connection if permitted; the UDP test checks if UDP/443 packets reach the app server (or are dropped by ACL/NAT). The Edge-Proxy logs and access-list counters should reflect the test outcome.

Real-world note: Modern browsers and ZTA clients implement QUIC/MASQUE differently — you may need an up-to-date client (Chrome, Edge) and properly configured proxy to see true QUIC-based proxying.

Verify (on Edge-Proxy):

Edge-Proxy# show access-lists ZTA_IN
Extended IP access list ZTA_IN
    10 permit udp any host 10.20.20.10 eq 443 (hitcnt=1)
    20 permit tcp any host 10.20.20.10 eq 443 (hitcnt=1)
    30 deny ip any any (implicit)

The hitcnt values indicate the ACL entries were matched by recent traffic.

Verification Checklist

  • Check 1: Edge-Proxy interfaces are up (show ip interface brief should show up/up).
    • How to verify: show ip interface brief — expect GigabitEthernet0/0 and GigabitEthernet0/1 up/up.
  • Check 2: DNS mapping for lab.nhprep.com resolves to 10.20.20.10 on the Edge-Proxy.
    • How to verify: show hosts — expect "IP address for lab.nhprep.com: 10.20.20.10".
  • Check 3: UDP/443 and TCP/443 are permitted and have been hit by test traffic.
    • How to verify: show access-lists ZTA_IN — expect permit udp and permit tcp entries with non-zero hit counts.
  • Check 4: Logs show whether UDP packets are passed or dropped (useful to detect QUIC success/fallback).
    • How to verify: show logging — check for UDP/TCP allow or drop log lines.

Common Mistakes

SymptomCauseFix
Client cannot reach app server on lab.nhprep.comNo IP route or interface is down on Edge-Proxyshow ip interface brief; correct interface config and no shutdown
QUIC (UDP/443) always dropped, only TCP worksACL missing UDP permit or NAT blocks UDPAdd permit udp any host 10.20.20.10 eq 443 and verify NAT allows UDP
Access-list shows zero hits after testsACL applied on wrong interface or wrong directionUse show run interface GigabitEthernet0/0 and ensure ip access-group ZTA_IN in is on user-facing interface
Name resolution fails for lab.nhprep.comNo DNS entry or ip host mappingAdd ip host lab.nhprep.com 10.20.20.10 or correct internal DNS

Key Takeaways

  • Zero Trust (ZTNA/ZTA) removes implicit trust of network location; access is granted per-session based on identity, posture, and continuous validation.
  • Proxy-based ZTNA uses outbound-initiated tunnels (QUIC over UDP 443 or HTTP/2 over TCP 443) so infrastructure must explicitly allow UDP/443 and TCP/443 between client and proxy and between proxy and app.
  • QUIC + MASQUE gives low-latency, multiplexed, resumable transports; when UDP is blocked, secure fallback to TCP/443 ensures connectivity — plan ACLs and NAT for both.
  • In production, the network-layer configuration (interfaces, routing, ACLs, DNS) is necessary but not sufficient — the ZTNA control plane (IdP, posture, policy enforcement) is what enforces least privilege and continuous verification.

Important: This lesson focused on the network prerequisites and basic proxy allowances that enable ZTNA flows (UDP/443 and TCP/443) and how to verify them. Subsequent lessons will cover how identity, posture, and application policy integrate with the proxy control plane to fully realize Zero Trust Access.

Practice with Hands-On Labs

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