Executive Summary

Architected a secure hybrid cloud connectivity platform on Microsoft Azure integrating Azure VPN Gateway Point-to-Site (P2S) connectivity with Azure AD authentication, MFA enforcement, hub-based network segmentation, Azure Firewall layered security, and Terraform Infrastructure-as-Code automation.

The architecture enables distributed administrators and developers to access private Azure workloads securely through Azure AD-authenticated VPN sessions — without exposing any workload VM to public IP addresses or open management ports — aligning remote access governance with Zero Trust identity-first principles.

The design addresses the specific technical challenges of P2S VPN architecture: Azure AD authentication flow integration, OpenVPN tunnel protocol configuration, split tunnelling policy design, client address pool planning, and MFA enforcement through Conditional Access — elements that distinguish a P2S connectivity architecture from generic hub-spoke network designs.

Business Drivers

Organisations adopting hybrid cloud models require secure remote access for administrators, developers, and operational teams who need private access to Azure-hosted workloads from distributed locations. Legacy approaches — public IP addresses on VMs, open RDP/SSH ports, or site-to-site VPN dependent on on-premises infrastructure — each introduce security exposure, operational overhead, or connectivity constraints that P2S VPN resolves.

This architecture was designed to address the secure remote access requirements of organisations where existing approaches result in:

• Public VM exposure creating persistent attack surface — open RDP and SSH ports accessible to automated scanners and brute-force tools continuously

• Site-to-site VPN dependency requiring on-premises infrastructure — not viable for organisations without existing on-premises VPN appliances or for fully cloud-native teams

• Certificate-based P2S VPN lacking MFA enforcement — individual certificate compromise provides VPN access without additional authentication factor

• Manual infrastructure provisioning creating configuration drift between environments

• Limited operational visibility into VPN connectivity health, authentication events, and network traffic flows

Operational Constraints

The architecture was designed to operate within the following constraints typical of distributed cloud operations teams:

• Workload VMs must have no public IP addresses — all access must flow through VPN-governed private connectivity

• Remote access must support distributed users without on-premises infrastructure dependency — P2S rather than S2S VPN

• VPN authentication must enforce MFA — password-only VPN authentication is not acceptable

• VPN client configuration must be distributable to users without complex manual setup — Azure VPN Client with Azure AD authentication simplifies distribution

• Split tunnelling policy must balance security governance against operational usability — full tunnelling for all traffic may create unacceptable latency for non-Azure traffic

• Infrastructure must be consistently deployable across development and production environments through Terraform

• Administrative access to VMs must not require open management ports — jumpbox model providing intermediate access control

Objectives

• Design a P2S VPN Gateway architecture with Azure AD authentication and MFA enforcement through Conditional Access

• Select appropriate VPN Gateway SKU, tunnel protocol, and client address pool for the target user population

• Define split tunnelling policy balancing Azure traffic governance against non-Azure traffic performance

• Implement hub-based network segmentation isolating VPN gateway, workloads, and administrative access

• Deploy Azure Firewall for centralised traffic inspection across hub-and-spoke flows

• Eliminate all public IP exposure from workload VMs — private access only through VPN-governed connectivity

• Implement jumpbox-based administrative access model as an intermediate step before full Azure Bastion adoption

• Automate infrastructure deployment through Terraform with remote state management

• Centralise operational monitoring including VPN connection logs, authentication events, and NSG flow logs

P2S VPN Technical Architecture

VPN Gateway Configuration

Gateway SKU Selection:

This architecture uses VpnGw2 — supporting up to 500 concurrent P2S connections with 1 Gbps aggregate throughput, appropriate for a mid-sized distributed operations team. Gateway SKU selection must be validated against the maximum expected concurrent VPN session count — SKU upgrades require gateway recreation.

Tunnel Protocol Selection — OpenVPN:

OpenVPN is the only protocol supporting Azure AD authentication with MFA enforcement — making it the required protocol choice for this architecture. IKEv2 and SSTP provide only certificate-based authentication without MFA capability.

Client Address Pool:

• P2S client address pool: 172.16.0.0/24 — providing 254 client IP addresses

• Pool CIDR must not overlap with any Azure VNet address space or on-premises network ranges

• Each connected VPN client receives a unique IP from this pool — used for NSG and firewall rule targeting if required

Azure AD Authentication & MFA Integration

Authentication Flow:

