Learning outcomes
- Trace identity and policy through a client-assisted TCP or UDP path.
- Distinguish connection authorization from application protocol authentication and permission.
- Define name, port, lifetime, reevaluation, and bypass controls.
- Test long-lived, connectionless, direct-origin, and destination-confusion failures.
System and boundaries
Include the native application, local connector or tunnel client, identity and authorization service, external listener, proxy, upstream connection, protocol server, application authentication, and evidence. For TCP, model a stateful connection. For UDP, model messages or an association that lacks TCP connection semantics.
Name the external service identity, local port, target host and port, protocol, subject, and maximum connection lifetime. Do not treat a local listener as a general network interface.
Request and decision flow
The user or workload authenticates the local access client. The client requests a named destination. The access system validates the binding and policy, opens or forwards approved traffic to the configured upstream, and records connection evidence. The protocol client then performs any native server authentication and application authorization that the protocol requires.
For long-lived TCP, define whether policy changes affect the current connection or only new connections. For UDP, define how client association, source, destination, idle state, and expiry are tracked.
Failure domains
- A local listener accepts untrusted local users or binds to a public interface.
- Destination data lets the client reach an unapproved host or port.
- A direct origin bypasses identity-aware access.
- Connection authorization is treated as database or broker permission.
- A TCP session continues after user or device authority changes.
- UDP association state permits injection or outlives policy.
- DNS changes map a permitted name to an unintended target.
Design tradeoffs and residual risk
Client-assisted access supports native protocols but requires endpoint software and credential custody. Connection-level policy is efficient but cannot inspect every application action. Short connection limits improve revocation but disrupt stateful work. UDP support needs explicit association rules because the transport is connectionless.
Keep native server authentication and least-privilege roles when the service supports them.
Pomerium boundary
Pomerium provides documented client-assisted TCP and UDP routes and separate native SSH capabilities. Pomerium authorizes the route or connection. The database, broker, remote desktop, or other server must enforce its own authentication and application permissions. Operators must close direct origin paths.
Exercise
Model one database over TCP and one name service over UDP. Record local bind address, user identity, destination, port, route policy, upstream network path, native protocol identity, connection or association lifetime, revocation behavior, and logs.
Test another local user, wrong destination, direct origin, policy removal during use, client crash, stale DNS, UDP spoofing, and server-level permission denial.
Evaluation checklist
- Is the local connector bound and authenticated for the intended user?
- Can the client select any host, port, or protocol outside the named route?
- Does the native service keep its own authentication and permission model?
- Are TCP lifetime and UDP association expiry and revocation explicit?
- Are direct-origin, DNS, long-lived, and local-client bypass cases tested?
Next learning unit
Clientless Zero Trust Access
Distinguish browser or native-client access from broad network tunnels and state which protocols still require a local connector.
