Designing a Secure ZTNA Data Plane: Reverse Proxy & Tunneling

Recommended resources

The freely available resources this lesson will direct you to.

Hello! Let's dive into the next lesson.

In our last session, we designed the ZTNA connector, the crucial component that securely bridges the gap between your private applications and the ZTNA control plane. We established that it operates on an outbound-only connection model and uses a strong, automatically-rotated cryptographic identity for authentication.

Now that we have a secure foothold inside the private network, we need to build the highway for user traffic. How does a request from a user's laptop in a coffee shop get securely transported to an internal server in a data center, all under the ZTNA model?

This lesson addresses the learning outcome: Design the reverse proxy and secure tunnel establishment for the ZTNA data plane, evaluating protocol trade-offs (e.g., TLS vs. WireGuard). We will architect the end-to-end data path, from the client device to the ZTNA service edge, and from there to the connector, focusing on the critical protocol choices that define the system's performance, security, and resilience.

1. The ZTNA Data Plane: A High-Level View

The data plane is the path that carries the actual user payload (e.g., SSH session data, HTTP requests to an internal web app). Unlike the control plane, which handles policy and configuration, the data plane is optimized for high throughput and low latency.

The typical flow involves three key components:

Client Agent: Software on the user's device that intercepts traffic destined for private applications.
ZTNA Edge Proxy: A reverse proxy in the ZTNA provider's cloud. It's the public-facing entry point for all user traffic.
ZTNA Connector: The agent we designed in the last lesson, running inside the private network.

The connection is not a single, direct tunnel from client to application. Instead, it's typically architected as two distinct legs stitched together at the ZTNA Edge Proxy:

Leg 1: User Device ↔ ZTNA Edge Proxy
Leg 2: ZTNA Edge Proxy ↔ ZTNA Connector

This "stitched" architecture is deliberate. The Edge Proxy acts as a policy enforcement point, terminating the user's connection, inspecting the request against the already-evaluated policy, and only then initiating a connection to the appropriate backend connector. This prevents unauthorized users from ever establishing a network path, however brief, to your internal infrastructure.

Now, let's explore the protocols we can use to build these tunnel legs. We'll focus on two leading, but architecturally distinct, approaches.

2. Protocol Deep Dive 1: WireGuard

WireGuard is a modern, high-performance VPN protocol known for its simplicity, strong cryptography, and kernel-native implementation. Its design philosophy makes it an excellent candidate for a ZTNA data plane.

To understand WireGuard from first principles, let's start with a presentation by its creator.

WireGuard: Next Generation Secure Network Tunnel

This talk, 'WireGuard: Next Generation Secure Network Tunnel' from Black Hat, provides an exceptional overview of WireGuard's design goals and core concepts.

Please watch from 00:29 to 13:50. As you watch, focus on these key architectural points: Simplicity and Audibility: Note the emphasis on a minimal code base (under 4,000 lines) compared to giants like IPsec or OpenVPN. Cryptokey Routing: Understand how WireGuard associates public keys with allowed IP addresses. This is the core mechanism we'll leverage. Statelessness: Pay attention to how the protocol appears stateless to the administrator, with session management handled automatically by timers behind the scenes.

Architecting a ZTNA Data Plane with WireGuard

In a ZTNA context, we would use WireGuard to establish the two tunnel legs:

The client agent on the user's device establishes a WireGuard tunnel to a specific ZTNA Edge Proxy.
The ZTNA Edge Proxy, upon receiving an authorized connection, uses a separate, pre-established WireGuard tunnel to communicate with the ZTNA Connector.

The "cryptokey routing" table, which is WireGuard's core mechanism, is not managed manually. Instead, it's dynamically programmed by the ZTNA control plane:

When a user authenticates, the control plane provisions the client agent with the ZTNA Edge Proxy's public key and sets its AllowedIPs to the IP addresses of the applications the user is authorized to access.
Simultaneously, the control plane tells the Edge Proxy to accept connections from the user's public key.