1. User opens Azure VPN Client
2. Azure VPN Client initiates OpenVPN connection to VPN Gateway
3. VPN Gateway redirects authentication to Microsoft Entra ID
4. User authenticates with Entra ID credentials
5. Conditional Access evaluates: MFA required, device compliance (optional), risk level
6. MFA challenge presented — Authenticator app, SMS, or hardware token
7. MFA satisfied → Entra ID issues authentication token
8. VPN Gateway validates token → OpenVPN tunnel established
9. User receives P2S client IP from client address pool
10. User can now reach private workloads through VPN tunnel

1. User opens Azure VPN Client
2. Azure VPN Client initiates OpenVPN connection to VPN Gateway
3. VPN Gateway redirects authentication to Microsoft Entra ID
4. User authenticates with Entra ID credentials
5. Conditional Access evaluates: MFA required, device compliance (optional), risk level
6. MFA challenge presented — Authenticator app, SMS, or hardware token
7. MFA satisfied → Entra ID issues authentication token
8. VPN Gateway validates token → OpenVPN tunnel established
9. User receives P2S client IP from client address pool
10. User can now reach private workloads through VPN tunnel

1. User opens Azure VPN Client
2. Azure VPN Client initiates OpenVPN connection to VPN Gateway
3. VPN Gateway redirects authentication to Microsoft Entra ID
4. User authenticates with Entra ID credentials
5. Conditional Access evaluates: MFA required, device compliance (optional), risk level
6. MFA challenge presented — Authenticator app, SMS, or hardware token
7. MFA satisfied → Entra ID issues authentication token
8. VPN Gateway validates token → OpenVPN tunnel established
9. User receives P2S client IP from client address pool
10. User can now reach private workloads through VPN tunnel

Conditional Access Policy for VPN:

The Azure VPN enterprise application must be registered in Entra ID and the Conditional Access policy scoped to this application — ensuring MFA enforcement applies specifically to VPN authentication events.

Split Tunnelling Architecture

Split tunnelling defines which traffic routes through the VPN tunnel versus directly to the internet from the client device — a significant security and performance architectural decision.

Split Tunnelling — Azure-Bound Traffic Only (Selected):

• Traffic destined for Azure VNet address spaces routes through the VPN tunnel

• All other traffic (internet browsing, SaaS applications) routes directly from the client device

• Lower latency for non-Azure internet traffic — not backhauled through Azure

• Reduced VPN Gateway bandwidth consumption — only Azure-bound traffic transits the tunnel

• Security consideration: client device internet traffic is not governed by Azure Firewall

Full Tunnelling Alternative — All Traffic Through VPN:

• All client device traffic routes through the VPN tunnel and exits through Azure

• Azure Firewall can govern all client internet traffic for security policy enforcement

• Higher latency for internet traffic — all traffic backhauled through Azure before reaching internet destinations

• Higher VPN Gateway bandwidth consumption — all client traffic transits the gateway

Decision Rationale: Split tunnelling is selected for this architecture — Azure-bound traffic is the operational requirement for remote access. Full tunnelling operational overhead (latency, bandwidth, gateway capacity) is not justified unless client internet traffic governance is an explicit security requirement. If regulatory requirements mandate internet traffic inspection for all remote workers, full tunnelling with Azure Firewall FQDN-based filtering should be reconsidered.

Architecture Overview

The solution is structured as a six-layer hub-based hybrid connectivity platform integrating secure VPN access, hub network governance, workload isolation, administrative access control, infrastructure automation, and centralised monitoring.

1. Hub Network Layer — Connectivity Control Plane

The hub VNet (vnet-hub) serves as the centralised connectivity and security governance layer — hosting the VPN Gateway, Azure Firewall, and shared security services.

Hub VNet Subnet Architecture:

VNet Address Space Planning:

Routing Architecture:

• User-Defined Routes (UDRs) in workload spoke subnets forcing default route through Azure Firewall private IP

• VPN client traffic entering through GatewaySubnet routes to workload spoke through VNet peering

• Azure Firewall inspects traffic between VPN clients and workload VMs — all VPN-to-workload traffic is logged

2. Workload Layer — Private VM Hosting

The workload subnet (vnet-workloads) hosts enterprise VMs with private IP addresses only — no public IP assignment permitted.

VM Configuration:

• Windows Server 2022 and Red Hat Enterprise Linux (RHEL) workload VMs

• No public IP addresses — VMs reachable only through VPN tunnel

