CloudConnexa and Azure VPN Gateway Point-to-Site (P2S) both give remote users and networks access into a private environment, but they start from different places. CloudConnexa is a vendor-operated global overlay that bundles Zero Trust Network Access (ZTNA), secure internet access, and site-to-site connectivity into one service. Azure VPN Gateway is a managed gateway you deploy inside your own Azure virtual network, one region at a time. This breakdown covers architecture, protocols, authentication, and Zero Trust access, so you can match the right tool to your environment.
CloudConnexa overview
OpenVPN CloudConnexa is a cloud-delivered network security platform that unifies ZTNA (private application access), secure internet access (content filtering, IDS/IPS), SaaS protection, and site-to-site connectivity into a single service. It's built around OpenVPN's Wide-area Private Cloud (WPC) model: an overlay private network spanning CloudConnexa's Points of Presence, through which customers connect their networks via software Connectors that require no inbound ports, and their devices via the OpenVPN Connect client, while OpenVPN operates the control and data planes. CloudConnexa uses OpenVPN Data Channel Offload (DCO) for high performance and applies Zero Trust controls based on identity, device, and location context. Client and device connections use the OpenVPN protocol, and IPsec is supported for site-to-site (Network Connector) connections. Its built-in Cyber Shield delivers content filtering and IDS/IPS, and the service is SOC 2 Type 2 and ISO/IEC 27001 certified.
Azure VPN Gateway overview
Azure VPN Gateway Point-to-Site (P2S) is a managed remote-access VPN that connects individual clients into an Azure virtual network (VNet), deployed as Azure-managed VMs in a dedicated GatewaySubnet within one region. It's a regional service tied to a VNet, without a global private backbone or PoP mesh for client connections, and gateway SKUs — Basic and VpnGw1–5, plus zone-redundant variants — set throughput and connection capacity. P2S supports the OpenVPN protocol (SSL/TLS), IKEv2, and SSTP (Windows-only, and being retired on Azure's published timeline); WireGuard is not supported. Authentication options include Microsoft Entra ID (OpenVPN protocol only, via the Azure VPN Client), certificates, and RADIUS/Active Directory, with MFA, Conditional Access, and Intune-based device compliance enforced through the separate Entra/Intune stack rather than the gateway itself — see our comparison of CloudConnexa and Microsoft Entra Private Access for how that broader stack compares to a ZTNA platform built for this from the ground up. Azure VPN Gateway is network-level connectivity with no built-in secure internet access: content filtering, DNS filtering, IDS/IPS, and application-level ZTNA are separate Microsoft products such as Azure Firewall, Microsoft Entra Internet Access, and Microsoft Entra Private Access.
When to choose CloudConnexa vs. Azure VPN Gateway
Choose CloudConnexa if you want a multi-cloud, vendor-operated service that bundles ZTNA, content filtering, and IDS/IPS; connects across a global set of regions; and offers application-level access controls, device posture, SCIM, and centralized logging without assembling separate products — or if you need site-to-site over IPsec or OpenVPN managed alongside remote access.
Choose Azure VPN Gateway if your environment is centered on Azure, you need managed remote access into a VNet with Entra ID authentication and Conditional Access, and you're prepared to add separate Microsoft services (Azure Firewall, Entra Internet Access, Entra Private Access) for filtering, threat protection, and application-level Zero Trust — keeping in mind that the gateway itself is network-level connectivity in a single region.
Architectural trade-offs
The two differ in where they run: CloudConnexa is a vendor-operated global overlay, while Azure VPN Gateway runs as managed VMs inside the customer's own VNet in one region. The points below weigh that difference and test where common claims hold.
Where Azure VPN Gateway's architecture can help
- Native integration with Azure networking (VNet, Virtual WAN) and Azure RBAC suits Azure-centric environments.
- Point-to-Site supports the OpenVPN protocol and IKEv2, and Entra ID authentication integrates with Conditional Access and Intune compliance.
- The gateway runs in the customer's own VNet and region, keeping the data path within the customer's tenant.
- Diagnostic logs integrate with Azure Monitor, Log Analytics, and Microsoft Sentinel.
- Zone-redundant SKUs provide intra-region high availability.
Trade-offs and claim-vs-reality
- It's a regional service tied to a VNet, with no global private backbone for client connections; global reach requires additional design (for example, Virtual WAN).
- Access is network/route-level, not application-level ZTNA — Microsoft positions Entra Private Access as a separate product for that.
- There is no built-in secure internet access; filtering and IDS/IPS require separate products (Azure Firewall, Entra Internet Access).
- MFA, device posture, and Conditional Access are not gateway features; they depend on the wider Entra/Intune stack (see the full CloudConnexa-vs-Entra comparison).
- Protocol and authentication combinations are constrained — Entra ID authentication requires the OpenVPN protocol specifically, and SSTP is Windows-only and being phased out (see the full breakdown of what changes when SSTP retires).
Feature comparison
Architecture & Deployment Model |
||
|
Capability |
CloudConnexa |
Azure VPN Gateway (P2S) |
|---|---|---|
|
Managed service |
Yes — WPC overlay; fully hosted |
Yes — managed gateway VMs in a GatewaySubnet |
|
Global edge / regions |
~36 Regions worldwide; full-mesh core |
Regional — one VNet/region; no global PoP mesh |
|
Multiple isolated overlay networks |
Yes — multiple isolated WPCs per account (segment OT, IoT, and IT networks) |
Yes (architecturally) — many isolated VNets per subscription; granular per-network access needs a separate gateway per VNet |
|
High availability |
Redundant full-mesh core network |
Zone-redundant gateways (AZ SKUs) for intra-region failover |
|
Capacity tiers |
Subscription-based; no capacity SKUs |
Basic / VpnGw1–5 SKUs set throughput and connection limits |
|
Device connection |
OpenVPN Connect client |
Azure VPN Client, OpenVPN client, or native IKEv2/SSTP |
|
Network / site connectivity |
Network and Host Connectors (IPsec or OpenVPN) |
Site-to-Site IPsec, VNet-to-VNet, Azure Virtual WAN [1] |
|
Multi-cloud reach |
AWS, Azure, GCP Connectors; plus VPS and routers |
Azure-centric; other clouds require additional plumbing |
Administration & Management |
||
|
Capability |
CloudConnexa |
Azure VPN Gateway (P2S) |
|---|---|---|
|
Web admin console |
Yes — dedicated Administration Portal |
Via the Azure portal (no dedicated VPN admin plane) |
|
Public API / CLI |
Yes — REST API with OAuth 2.0 |
Yes — Azure REST API, CLI, PowerShell |
|
Infrastructure-as-code |
Yes — Terraform provider |
Yes — ARM, Bicep, Terraform |
|
Admin access control |
Owner/Admin/Member roles |
Governed by Azure RBAC |
Zero Trust & Identity |
||
|
Capability |
CloudConnexa |
Azure VPN Gateway (P2S) |
|---|---|---|
|
Access granularity |
Application and destination CIDR + Access Groups (app-level) |
Network/route-level; no app-level ZTNA (Entra Private Access [6] is separate) |
|
Zero-trust access model |
Zero Trust Application Broker in CloudConnexa continuously verifies identity, location context, and device posture, then assigns a synthetic intermediate IP scoped to a single authorized app. The device never receives a route to the private network, making lateral movement structurally impossible. Access Groups control access to destination applications and IP services based on source identity. They include network-to-application and network-to-network access control. |
Network/route-level; no app-level ZTNA (Entra Private Access [6] is separate) |
|
User authentication |
Local username/password, LDAP, SAML 2.0, Certificate |
Certificate, Microsoft Entra ID, RADIUS/AD; no local user database |
|
Simultaneous IdP + local auth |
Yes — SAML and local accounts usable at the same time (not available in all plans). |
Partial — a gateway enables a subset of {Entra, RADIUS, certificate}; no local user database; single Entra app |
|
Multiple group membership per user |
Yes — one Primary plus up to 20 Secondary user groups (additive) |
Yes — Entra group assignment (direct membership only; no nested groups) |
|
MFA |
Built-in 2FA; passkey / passwordless. Delegated to IdP when SAML is used. |
Via Entra Conditional Access [3] (separate Azure/Microsoft service) |
|
Device posture / compliance |
Yes — OS, antivirus, disk encryption, certificate |
Via Entra Conditional Access [3] + Intune [4] compliance (separate Azure/Microsoft service) |
|
Location / geo context |
Yes — allow/block by IP range or country |
Via Entra Conditional Access named locations (Entra auth only) (separate Azure/Microsoft service) |
|
SCIM provisioning |
Yes — SCIM 2.0 (not available in all plans) |
No native SCIM (lifecycle handled in Entra ID) |
|
Service / non-human identity |
Host Connectors; REST API (OAuth client credentials), Certificate (mutual TLS) |
Partial — certificate-based machine authentication |
|
Device / supply-chain trust |
Device Identity Verification & Enforcement (locks profile to device) |
Via Entra Conditional Access (compliant/joined devices) and per-device certificate (separate Azure/Microsoft service) |
Access Use Cases |
||
|
Capability |
CloudConnexa |
Azure VPN Gateway (P2S) |
|---|---|---|
|
Remote access |
Yes — core use case |
Yes — Point-to-Site is the primary remote-access feature |
|
Site-to-site |
Yes — via Network Connectors (IPsec or OpenVPN) |
Yes — Site-to-Site IPsec; VNet-to-VNet |
|
Access to cloud / on-prem |
Cloud Connectors into AWS/Azure/GCP |
VNet resources; on-prem via transit over Site-to-Site |
|
Internet gateway / egress |
Yes — any Network as Internet Gateway; smart geo routing |
No native internet breakout; forced tunneling needs an NVA/Azure Firewall [2] (separate Azure/Microsoft service) |
|
Selective SaaS routing by domain (split tunnel on) |
Yes — route specific SaaS domains through a chosen Internet Gateway with split tunnel on (no full tunnel required) |
Partial — split/forced tunnel routes by route/CIDR, not by domain |
|
Vendor-provided static egress IP |
No — the customer runs the Internet Gateway and supplies the public IP |
No — customer-provided IP via a separate Azure NAT gateway / firewall (with forced tunneling) |
|
Split tunneling |
Yes — Split Tunnel On/Off and Restricted Internet |
Yes — default split tunnel; forced tunnel configurable |
|
Application-level ZTNA |
Yes — per-application Access Groups |
No — via Microsoft Entra Private Access [6] (separate Azure/Microsoft service) |
Networking |
||
|
Capability |
CloudConnexa |
Azure VPN Gateway (P2S) |
|---|---|---|
|
Client/device protocol |
OpenVPN only; OpenVPN Data Channel Offload (DCO) for throughput |
OpenVPN (SSL/TLS), IKEv2, SSTP (Windows-only, deprecating) |
|
WireGuard |
No — not supported for any connection type |
No — not supported |
|
Auth–protocol coupling |
IdP/SAML works across the OpenVPN client |
Entra ID auth requires the OpenVPN protocol; SSTP/IKEv2 alone cannot use Entra ID |
|
Site-to-site protocol |
IPsec or OpenVPN (Network Connectors) |
IPsec / IKE (route-based or policy-based) |
|
DNS |
Yes — DNS Proxy, custom records/zones, custom DNS servers |
Custom DNS servers and suffixes via client profile |
|
Overlapping-IP / domain routing |
Yes — domain-based routing handles overlapping IPs |
No – Route/CIDR-based; custom routes advertised to clients |
Secure Internet Access |
||
|
Capability |
CloudConnexa |
Azure VPN Gateway (P2S) |
|---|---|---|
|
Content / URL filtering |
Yes — Cyber Shield Domain Filtering, 43 categories; included |
No native — Azure Firewall [2] / Entra Internet Access [5] (separate Azure/Microsoft service) |
|
DNS filtering |
Yes — DNS Proxy + Domain Filtering |
No native — separate Microsoft service |
|
IDS / IPS |
Yes — Cyber Shield Traffic Filtering (monitor/block) |
No native — Azure Firewall Premium [2] (separate Azure/Microsoft service) |
|
Malware / threat protection |
Yes — domain-level malware, ransomware, C2, phishing, more |
No native — Azure Firewall Premium [2] / NVA (separate Azure/Microsoft service) |
|
CASB / SaaS security |
Not offered (SaaS access can be restricted to an Internet Gateway egress IP) |
Not offered (separate Microsoft services, e.g. Entra Internet Access [5]) |
Observability & Operations |
||
|
Capability |
CloudConnexa |
Azure VPN Gateway (P2S) |
|---|---|---|
|
Diagnostic / connection logging |
Yes — A wide variety of logs in addition to basic connection logs. |
Yes — P2S/Gateway/Tunnel/Route/IKE diagnostic logs |
|
Audit logging |
Yes — Audit Log of config changes |
Yes — Azure Activity Log (control-plane actions) |
|
Metrics / monitoring |
Cyber Shield and Status dashboards |
Yes — Azure Monitor metrics; packet capture |
|
SIEM / log export |
Yes — JSON streaming to AWS S3; Splunk, Datadog |
Diagnostic settings to Log Analytics / Event Hub; Microsoft Sentinel |
|
Network flow logs |
DNS Log and access flows |
NSG flow logs via Network Watcher |
Reference: Azure / Microsoft named services
The Azure comparison references several separate Microsoft services by name. The numbers below are referenced in the comparison tables above (e.g. "Virtual WAN [1]"). Each entry summarizes the function and the closest equivalent in CloudConnexa.
|
Service |
What it does |
CloudConnexa equivalent |
|---|---|---|
|
Azure's hub-and-spoke network-as-a-service for large-scale site connectivity. |
The full-mesh WPC overlay. |
| 2. Azure Firewall (Premium) |
A managed firewall with IDS/IPS and filtering — a separate, separately-priced service. |
Cyber Shield (IDS/IPS plus content filtering) is built in. |
| 3. Conditional Access |
Microsoft Entra ID's policy engine enforcing MFA and device / risk conditions. |
Built-in MFA plus device posture and location-context policies. |
| 4. Intune |
Microsoft's MDM / compliance service providing device-compliance signals. |
Native device posture policies. |
| 5. Entra Internet Access |
Microsoft's separate SSE / secure-web-gateway product. |
Built-in secure internet access (DNS / content filtering, IDS/IPS). |
| 6. Entra Private Access |
Microsoft's separate application-level ZTNA product. |
Application-level access via Access Groups, built into the service. |
Frequently asked questions
What's the difference between Azure VPN Gateway Point-to-Site and Site-to-Site VPN?
Point-to-Site connects individual client devices into a VNet over an encrypted tunnel; Site-to-Site connects two networks — for example, an on-prem site and Azure — through a VPN device or another gateway. CloudConnexa supports both patterns natively: device access through the OpenVPN Connect client, and network-to-network access through its Network Connector, within the same platform.
Does Azure VPN Gateway support Zero Trust access control?
Not on its own. Azure VPN Gateway grants network- and route-level access into a VNet; application-level Zero Trust controls — device compliance, Conditional Access policies, per-app access — come from the separate Microsoft Entra Private Access product layered on top. CloudConnexa applies Zero Trust controls — identity, device posture, and location context — natively at the platform level.
How much does Azure VPN Gateway cost?
Pricing is based on the gateway SKU you provision — Basic through VpnGw5, plus zone-redundant variants — billed per hour regardless of how much of that SKU's connection capacity you're actually using, plus data-transfer charges. CloudConnexa pricing scales by connections and regions rather than a fixed hourly gateway tier.
Can Azure VPN Gateway connect users to networks outside Azure?
Only indirectly. The gateway itself terminates connections into one Azure VNet and region; reaching other clouds or on-prem networks means peering VNets, building an Azure Virtual WAN hub, or standing up additional gateways elsewhere. CloudConnexa's WPC model is multi-cloud and multi-region by default — the same overlay and access policies reach AWS, Azure, GCP, and on-prem networks through Connectors.
Is there a multi-cloud alternative to Azure VPN Gateway?
Yes. CloudConnexa is built as a vendor-operated overlay spanning multiple clouds and regions rather than living inside a single VNet, so the same access policies and Connectors work whether the network you're reaching is in Azure, AWS, GCP, or on-prem. For a fully self-hosted option that still deploys directly into your VNet, OpenVPN Access Server is also available through the Azure Marketplace.
Does Azure VPN Gateway include content filtering or intrusion detection?
No. Azure VPN Gateway is a connectivity service; filtering and threat detection require separate products such as Azure Firewall or Microsoft Entra Internet Access. CloudConnexa includes both through its built-in Cyber Shield.
What happens to Azure VPN Gateway P2S connections when SSTP retires?
Existing SSTP-enabled gateways stop accepting SSTP connections on the timeline Microsoft has published; the OpenVPN protocol and IKEv2 keep working throughout. If you're specifically navigating that migration, see our full breakdown of what changes — and why a tunnel-type switch alone may not solve the underlying connection-scaling limits.
Does Azure VPN Gateway support WireGuard?
No. Azure VPN Gateway Point-to-Site supports the OpenVPN protocol, IKEv2, and SSTP — WireGuard isn't among its supported protocols.
Secure your network now.
If your team is weighing a VNet-bound gateway against a platform built for multi-cloud Zero Trust from the ground up, see how CloudConnexa fits your environment.