In the first post we separated two ideas that get tangled together: the architecture that decides who can reach what, and the transport that carries the traffic. ZTNA is about the architecture. The protocol underneath is just plumbing.
This post gets concrete. CloudConnexa is unusual in that the same service can run in two genuinely different access architectures — and you choose which one by how you model your resources, not by switching products. Understanding the two modes is the clearest way to see why "it’s a VPN" and "it’s ZTNA" can both be accurate descriptions depending on configuration.
The two ways to expose a resource
In CloudConnexa, you make internal resources reachable by representing them as one of two things:
- An IP Service — a subnet or set of IP addresses, with routes. This is the classic network-layer model. The client learns routes to IP space and can address hosts directly.
- An Application — a resource identified by a domain name. The client never learns the resource’s real IP or the network it lives on. It connects to a name, and the service brokers the rest.
That single modeling choice is the fork in the road between "full network" and "identity-aware proxy." Everything else follows from it.
Mode 1: Full network connectivity
Configure resources as IP Services and CloudConnexa behaves like a powerful cloud-based router and firewall. Subnet routes are exchanged. A connected device receives routes into your private IP space and can reach hosts by their actual addresses, subject to policy.
Network Connectors — which can use either the OpenVPN or IPsec protocol — join entire sites to the overlay and act as routers between your network and the cloud.
This is the mode that looks and feels like a traditional VPN, and for good reason: sometimes that’s exactly what you need. Site-to-site connectivity, lift-and-shift of existing applications, legacy systems that expect flat network reachability, IP-based services that were never designed to sit behind a name — all of these are served well by full network-layer connectivity. It’s the familiar, broadly compatible mode, and CloudConnexa supports it deliberately.
The trade-off is the one Zero Trust guidance warns about: when you route to subnets, the client has a map of internal IP space, and access tends to be expressed at the network level. You can still apply granular Access Groups, but the underlying exposure model is network-centric.
Mode 2: Pure identity-aware proxy
Now configure your resources exclusively as Applications — no IP Services, no exchanged subnet routes — and the architecture changes character entirely. This is CloudConnexa operating as a Zero Trust application proxy, and it works through a mechanism called Application Domain-based Routing.
Here’s what actually happens on the wire:
- CloudConnexa acts as the proxy DNS server for the session. When a user’s device looks up a configured application domain, the query is intercepted by CloudConnexa rather than resolved to the real server.
- Instead of returning the application’s true IP, CloudConnexa returns an intermediary IP address drawn from a dedicated Domain Routing range inside the overlay. This intermediary address is a stand-in — it bridges the traffic but reveals nothing about the destination.
- The device sends traffic to that intermediary address through the tunnel. CloudConnexa maps it to the correct connected network and the real destination, and brokers the connection.
The consequences are exactly the ZTNA properties from post one:
- No private network routes are exchanged. The client never receives routes into your IP space.
- Real server IPs and internal topology are cloaked. The client only ever sees an intermediary address from the routing range, so there is no internal map to scan and brute-force IP probing for application discovery doesn’t work.
- Access is per-application. Because resources are named applications, policy is expressed as "this identity may reach this application" — least privilege at the resource level, not the subnet level.
- Applications are hidden and isolated from the internet, reachable only through CloudConnexa after the identity and device clear policy.
This is an identity-aware proxy by any reasonable definition. There’s an intermediary that authenticates identity, evaluates policy, and bridges traffic to a named application without joining the client to the resource’s network. (Application Domain-based Routing depends on the CloudConnexa DNS Proxy being enabled — a useful detail to keep in mind, since turning it off disables the mechanism that makes this mode work.)
The policy layer is the same in both modes
Whichever exposure model you choose, the Zero Trust control plane sits on top:
- Setting the WPC topology to Custom flips the service to default-deny — nothing is reachable unless an Access Group explicitly allows it.
- Access Groups express permitted relationships between sources (users, networks, hosts) and destinations (applications, IP services), down to specific protocols.
- Device posture policies gate connections on OS version, antivirus presence, disk encryption, and client certificates.
- Location context policies constrain access by geography or IP range.
- Device Identity Verification & Enforcement (DIVE) binds a connection profile to a specific device so credentials can’t be lifted onto another machine.
- Continuous verification means posture and context are evaluated on an ongoing basis, not just at login.
In pure-Application mode, this control plane plus the cloaking and per-application scoping gives you a clean ZTNA posture. In full-network mode, the same control plane lets you tighten a more traditional deployment. The flexibility is the product.
On the "OpenVPN protocol means it isn’t real ZTNA" objection
Look again at what happens in pure proxy mode and ask where the OpenVPN protocol actually sits. It carries the encrypted session between the device and the CloudConnexa point of presence. That’s it. It is the transport — the equivalent of TLS under HTTPS.
Everything that makes the mode zero trust happens above that transport: the DNS interception, the intermediary IP substitution, the route suppression, the per-application policy enforcement, the cloaking of internal topology. None of that is a property of OpenVPN; all of it is a property of how CloudConnexa brokers access. You could swap the data-plane protocol and the architecture would be unchanged. You could keep OpenVPN and switch to full-network mode and the architecture would change completely. The protocol and the architecture move independently — which is the whole tell that they’re at different layers.
The reason the objection persists is historical association: OpenVPN, the protocol, is best known from the era of full-tunnel remote-access VPNs that did drop you onto the network. But "best known for" is not "limited to." The same encrypted-tunnel primitive can underpin a default-deny, identity-aware, application-scoped proxy — and in pure-Application mode, that’s exactly what it does. Judging the architecture by the transport’s reputation is judging the book by the typeface.
A fair-minded skeptic might push back: "If it can run as a full network, doesn’t that prove it’s really a VPN wearing a ZTNA badge?" The honest answer is that dual capability doesn’t dilute either mode. A service that can run default-deny with cloaked, per-application access is doing ZTNA when configured that way, regardless of what else it’s capable of. The relevant question for an audit or a design review is always "how is this deployment configured?" — not "what is the tool theoretically able to do?"
The takeaway
CloudConnexa isn’t a VPN pretending to be ZTNA, and it isn’t a ZTNA product that’s embarrassed about its tunnels. It’s one service that can express two architectures: full network-layer connectivity when you model resources as IP Services, and a pure identity-aware proxy when you model them exclusively as Applications. The OpenVPN protocol is the transport in both cases; the architecture is whatever your configuration makes it.
That dual capability turns out to be the practical bridge between where most organizations are today and where the Zero Trust guidance is pointing them. In the final post, we’ll walk that bridge — the migration from subnets and ACLs to least-privilege application access, without a forklift.
Frequently Asked Questions
What is an identity-aware proxy?
An identity-aware proxy is an access architecture where an intermediary authenticates a user’s identity and evaluates policy before brokering a connection to a specific application — without ever putting the client on the application’s network. It’s a pattern, not one vendor’s product: Google Cloud has a service by that name, and CloudConnexa’s Application-only configuration implements the same pattern independently, over its own transport.
What’s the difference between CloudConnexa’s full-network mode and identity-aware proxy mode?
Full-network mode exchanges subnet routes, so a connected device can address hosts by their real IPs, like a traditional VPN. Identity-aware proxy mode exposes resources only as named Applications, cloaks their real IPs behind an intermediary address, and never exchanges routes — access is scoped per application instead of per subnet.
Do I need different infrastructure, or a different CloudConnexa product, to switch modes?
No. Both modes run on the same CloudConnexa service and the same WPC overlay. The mode is set by how you model a resource — as an IP Service or as an Application — not by a separate product tier or deployment.
Can I mix both modes in the same CloudConnexa network?
Yes. The mode is set per resource, not per deployment, so most CloudConnexa networks run a mix — some resources exposed as IP Services for full-network reachability, others exposed exclusively as Applications for cloaked, per-app access.
How does Application Domain-based Routing hide internal IP addresses?
CloudConnexa acts as the proxy DNS server for the session. When a device looks up a configured application’s domain, CloudConnexa returns an intermediary IP address from a dedicated routing range instead of the real one, then maps traffic sent to that intermediary address to the actual destination behind the scenes.
Does using the OpenVPN protocol disqualify a deployment from being ZTNA?
No. The protocol only carries the encrypted session between the device and CloudConnexa’s point of presence — the same role TLS plays under HTTPS. Whether a deployment is ZTNA depends on the architecture built on top of that transport: default-deny policy, identity and device verification, route suppression, and per-application access, all of which are independent of which protocol carries the bytes.
Further Reading
- What ZTNA Actually Means — And Why the Transport Protocol Isn’t the Point (Part 1 of this series)
- How CloudConnexa Delivers the SSE Framework
- Why Zero Trust Network Access (ZTNA) Implementations Fail
- ZTNA and the SASE Roadmap
- How Access Server Does Domain-Based Routing (the self-hosted analog of Application Domain-based Routing)