• NSG applied at subnet level — inbound RDP (3389) and SSH (22) permitted only from JumpboxSubnet IP range

• Outbound internet access through Azure Firewall with application rule filtering

No Public IP Enforcement: Azure Policy assignment denying public IP association to VMs in the workload resource group — preventing accidental public exposure even through manual portal operations.

3. Jumpbox Access Layer

The jumpbox model provides an intermediate administrative access control point — administrators VPN into the hub network, then connect to the jumpbox, then connect from the jumpbox to workload VMs.

Jumpbox Architecture:

Remote Administrator
      ↓ Azure AD-authenticated OpenVPN P2S
VPN Gateway (hub)
      ↓ Private connectivity through hub VNet
Jumpbox VM (JumpboxSubnet)
      ↓ RDP/SSH from jumpbox private IP
Workload VMs (vnet-workloads)

Remote Administrator
      ↓ Azure AD-authenticated OpenVPN P2S
VPN Gateway (hub)
      ↓ Private connectivity through hub VNet
Jumpbox VM (JumpboxSubnet)
      ↓ RDP/SSH from jumpbox private IP
Workload VMs (vnet-workloads)

Remote Administrator
      ↓ Azure AD-authenticated OpenVPN P2S
VPN Gateway (hub)
      ↓ Private connectivity through hub VNet
Jumpbox VM (JumpboxSubnet)
      ↓ RDP/SSH from jumpbox private IP
Workload VMs (vnet-workloads)

Jumpbox Security Controls:

• Jumpbox VMs have no public IP — accessible only from VPN client addresses

• NSG on JumpboxSubnet permitting inbound RDP/SSH from P2S client address pool only (172.16.0.0/24)

• NSG on workload subnet permitting inbound RDP/SSH from JumpboxSubnet CIDR only

• Workload VMs unreachable directly from VPN client IPs — must transit through jumpbox

Jumpbox vs Azure Bastion Trade-off: The jumpbox model requires ongoing VM management — OS patching, security hardening, availability, and cost for always-running VMs. Azure Bastion provides equivalent administrative access as a PaaS service without VM management overhead. This architecture uses jumpbox VMs as an interim model — Azure Bastion migration is the recommended future evolution. The decision to use jumpbox VMs reflects the specific constraint of environments where Azure Bastion Standard SKU cost is not yet approved, or where legacy administrative tooling requires full RDP session capability that Bastion's browser-based model may not fully replicate.

4. Identity & Access Governance Layer

Identity governance integrates Azure AD authentication across VPN access and VM-level administrative operations.

Azure AD P2S Authentication:

• Azure VPN Client distributed to all remote users — downloadable from Microsoft or deployable through Intune

• VPN profile XML downloaded from Azure Portal and imported into Azure VPN Client — no manual VPN configuration required

• Entra ID Conditional Access enforcing MFA for every VPN session initiation

• VPN session tokens expire after configured lifetime — re-authentication required for new sessions

Azure RBAC — Infrastructure Governance:

• Infrastructure Contributor: Terraform service connection and platform engineers managing hub network resources

• VM Operator: operations team managing workload VMs without network or VPN gateway access

• Network Reader: security team read-only access to network configuration and firewall logs

• Jumpbox User: specific security group granting RDP/SSH access to jumpbox VMs

5. Infrastructure Automation Layer

Terraform manages all hub connectivity infrastructure through modular, environment-parameterised configurations.

Connectivity-Specific Terraform Modules:

modules/
├── vpn-gateway/          # VPN Gateway, client address pool, Azure AD auth config
├── hub-network/          # Hub VNet, subnets, UDRs, VNet peering
├── azure-firewall/       # Firewall, policy, application/network rules
├── jumpbox/              # Jumpbox VMs, NSGs, extensions
└── monitoring/           # Log Analytics, diagnostic settings, alerts

modules/
├── vpn-gateway/          # VPN Gateway, client address pool, Azure AD auth config
├── hub-network/          # Hub VNet, subnets, UDRs, VNet peering
├── azure-firewall/       # Firewall, policy, application/network rules
├── jumpbox/              # Jumpbox VMs, NSGs, extensions
└── monitoring/           # Log Analytics, diagnostic settings, alerts

