Self-Hosted ZTNA: How Domain Routing Turns Access Server Into an Identity-Aware Proxy

One set of credentials, one flat subnet, one very large blast radius if anything goes wrong. It's the argument that's fueled a decade of "VPN is dead, Zero Trust is the future" vendor pitches - and it's a fair criticism of traditional remote access VPN.

It's also no longer an accurate description of what OpenVPN Access Server does. With domain routing, Access Server can be configured to stop granting network access altogether and instead broker access to individual applications by name, the same architectural pattern used by commercial identity-aware proxies. That's a meaningful shift, and it's worth examining on its own technical merits rather than as a footnote to a cloud ZTNA pitch.

The Real Complaint About VPNs Isn't Encryption - It's Scope

Nobody seriously argues that OpenVPN's encryption is weak. The actual complaint is about scope of access: once a client authenticates, IP-based access control rules determine what they can reach, and those rules are usually defined at the subnet level because that's how routing has traditionally worked. If a support rep needs to reach one internal ticketing tool, the "simple" path has often been to route them into the whole 10.0.0.0/16 network and rely on downstream firewalls to sort out the rest.

That's the pattern Zero Trust Network Access (ZTNA) was built to break. ZTNA replaces network-level trust with application-level, identity-driven access decisions; verify the user and device, then grant access to a specific resource, not a subnet. The mechanism matters less than the outcome: no standing network path exists between a client and anything it isn't explicitly authorized to reach.

What Domain Routing Actually Changes Under the Hood

Domain routing lets you write access control rules against a hostname - app.example.com, *.example.com, or even a wildcard TLD - instead of an IP address or subnet. That sounds like a convenience feature (and it is one, since it solves the real operational problem of CDN-backed and dynamic-IP SaaS apps breaking static IP allowlists). But the way Access Server implements it also happens to produce a proxy-like access mode.

• DNS interception, not network exposure. When domain-based rules are active, Access Server's DNS proxy intercepts the client's query for the matched domain and returns a mapped address from a dedicated internal pool (100.64.0.0/10 by default) instead of the real public IP. The client never learns, or routes toward, the actual destination address.
• A CNAT-style intermediate hop. That mapped address exists only inside Access Server's NAT/DNAT tables (verifiable directly via nft list chain ip as_nat AS_DOMAIN_RT or iptables -t nat -S AS0_DOMAIN_RT, as shown in OpenVPN's domain routing tutorials). Access Server does the DNAT translation from the internal IP to the real destination server-side, functioning as the intermediary for that connection rather than simply routing the client onto the destination's network.
•  No route to anything else. Because the client only ever resolves and reaches the domains explicitly permitted in its access rules, there's no residual network path to sibling systems on that subnet - which is precisely the lateral-movement risk that traditional full-tunnel and even naive split-tunnel VPN configurations leave open.
• Enforcement independent of shifting infrastructure. Rules are evaluated against hostnames, so access policy survives IP churn behind load balancers, CDNs, or autoscaling groups without manual rule maintenance - a practical requirement for any access model that claims to be policy-driven rather than infrastructure-driven.

In other words: point a client at app1.example.com, and Access Server resolves, intercepts, maps, and forwards that single connection - without ever putting the client on the same network segment as the application server. That's not "VPN with extra steps." That's an identity-aware proxy pattern, self-hosted.

Mapping Domain Routing to ZTNA's Core Principles

OpenVPN already frames Access Server as a foundation for Zero Trust Network Access, built on pillars like explicit verification, least privilege, assumed breach, micro-segmentation, and continuous monitoring. Domain routing is what makes least privilege and micro-segmentation enforceable at the application layer rather than the subnet layer:

•  Least privilege by domain, not by subnet. Access rules can be scoped globally, per group, or per individual user, so a Sales group can be permitted app2.example.com while a Support group is permitted only app3.example.com - with neither group able to resolve or reach the other's application, let alone the rest of the network it lives on. 

•  Deny rules for explicit exclusion. As of Access Server 3.2.0, deny rules let administrators block specific domains or subdomains outright - useful for carving exceptions out of a broader wildcard allow rule (allow *.example.com, deny internal-admin.example.com), which is a level of policy granularity flat network access simply can't offer.
•  Bypass and exclusion rules for split-tunnel precision. Bypass rules let specific domains skip the tunnel entirely while a match-all rule routes everything else through it - giving administrators fine control over exactly which traffic is proxied versus sent direct, instead of an all-or-nothing tunnel decision. 
•  Verifiable enforcement, not a policy on paper. Every claim above is checkable on the box itself: DNS proxy logs show queries being forwarded, mapped, or denied in real time, and firewall tables show the NAT translations backing each rule. For security teams who need to prove least-privilege access rather than just assert it, that auditability is the difference between a compliance checkbox and an actual control. 

Why "Self-Hosted" Doesn't Disqualify This as ZTNA

There's a lingering assumption that Zero Trust Network Access requires a cloud-delivered, vendor-brokered service sitting between users and applications. Nothing in the ZTNA model actually requires that - it requires identity-based verification and per-application access enforcement, full stop. Where that enforcement runs is an infrastructure decision, not a security one.

Running that enforcement point on infrastructure you control has real advantages: no third party in the data path for internal traffic, no dependency on an external vendor's uptime or breach history, and no negotiation over data residency or compliance scope. Access Server itself is SOC 2 Type 2, ISO/IEC 27001:2022, HIPAA, and GDPR compliant-ready, which is the same bar enterprise buyers hold cloud-delivered ZTNA vendors to - it's just running on a server you deployed rather than one a vendor operates on your behalf.

For organizations with strict data-sovereignty requirements, air-gapped or regulated environments, or simply a preference for owning their access-control plane outright, a self-hosted identity-aware proxy isn't a compromise version of ZTNA. It's ZTNA with the enforcement point kept in-house.

Getting Started with Domain-Based Least-Privilege Access

If you're running Access Server 3.1.0 or newer, domain routing is available from both the Admin Web UI and the CLI. A typical rollout looks like this:

1.  Enable the DNS server proxy globally (on by default in 3.1.0+, configurable via sacli --key "dnsproxy.mode"). 

2.  Define global, group, or user-level access rules against exact domains, wildcard domains, or wildcard TLDs - choosing NAT (traffic exits via the Access Server IP) or Route (traffic keeps the client's VPN IP) per rule. Domain routing cannot handle overlapping IP addresses, so routing to other sites needs different subnets. 
   1.  Note: if there are any IP address subnets present to represent the network that Access Server is deployed on, they should be removed and replaced only with domain names. 
3. Layer in deny rules for domains that should be explicitly blocked, and bypass rules for domains that should skip the tunnel entirely.
4. Verify enforcement using sacli AccessControlRulesList, DNS proxy debug logs, or the nft/iptables NAT tables - confirming policy and behavior actually match.

OpenVPN's documentation walks through each of these in detail, including full configuration via the Admin Web UI, role-based access scenarios with worked examples, and CLI-driven rule management for teams managing configuration as code.

The takeaway

Domain routing doesn't just patch over the VPN's biggest weakness - it changes what kind of tool Access Server is. Instead of authenticating a client onto a network and hoping firewall rules do the rest, it authenticates a client to a specific application and never gives it a network path to anything else. That's the identity-aware proxy model ZTNA is built on, running on infrastructure you host and control. If full network access has been the reason you've held off on OpenVPN Access Server, domain routing is the feature that changes the answer.