This design is elegant. The data plane simply enforces the routing decisions made by the control plane using WireGuard's native, high-performance cryptographic routing.

Performance and Scalability of WireGuard

A key reason for choosing WireGuard is its performance, which stems directly from its architecture. It's not just fast; it's designed to scale efficiently on multi-core systems—a critical requirement for a high-traffic edge proxy.

Is WIREGUARD Over-Hyped? Comparing Wireguard with OpenVPN and IPSec

This next video, 'Is WIREGUARD Over-Hyped?', provides an excellent technical breakdown of why WireGuard scales so well.

Watch from 11:52 to 13:11. The visual explanation of how WireGuard uses its own work queues to distribute cryptographic work across multiple CPU cores is a perfect example of a deep architectural design choice that yields significant performance gains. Contrast this with the single-threaded bottleneck described for other protocols.

This ability to parallelize encryption/decryption work across all available CPU cores means a ZTNA Edge Proxy built with WireGuard can handle a massive number of concurrent tunnels without being bottlenecked by a single core.

3. Protocol Deep Dive 2: Tunnels over HTTP (MASQUE)

An alternative approach is to avoid bespoke VPN protocols altogether and instead tunnel traffic over the most ubiquitous protocol on the internet: HTTP. The MASQUE (Multiplexed Application Substrate over QUIC Encryption) framework standardizes this approach.

This might seem strange at first—why wrap IP packets inside HTTP? The key benefits are network traversal and leveraging the massive, mature web ecosystem.

Beneath the MASQUE - a dive into Network Relay technology on ...

Let's explore this concept with the article 'Beneath the MASQUE', which provides a great introduction to this technology.

Please read the section '🚚 What is a relay, and why does it matter?'. Focus on the two primary mechanisms described: Extended CONNECT for TCP traffic. CONNECT-UDP for UDP traffic. \nNote the argument that this approach is simpler to manage than traditional VPNs and is more firewall-friendly.

Architecting a ZTNA Data Plane with MASQUE

In this model:

The ZTNA Client Agent acts as a sophisticated HTTP client.
The ZTNA Edge Proxy is a specialized HTTP/3 (QUIC) server, often built using a high-performance proxy like Envoy.
To access an application, the client agent sends an HTTP CONNECT request to the Edge Proxy. This request effectively says, "Please open a raw TCP or UDP tunnel to this internal destination for me."
The Edge Proxy authenticates the request (e.g., via a token in the headers), consults the policy engine, and if authorized, proxies the data to the ZTNA Connector. The connection to the connector could also be another MASQUE tunnel or the gRPC tunnel we discussed in the previous lesson.

The primary transport for this is QUIC (HTTP/3), a modern transport protocol that runs over UDP.

Performance and Resilience of QUIC

QUIC was designed to overcome the limitations of TCP. Its two main advantages are reduced connection latency and superior performance on lossy networks.

1. Faster Handshake (Reduced RTT)

TCP + TLS 1.3 vs. QUIC Handshake Comparison — This diagram illustrates the handshake process for traditional TCP+TLS versus QUIC. QUIC combines the transport and cryptographic handshakes, significantly reducing the number of round trips (RTTs) required to establish a secure connection. This results in lower initial connection latency.

2. Resilience to Packet Loss

TCP suffers from "head-of-line blocking." If one packet is lost, all subsequent packets in that stream must wait for it to be retransmitted, even if they have already arrived. QUIC solves this. It has multiple independent streams within a single connection, so the loss of a packet in one stream does not block others.

Beneath the MASQUE - a dive into Network Relay technology on ...

The 'Beneath the MASQUE' article includes a great section with performance graphs that vividly illustrate QUIC's advantage.