modules/
├── vpn-gateway/          # VPN Gateway, client address pool, Azure AD auth config
├── hub-network/          # Hub VNet, subnets, UDRs, VNet peering
├── azure-firewall/       # Firewall, policy, application/network rules
├── jumpbox/              # Jumpbox VMs, NSGs, extensions
└── monitoring/           # Log Analytics, diagnostic settings, alerts

VPN Gateway Terraform Resource:

hcl

resource "azurerm_virtual_network_gateway" "vpn" {
  name                = "vpn-gateway-${var.environment}"
  type                = "Vpn"
  vpn_type            = "RouteBased"
  sku                 = "VpnGw2"
  generation          = "Generation2"

  vpn_client_configuration {
    address_space         = ["172.16.0.0/24"]
    vpn_client_protocols  = ["OpenVPN"]
    vpn_auth_types        = ["AAD"]
    aad_tenant            = "https://login.microsoftonline.com/${var.tenant_id}/"
    aad_audience          = "41b23e61-6c1e-4545-b367-cd054e0ed4b4"  # Azure VPN app ID
    aad_issuer            = "https://sts.windows.net/${var.tenant_id}/"
  }
}

resource "azurerm_virtual_network_gateway" "vpn" {
  name                = "vpn-gateway-${var.environment}"
  type                = "Vpn"
  vpn_type            = "RouteBased"
  sku                 = "VpnGw2"
  generation          = "Generation2"

  vpn_client_configuration {
    address_space         = ["172.16.0.0/24"]
    vpn_client_protocols  = ["OpenVPN"]
    vpn_auth_types        = ["AAD"]
    aad_tenant            = "https://login.microsoftonline.com/${var.tenant_id}/"
    aad_audience          = "41b23e61-6c1e-4545-b367-cd054e0ed4b4"  # Azure VPN app ID
    aad_issuer            = "https://sts.windows.net/${var.tenant_id}/"
  }
}

resource "azurerm_virtual_network_gateway" "vpn" {
  name                = "vpn-gateway-${var.environment}"
  type                = "Vpn"
  vpn_type            = "RouteBased"
  sku                 = "VpnGw2"
  generation          = "Generation2"

  vpn_client_configuration {
    address_space         = ["172.16.0.0/24"]
    vpn_client_protocols  = ["OpenVPN"]
    vpn_auth_types        = ["AAD"]
    aad_tenant            = "https://login.microsoftonline.com/${var.tenant_id}/"
    aad_audience          = "41b23e61-6c1e-4545-b367-cd054e0ed4b4"  # Azure VPN app ID
    aad_issuer            = "https://sts.windows.net/${var.tenant_id}/"
  }
}

Terraform Import for Existing Resources: Pre-existing Azure resources deployed manually before IaC adoption are imported through terraform import workflows — bringing hub network components, existing NSGs, and firewall policies under Terraform state governance without requiring recreation.

6. Monitoring & Observability Layer

Centralised monitoring provides operational visibility across VPN connectivity, authentication events, network traffic, and workload health.

VPN Connectivity Monitoring:

• Azure VPN Gateway diagnostic logs forwarded to Log Analytics — tunnel connection events, client connection/disconnection, authentication failures

• Alert rules for VPN Gateway health degradation and tunnel count anomalies

• P2S connection count monitoring — alerting when connection count approaches SKU limit (500 for VpnGw2)

Authentication Event Monitoring:

• Entra ID sign-in logs for the Azure VPN enterprise application — VPN authentication successes, MFA completions, and Conditional Access policy failures

• Alert rules for repeated VPN authentication failures indicating potential credential attack attempts

Network Traffic Monitoring:

• NSG flow logs on JumpboxSubnet and workload subnets — providing visibility into connection patterns between VPN clients, jumpbox, and workload VMs

• Azure Firewall diagnostic logs — traffic flow visibility for all hub-to-spoke and VPN client traffic passing through firewall inspection

Workload Health Monitoring:

• VM performance metrics through Azure Monitor — CPU, memory, disk, and network utilisation for all workload VMs

• Log Analytics agent on all VMs forwarding Windows Event Logs and Linux Syslog for operational diagnostics

Architecture Diagram

Technologies Used

Key Challenges Addressed

Designing secure access without exposing public endpoints — addressed through P2S VPN Gateway providing private connectivity to Azure workloads without any public IP on workload VMs — remote users access resources through authenticated VPN sessions only.

