Zero-Trust Private Network Access Platform
A reusable, shared “hub” networking platform so any internal team can privately connect Azure PaaS resources to a corporate VPN, without each team building its own DNS/peering plumbing from scratch.
Project Brief
- Role
- Network architecture and rollout owner
- Scope
- A reusable private-access hub designed for multiple subscriptions, environments, and Azure PaaS consumers
- Collaboration
- Cloud platform, security, VPN/networking, and service-owner stakeholders
- Result
- A repeatable onboarding path that makes sensitive services unreachable from the public internet without rebuilding DNS and peering for every team
Evidence Included
Hub-and-spoke topology
A sanitized architecture diagram shows the VPN, peering, DNS resolver, private endpoint, and service boundaries.
Three traffic flows
VPN resolution, public-client denial, and reusable service onboarding are documented as explicit sequences.
Reference implementation details
The page includes a component matrix and an illustrative, non-production addressing plan.
3-phase: throwaway → low-risk → prod
Rollout model
1, reused org-wide
Shared network hubs built
Zero — connection-refused by default
Public exposure
The Problem
Cloud data platforms and internal services were reachable over the public internet by default, gated only by login. Security requirements moved to a stronger posture: sensitive workspaces should be unreachable at the network layer unless the client is on the corporate VPN — a public request should get connection-refused, not a login page. Doing this one service at a time would mean re-solving the same DNS/peering/routing problem repeatedly.
My Approach
- Designed a single shared hub virtual network, peered once into the existing VPN termination point, with dedicated subnets carved out per target environment/subscription for Private Endpoints — so onboarding a new service means “add a Private Endpoint in the right subnet,” not “build new network plumbing.”
- Deployed a DNS Private Resolver (inbound + outbound endpoints) so VPN clients resolve private service names to internal IPs automatically, while everything else still forwards to public DNS — no per-service DNS reconfiguration needed on the client side.
- Centralized Private DNS Zone management in the hub, linked once, reused by every consuming service.
- Used a phased, risk-managed rollout: proved the entire pattern end-to-end on a disposable/throwaway workspace first, validated it a second time on a low-blast-radius real workspace, and only then applied the proven playbook to the actual production target.
- Documented prerequisites and platform gotchas discovered along the way (subnet/NSG ordering requirements, RBAC scope needed for cross-subscription DNS zone links, compute that must be stopped before a network-access-mode change) so the next team doesn't rediscover them the hard way.
Architecture Diagram
Zero-Trust Private Access Topology
Client
VPN Client
Cisco AnyConnect
VPN Concentrator
Meraki vMX
VPN termination
Network Hub
Existing Hub VNet
Pre-existing VPN hub
Private Link Hub VNet
New, shared, peered
DNS + Private Endpoints
DNS Private Resolver
Inbound + outbound
Private Endpoint Subnets
Per environment (A/B/C)
Destination
Private DNS Zones
privatelink.* → private IP
Databricks + PaaS
VNet-injected, no public IP
Public DNS
Fallback for normal traffic
Access Governance → feeds into “Private Link Hub VNet”
Azure RBAC
Private DNS Zone Contributor
Every consuming service reuses the same hub — onboarding a new one means adding a Private Endpoint in the right subnet, not new network plumbing.
Traffic Flow & Methodology
Private Access Flow
- 1A user connects over Cisco AnyConnect to the Cisco Meraki vMX VPN concentrator, landing on the existing network hub.
- 2The hub VNet is peered (intra-subscription VNet Peering) to the new, shared Private Link Hub VNet — built once, reused by every onboarding service.
- 3All VPN client DNS queries are routed to the Azure DNS Private Resolver's inbound endpoint.
- 4If the query matches a Private DNS Zone linked to the hub, it resolves to the private IP address of a Private Endpoint inside the hub — traffic to that service never leaves the private network.
- 5If the query doesn't match a private zone, the resolver's outbound endpoint and forwarding ruleset send it to public DNS as a fallback — no special handling needed for normal internet traffic.
- 6Each consuming service gets its own Private Endpoint subnet inside the hub, scoped per target subscription/environment, so a Private Endpoint can target a resource in any subscription without a new peering.
First Consumer Example — Azure Databricks
- 1The first service locked down via this platform was an Azure Databricks workspace.
- 2Required prerequisites: VNet injection (the workspace's clusters live in a customer-managed VNet) and Secure Cluster Connectivity (No Public IP).
- 3Once those prerequisites are met, the workspace's public network access is disabled entirely and a Private Endpoint is created in the hub — so the workspace URL only resolves and connects for clients on the VPN, through the private DNS path above.
Component & Technology Reference
| Layer | Technology | Role |
|---|---|---|
| VPN Client | Cisco AnyConnect | Client-to-site VPN software |
| VPN Concentrator | Cisco Meraki vMX | Terminates VPN connections into the network hub |
| Network Hub | Azure Virtual Network (pre-existing) | Existing VPN-connected network hub |
| Shared Platform | Azure Virtual Network (Private Link Hub, new) | Centralized, reusable hub for all Private Endpoints |
| Connectivity | Azure VNet Peering (intra- and cross-subscription) | Connects the VPN hub to the Private Link hub, and the hub to consumer subscriptions |
| Private Connectivity | Azure Private Link / Private Endpoints | Gives PaaS resources a private IP reachable only from the hub/VPN |
| DNS Resolution | Azure DNS Private Resolver (Inbound + Outbound) | Routes VPN client DNS queries to private or public resolution paths |
| DNS Records | Azure Private DNS Zones (privatelink.*) | Maps service hostnames to Private Endpoint IPs |
| DNS Fallback | Forwarding Ruleset (default rule) → Public DNS | Ensures normal internet DNS still works for VPN clients |
| First Consumer | Azure Databricks (VNet Injection + Secure Cluster Connectivity) | Workspace locked to VPN-only access via the hub |
| Access Governance | Azure RBAC (Private DNS Zone Contributor) | Least-privilege control over shared DNS/network resources |
Illustrative Addressing Scheme
| Component | Example CIDR | Purpose |
|---|---|---|
| Private Link Hub VNet | 10.100.0.0/20 | Overall hub address space |
| Private Endpoint Subnet — Env A | 10.100.0.0/24 | PEs targeting Environment A resources |
| Private Endpoint Subnet — Env B | 10.100.1.0/24 | PEs targeting Environment B resources |
| Private Endpoint Subnet — Env C | 10.100.2.0/24 | PEs targeting Environment C resources |
| DNS Private Resolver — Inbound | 10.100.4.0/28 | Resolver inbound endpoint subnet |
| DNS Private Resolver — Outbound | 10.100.4.16/28 | Resolver outbound endpoint subnet |
Illustrative addressing scheme — example ranges, not real production values.
Stack
Networking
Identity/Access
Data Platform Integration
Practices
Skills Demonstrated
- ▸Zero-trust network architecture at an enterprise, multi-subscription scale
- ▸DNS architecture for hybrid VPN + cloud environments
- ▸Security-first infrastructure design — treating “public until proven private” as the wrong default
- ▸Risk-managed rollout planning (throwaway → low-risk real target → production), not big-bang changes
- ▸Clear technical documentation of platform prerequisites for other teams to self-serve