Please read the section '📊 A few notes on performance'. The graphs comparing throughput and Time to First Byte under packet loss conditions clearly show how QUIC 'shields' the inner traffic from unreliable network conditions, which is a massive benefit for users on mobile or Wi-Fi networks.

4. Protocol Trade-Off Analysis

As an architect, your job is to choose the right tool for the job. Neither WireGuard nor MASQUE/QUIC is universally "better"; they represent different sets of trade-offs.

Feature	WireGuard	MASQUE (over QUIC/HTTP3)	Architectural Consideration
Performance	Extremely high throughput due to kernel-native implementation and simple design.	Very low latency due to 1-RTT handshake. Excellent performance on lossy networks due to superior congestion control.	WireGuard often wins on raw, single-stream throughput on a stable network. QUIC often provides a better user experience on real-world, unstable networks (mobile, Wi-Fi).
Network Traversal	Uses a configurable UDP port. May be blocked on restrictive corporate or public Wi-Fi networks that only allow TCP/80 and TCP/443.	Uses standard ports for web traffic (UDP/443). Is almost indistinguishable from normal web traffic, making it extremely difficult to block.	MASQUE is the clear winner for reliability across unknown network environments.
Scalability	Excellent multi-core scaling is built into its core design via dedicated work queues.	Scalability depends on the underlying HTTP proxy (e.g., Envoy, Nginx), which are themselves architected for massive scalability.	Both approaches can be scaled to handle massive traffic loads. The engineering effort might differ.
Ecosystem	Minimalist. The protocol is the product. You build on top of WireGuard itself.	Leverages the entire web ecosystem: proxies, load balancers, TLS libraries, observability tools (e.g., OpenTelemetry), etc.	Building with MASQUE may accelerate development by reusing mature, battle-tested components from the web services world.
MTU Issues	As a UDP-based protocol, it relies on Path MTU Discovery (PMTUD). If ICMP is blocked (a common network misconfiguration), PMTUD can fail, leading to dropped packets.	QUIC also runs over UDP and faces similar PMTUD challenges. However, TCP-based tunneling (CONNECT over HTTP/2) avoids this, as TCP handles MTU negotiation gracefully.	This is a subtle but important operational consideration for any UDP-based tunnel. It can lead to hard-to-diagnose connectivity problems.

MTU Fragmentation Diagram — Fragmentation, shown here, can occur when a large packet needs to traverse a network link with a smaller Maximum Transmission Unit (MTU). This adds latency and is a potential issue for UDP-based protocols like WireGuard and QUIC if Path MTU Discovery fails.

Conclusion

We have now designed the data plane for our ZTNA service, exploring two powerful but distinct architectural patterns.

Key Takeaways:

The data plane is a stitched, two-leg path: It runs from the client to an edge proxy, and from the edge proxy to the internal connector, with the proxy acting as the policy enforcement point.
WireGuard offers raw performance and simplicity: Its kernel-native implementation, minimalist design, and elegant cryptokey routing make it a top-tier choice for building a high-throughput data plane. Its architecture is optimized for multi-core scaling.
MASQUE/QUIC offers resilience and ecosystem leverage: Tunneling over HTTP/3 provides unparalleled firewall traversal and superior performance on unreliable networks. This approach allows you to build on the shoulders of giants by leveraging the mature, scalable ecosystem of web proxies and libraries.
The choice is a trade-off: As an architect, you must weigh the raw speed of a dedicated protocol like WireGuard against the operational benefits and real-world resilience of a web-native protocol like QUIC.

Preview of the Next Lesson:

So far, our policy decisions have been based primarily on a user's identity. But the "Zero Trust" mantra is "never trust, always verify." To truly verify, we need to know more than just who the user is; we need to know about the device they are using. Is it patched? Is its disk encrypted? Is malware protection running?

In our next lesson, we will design a device posture assessment system, including agent health checks, a signal collection pipeline, and compliance scoring. We'll give our client agent the intelligence to collect these critical signals and feed them back into our policy engine.