Integrating Azure AD authentication with P2S VPN — addressed through OpenVPN protocol selection (the only Azure P2S protocol supporting Azure AD authentication) with Conditional Access MFA enforcement — certificate-based P2S authentication cannot enforce MFA per-user through Conditional Access.

Managing Terraform state alongside pre-existing resources — addressed through terraform import workflows bringing existing Azure resources under IaC governance without requiring recreation — a critical operational challenge for realistic IaC adoption in environments with existing infrastructure.

Balancing security controls with operational usability — addressed through split tunnelling limiting VPN tunnel to Azure-bound traffic — reducing latency for internet-bound traffic while maintaining governance over Azure resource access.

Achieving observability across VPN connectivity and authentication — addressed through diagnostic log integration covering VPN Gateway tunnel events, Entra ID sign-in logs for VPN authentication, NSG flow logs, and firewall traffic logs — providing correlated visibility across all connectivity layers.

Design Decisions & Rationale

Point-to-Site over Site-to-Site VPN : Site-to-Site VPN requires on-premises VPN appliance infrastructure — not viable for organisations without existing on-premises infrastructure or for fully cloud-native operations teams. P2S VPN enables individual user connectivity directly to Azure without on-premises infrastructure dependency — appropriate for distributed teams, remote developers, and cloud-native operations models.

Azure AD Authentication over Certificate-Based P2S : Certificate-based P2S authentication cannot enforce MFA through Conditional Access — certificate compromise provides VPN access without additional authentication challenge. Azure AD authentication integrates VPN access into Entra ID Conditional Access — enabling MFA enforcement, sign-in risk evaluation, and device compliance validation for every VPN session. Azure AD authentication is the only P2S model that supports Zero Trust identity-first access principles.

OpenVPN over IKEv2 and SSTP : IKEv2 and SSTP support only certificate-based authentication — incompatible with Azure AD P2S authentication. OpenVPN is the required protocol for Azure AD authentication support and additionally provides cross-platform client support (Windows, macOS, Linux, iOS, Android) without protocol limitations.

Split Tunnelling — Azure Traffic Only : Full tunnelling routes all client internet traffic through Azure — increasing VPN Gateway bandwidth consumption, adding latency for internet-bound traffic, and requiring Azure Firewall capacity for all remote user internet traffic. Split tunnelling limits VPN tunnel to Azure-bound traffic — operationally appropriate when the access requirement is Azure workload connectivity, not internet traffic governance. If regulatory requirements mandate all remote worker internet traffic inspection, full tunnelling with Azure Firewall FQDN filtering should be evaluated despite the operational cost increase.

Jumpbox over Azure Bastion (Interim) : Azure Bastion provides browser-based RDP/SSH without jumpbox VM management overhead — the architecturally preferred long-term model. Jumpbox VMs are used in this architecture as an interim approach where Bastion Standard SKU cost has not been approved or where legacy administrative tooling requires full RDP session capability. The jumpbox provides equivalent security isolation at higher operational cost — migration to Bastion is the planned evolution as budget and tooling constraints are resolved.

Hub-Based Network Architecture : Flat VNet architecture without hub-spoke segmentation places VPN Gateway, workload VMs, and administrative access on the same network layer — creating lateral movement risk if any component is compromised. Hub-spoke architecture isolates VPN Gateway in the hub, workloads in spoke VNets, and routes all inter-layer traffic through Azure Firewall inspection — providing defence-in-depth that flat networks cannot achieve.

Trade-offs & Design Constraints

VPN Gateway SKU Lock-in : Azure VPN Gateway SKU selection is not easily changed post-deployment — SKU upgrades require gateway recreation which disrupts active VPN sessions. Gateway SKU must be validated against maximum expected concurrent P2S connections before deployment. VpnGw2 supporting 500 concurrent connections is appropriate for mid-sized teams — organisations approaching this limit must plan gateway recreation during a maintenance window rather than performing a live SKU upgrade.

OpenVPN Protocol UDP vs TCP Trade-off : OpenVPN over UDP (port 1194) provides better performance — lower latency and higher throughput for VPN tunnel traffic. OpenVPN over TCP (port 443) provides better firewall traversal — TCP 443 is universally permitted through corporate firewalls and proxy servers. Azure P2S VPN supports both — the default Azure VPN Client configuration uses TCP 443 for maximum compatibility. Environments with reliable network connectivity without restrictive outbound firewall policies may benefit from UDP configuration for improved performance.

Split Tunnelling Internet Traffic Governance Gap : Split tunnelling means remote user internet traffic bypasses Azure Firewall — corporate internet access policies cannot be enforced for VPN-connected remote workers through Azure Firewall alone. Organisations requiring internet traffic governance for remote workers must either implement full tunnelling (accepted latency trade-off), deploy endpoint-based web filtering (Defender for Endpoint web content filtering), or accept the governance gap for internet-bound traffic.

Jumpbox VM Operational Overhead : Jumpbox VMs require ongoing OS patching, security hardening, monitoring, and availability management — costs that Azure Bastion eliminates. In environments where Bastion migration is planned but not yet executed, jumpbox operational overhead accumulates. Jumpbox should be treated as a transitional model with a defined timeline for Bastion migration rather than a permanent architecture component.

P2S VPN Authentication Session Token Lifetime : Azure AD authentication tokens for P2S VPN sessions expire after configured lifetime — users must re-authenticate when tokens expire, disrupting active VPN sessions. Token lifetime configuration must balance security (shorter lifetimes reduce exposure window for compromised tokens) against operational disruption (frequent re-authentication interrupts administrative workflows). Recommended token lifetime of 1 hour for P2S VPN balances security and usability for typical administrative session durations.

Terraform VPN Gateway Deployment Time : Azure VPN Gateway deployment through Terraform takes approximately 25–45 minutes — significantly longer than most Azure resource deployments. CI/CD pipelines provisioning or modifying VPN Gateways must account for this deployment duration in pipeline timeout configuration and team expectation management.

Projected Outcomes

The architecture is designed to deliver the following operational and security outcomes in a production hybrid enterprise environment:

• Fully private Azure workload access — no public IP exposure on any workload VM or management interface

• MFA-secured VPN connectivity through Azure AD authentication with Conditional Access enforcement for every session

• Zero Trust-aligned remote access governance — identity and MFA verified before network access granted, regardless of client location

• Consistent infrastructure deployment through Terraform modular IaC with remote state governance

• Centralised operational visibility across VPN connectivity health, authentication events, and network traffic through Log Analytics

• Reduced attack surface through hub-based network segmentation isolating VPN gateway, workloads, and administrative access

• Repeatable and auditable infrastructure deployment through Azure DevOps pipelines with approval-gated production changes

Future Evolution

• Azure Bastion migration replacing jumpbox VMs — eliminating VM management overhead for administrative access while preserving private-only connectivity model

• ExpressRoute integration for enterprise-grade dedicated hybrid connectivity replacing P2S VPN for site-level access requirements

• Zero Trust Network Access (ZTNA) expansion through Entra Private Access — per-application access governance replacing full network VPN tunnel model

• Conditional Access device compliance enforcement for VPN — requiring Intune-compliant device state before VPN session establishment

• Policy-as-Code governance through Azure Policy and Checkov preventing non-compliant network configurations from reaching deployment

• Multi-region VPN Gateway deployment for geographic resilience — active-active gateway configuration for high-availability VPN connectivity

• Advanced network analytics through Azure Network Watcher for VPN tunnel diagnostics and connectivity troubleshooting automation

• AI-assisted infrastructure diagnostics through Azure Monitor intelligent alerting and anomaly detection for VPN connectivity patterns

Key Takeaways

• Azure AD authentication is the only P2S VPN model supporting MFA enforcement through Conditional Access — certificate-based P2S cannot enforce per-user MFA and should not be used where Zero Trust access governance is required

• OpenVPN is the required tunnel protocol for Azure AD P2S authentication — IKEv2 and SSTP support certificate authentication only

• Split tunnelling is operationally appropriate when the access requirement is Azure workload connectivity — full tunnelling introduces significant latency and bandwidth overhead that must be justified by explicit internet traffic governance requirements

• VPN Gateway SKU must be validated against maximum concurrent P2S connections before deployment — SKU upgrades require gateway recreation disrupting active sessions

• P2S VPN eliminates on-premises infrastructure dependency for remote access — appropriate for cloud-native teams and distributed operations without existing site-to-site connectivity

• Jumpbox VMs should be treated as a transitional model toward Azure Bastion — they provide equivalent security isolation at higher operational overhead that Bastion eliminates

• Hub-based network segmentation with Azure Firewall inspection of VPN-to-workload traffic is essential — flat networks placing VPN gateway and workloads on the same layer eliminate the security benefit of private-only workload exposure