Azure Forced Tunneling

Complete Implementation Guide with Traffic Flow Analysis

Overview of Azure Forced Tunneling

Azure Forced Tunneling is a networking feature that redirects or "forces" all internet-bound traffic from Azure VMs through your on-premises network for inspection and auditing before allowing it to reach the internet. This is critical for compliance, security policies, and maintaining control over outbound traffic.

Key Concepts

  • User-Defined Routes (UDR): Custom routes that override Azure's default routing
  • Route Table: Collection of routes that determine traffic flow
  • Next Hop Type: Specifies where traffic should be sent (Virtual Network Gateway, Virtual Appliance, etc.)
  • Address Prefix: Destination network range for the route

Architecture Overview

graph TD A[Azure VM] -->|Internet Traffic| B[Subnet Route Table] B -->|0.0.0.0/0 Route| C[VPN Gateway] C -->|Forced Tunnel| D[On-Premises Network] D -->|Security Inspection| E[On-Premises Firewall] E -->|Approved Traffic| F[Internet] G[Azure Services] -->|Direct Route| H[Internet] style A fill:#e1f5fe style C fill:#fff3e0 style D fill:#f3e5f5 style E fill:#ffebee style F fill:#e8f5e8

Architecture Explanation

This diagram shows the basic forced tunneling architecture where:

  • Azure VM: Generates internet-bound traffic
  • Subnet Route Table: Contains UDR with 0.0.0.0/0 route pointing to VPN Gateway
  • VPN Gateway: Receives all internet traffic and tunnels it to on-premises
  • On-Premises Network: Receives tunneled traffic for inspection
  • Security Inspection: Firewall or security appliance inspects traffic
  • Internet Access: Approved traffic is allowed to reach the internet

Note: Azure platform services maintain direct internet connectivity for management operations.

Detailed Traffic Flow Analysis

Scenario 1: VM-to-Internet Traffic Flow

sequenceDiagram participant VM as Azure VM participant RT as Route Table participant GW as VPN Gateway participant OP as On-Premises participant FW as Firewall participant INT as Internet VM->>RT: Internet request (0.0.0.0/0) RT->>GW: Route to VPN Gateway GW->>OP: Tunnel traffic via VPN OP->>FW: Forward to security inspection FW->>INT: Allow approved traffic INT->>FW: Response FW->>OP: Forward response OP->>GW: Return via VPN tunnel GW->>VM: Deliver response

VM-to-Internet Flow Explanation

This sequence diagram illustrates the complete journey of internet-bound traffic from an Azure VM:

  1. VM initiates request: VM attempts to access internet resource
  2. Route table lookup: Azure checks UDR for destination 0.0.0.0/0
  3. Gateway routing: Traffic is directed to VPN Gateway instead of default internet route
  4. VPN tunneling: Gateway encrypts and tunnels traffic to on-premises
  5. Security inspection: On-premises firewall inspects traffic for compliance
  6. Internet access: Approved traffic reaches the internet
  7. Response path: Return traffic follows the same path in reverse

Scenario 2: Multi-Tier Application with Forced Tunneling

graph TB subgraph "Azure VNet" subgraph "Web Tier Subnet" W1[Web Server 1] W2[Web Server 2] WRT[Web Route Table] end subgraph "App Tier Subnet" A1[App Server 1] A2[App Server 2] ART[App Route Table] end subgraph "DB Tier Subnet" D1[Database 1] D2[Database 2] DRT[DB Route Table] end subgraph "Gateway Subnet" VGW[VPN Gateway] end end subgraph "On-Premises" FW[Firewall] CORP[Corporate Network] end INTERNET[Internet] W1 --> WRT W2 --> WRT WRT -->|0.0.0.0/0| VGW A1 --> ART A2 --> ART ART -->|0.0.0.0/0| VGW D1 --> DRT D2 --> DRT DRT -->|0.0.0.0/0| VGW VGW -->|Forced Tunnel| FW FW --> CORP FW --> INTERNET style W1 fill:#e3f2fd style W2 fill:#e3f2fd style A1 fill:#f1f8e9 style A2 fill:#f1f8e9 style D1 fill:#fff3e0 style D2 fill:#fff3e0 style VGW fill:#ffebee style FW fill:#f3e5f5

Multi-Tier Application Flow Explanation

This diagram shows how forced tunneling applies to a multi-tier application architecture:

  • Web Tier: Internet-facing servers that need to access external APIs or services
  • App Tier: Application servers that may need to download updates or access external services
  • Database Tier: Database servers that might need to access external backup services
  • Consistent Routing: All tiers use the same forced tunneling configuration
  • Centralized Security: All internet traffic is inspected at the on-premises firewall

Each subnet has its own route table with identical UDR configuration, ensuring consistent traffic flow across all tiers.

Use Cases for Forced Tunneling

1. Compliance and Regulatory Requirements

Scenario: Financial services company needs to comply with PCI-DSS requirements.

Solution: All internet traffic must be inspected and logged through on-premises security appliances.

Benefits: Maintains compliance, centralized logging, consistent security policies.

2. Data Loss Prevention (DLP)

Scenario: Healthcare organization needs to prevent sensitive data exfiltration.

Solution: Route all outbound traffic through DLP appliances for content inspection.

Benefits: Prevents data leakage, maintains HIPAA compliance, audit trails.

3. Centralized Internet Access Control

Scenario: Government agency requires all internet access to go through approved gateways.

Solution: Force all Azure VM traffic through on-premises security stack.

Benefits: Consistent security policies, centralized management, controlled access.

4. Hybrid Cloud Security Architecture

Scenario: Enterprise wants consistent security posture across on-premises and cloud.

Solution: Extend existing security infrastructure to cover Azure workloads.

Benefits: Unified security management, consistent policies, reduced complexity.

Configuration Implementation

Configuration Flow Diagram

graph TD A[1. Create Route Table] --> B[2. Create UDR Route] B --> C[3. Associate Route Table to Subnet] C --> D[4. Configure VPN Gateway] D --> E[5. Verify Configuration] A1[az network route-table create] --> A B1[az network route-table route create] --> B C1[az network vnet subnet update] --> C D1[BGP Configuration] --> D E1[az network route-table route list] --> E style A fill:#e3f2fd style B fill:#f1f8e9 style C fill:#fff3e0 style D fill:#ffebee style E fill:#f3e5f5

Configuration Flow Explanation

This diagram shows the logical order of configuration steps:

  1. Route Table Creation: First, create the route table container
  2. UDR Route Creation: Add the specific route for forced tunneling
  3. Subnet Association: Link the route table to the target subnet
  4. Gateway Configuration: Ensure VPN gateway is properly configured
  5. Verification: Confirm the configuration is working correctly

Step 1: Create Route Table

az network route-table create \ --resource-group myResourceGroup \ --name myRouteTable \ --location eastus \ --disable-bgp-route-propagation true

Route Table Configuration Parameters

  • --resource-group: Specifies the resource group containing the route table
  • --name: Unique name for the route table within the resource group
  • --location: Azure region where the route table will be created
  • --disable-bgp-route-propagation: Prevents BGP routes from being automatically added to the route table

Purpose: This creates the container for your custom routes. The BGP propagation is disabled to prevent automatic route learning from interfering with your forced tunneling configuration.

Next Step: After creating the route table, you'll add the specific UDR route for forced tunneling.

Step 2: Create Forced Tunneling Route

az network route-table route create \ --resource-group myResourceGroup \ --route-table-name myRouteTable \ --name ForceInternetToOnPrem \ --address-prefix 0.0.0.0/0 \ --next-hop-type VirtualNetworkGateway

UDR Route Configuration Parameters

  • --route-table-name: References the route table created in Step 1
  • --name: Descriptive name for the route (use meaningful names for management)
  • --address-prefix: 0.0.0.0/0 captures all internet-bound traffic
  • --next-hop-type: VirtualNetworkGateway directs traffic to the VPN gateway

Purpose: This is the core forced tunneling route that intercepts all internet traffic (0.0.0.0/0) and redirects it to the VPN gateway instead of the default internet route.

Alternative Options: You could also use VirtualAppliance as next-hop-type if routing through a network virtual appliance.

Step 3: Associate Route Table with Subnet

az network vnet subnet update \ --resource-group myResourceGroup \ --vnet-name myVNet \ --name mySubnet \ --route-table myRouteTable

Subnet Association Parameters

  • --vnet-name: Name of the virtual network containing the subnet
  • --name: Name of the subnet to associate with the route table
  • --route-table: Name of the route table to associate

Purpose: This step activates the forced tunneling by associating the route table with the subnet containing your VMs.

Important: Once associated, all VMs in this subnet will have their internet traffic forced through the VPN gateway.

Step 4: Configure VPN Gateway for Forced Tunneling

az network vnet-gateway update \ --resource-group myResourceGroup \ --name myVpnGateway \ --enable-bgp true \ --bgp-peering-address 10.0.0.1 \ --asn 65000

VPN Gateway BGP Configuration

  • --enable-bgp: Enables Border Gateway Protocol for dynamic routing
  • --bgp-peering-address: IP address for BGP peering (typically gateway subnet IP)
  • --asn: Autonomous System Number for BGP (use private ASN range)

Purpose: BGP is essential for forced tunneling as it allows the VPN gateway to advertise a default route (0.0.0.0/0) to Azure, enabling proper traffic flow.

Prerequisites: Your on-premises VPN device must also support BGP and be configured with a compatible ASN.

Step 5: Create Default Route Advertisement

az network local-gateway update \ --resource-group myResourceGroup \ --name myLocalGateway \ --local-address-prefixes 0.0.0.0/0 \ --bgp-peering-address 192.168.1.1 \ --asn 65001

Local Gateway Configuration

  • --local-address-prefixes: 0.0.0.0/0 indicates this gateway can reach all internet destinations
  • --bgp-peering-address: On-premises BGP peer IP address
  • --asn: On-premises ASN (must be different from Azure gateway ASN)

Purpose: This configures the local network gateway to advertise itself as the route to internet destinations, enabling forced tunneling.

Critical: The on-premises device must actually be able to route internet traffic, or connectivity will fail.

Advanced Configuration Scenarios

Scenario 1: Selective Forced Tunneling

graph TD subgraph "Azure VNet" A[VM - Critical Apps] --> RT1[Route Table 1] B[VM - Dev/Test] --> RT2[Route Table 2] C[VM - Management] --> RT3[Route Table 3] end RT1 -->|All Traffic| GW[VPN Gateway] RT2 -->|Selective Routes| GW RT3 -->|No Forced Tunneling| INT[Internet] GW --> OP[On-Premises] OP --> INTERNET[Internet] style A fill:#ffebee style B fill:#fff3e0 style C fill:#e8f5e8

Selective Forced Tunneling Explanation

This scenario shows how different workloads can have different routing policies:

  • Critical Applications: Full forced tunneling for maximum security
  • Dev/Test Environments: Partial forced tunneling for specific destinations
  • Management VMs: Direct internet access for operational efficiency
# Create route table for selective forced tunneling az network route-table create \ --resource-group myResourceGroup \ --name selectiveRouteTable \ --location eastus # Add route for specific IP ranges only az network route-table route create \ --resource-group myResourceGroup \ --route-table-name selectiveRouteTable \ --name ForceSpecificTraffic \ --address-prefix 203.0.113.0/24 \ --next-hop-type VirtualNetworkGateway

Selective Routing Configuration

This configuration forces only specific IP ranges through the VPN gateway instead of all internet traffic. Use this when you need to:

  • Route traffic to specific partner networks through VPN
  • Maintain direct internet access for most destinations
  • Apply forced tunneling to specific compliance-required destinations

Scenario 2: Network Virtual Appliance (NVA) Integration

graph TD subgraph "Azure VNet" A[VM] --> RT[Route Table] RT -->|0.0.0.0/0| NVA[Network Virtual Appliance] NVA --> GW[VPN Gateway] end GW --> OP[On-Premises] OP --> FW[Firewall] FW --> INT[Internet] style NVA fill:#e1f5fe style GW fill:#fff3e0 style FW fill:#ffebee

NVA Integration Explanation

This scenario routes traffic through a Network Virtual Appliance before sending to the VPN gateway:

  • First Hop: Traffic goes to NVA for additional processing
  • Second Hop: NVA forwards traffic to VPN gateway
  • Use Cases: Additional security scanning, load balancing, or custom routing logic
# Create route to NVA az network route-table route create \ --resource-group myResourceGroup \ --route-table-name myRouteTable \ --name RouteToNVA \ --address-prefix 0.0.0.0/0 \ --next-hop-type VirtualAppliance \ --next-hop-ip-address 10.0.1.4

NVA Routing Configuration

  • --next-hop-type VirtualAppliance: Specifies traffic should go to a VM-based appliance
  • --next-hop-ip-address: IP address of the NVA (must be in same VNet)

Requirements: The NVA must have IP forwarding enabled and appropriate routing configured to forward traffic to the VPN gateway.

Verification and Troubleshooting

Verification Commands

# Verify route table configuration az network route-table route list \ --resource-group myResourceGroup \ --route-table-name myRouteTable \ --output table
# Check subnet association az network vnet subnet show \ --resource-group myResourceGroup \ --vnet-name myVNet \ --name mySubnet \ --query routeTable.id \ --output tsv
# Verify VPN gateway BGP configuration az network vnet-gateway show \ --resource-group myResourceGroup \ --name myVpnGateway \ --query bgpSettings

Verification Steps

  1. Route Table Verification: Confirm the 0.0.0.0/0 route exists and points to VirtualNetworkGateway
  2. Subnet Association: Ensure the route table is properly associated with the subnet
  3. BGP Configuration: Verify BGP settings are correctly configured for route advertisement

Testing Connectivity

# Test from VM - check effective routes az network nic show-effective-route-table \ --resource-group myResourceGroup \ --name myVmNic \ --output table
# Test internet connectivity (should fail if not configured properly) # Run from VM: curl -I http://www.google.com

Important Testing Notes

  • Test connectivity before and after implementing forced tunneling
  • Ensure on-premises firewall allows the required traffic
  • Monitor VPN gateway metrics for traffic flow
  • Use Network Watcher for detailed troubleshooting

Best Practices and Considerations

Security Considerations

  • Gateway Subnet: Never apply forced tunneling to the gateway subnet
  • Management Access: Ensure management plane access remains functional
  • Service Endpoints: Use VNet service endpoints for Azure services when possible
  • Private Endpoints: Consider private endpoints for PaaS services

Performance Considerations

  • Bandwidth: Ensure sufficient VPN bandwidth for all tunneled traffic
  • Latency: Additional hops increase latency - test application performance
  • Gateway SKU: Choose appropriate VPN gateway SKU for throughput requirements
  • Routing Efficiency: Optimize on-premises routing for performance

Cost Considerations

  • VPN Gateway: Costs based on SKU and uptime
  • Data Transfer: All internet traffic now goes through VPN (outbound charges)
  • On-Premises Bandwidth: Increased bandwidth requirements
  • Monitoring: Additional monitoring and management overhead

Critical Warnings

  • Never apply forced tunneling to the gateway subnet - this will break connectivity
  • Test thoroughly before implementing in production
  • Have a rollback plan in case of connectivity issues
  • Monitor continuously for performance and connectivity issues

Complete Configuration Summary

Configuration Order Summary

Step 1: Create Route Table
az network route-table create --resource-group myResourceGroup --name myRouteTable --location eastus --disable-bgp-route-propagation true
Step 2: Create Forced Tunneling Route
az network route-table route create --resource-group myResourceGroup --route-table-name myRouteTable --name ForceInternetToOnPrem --address-prefix 0.0.0.0/0 --next-hop-type VirtualNetworkGateway
Step 3: Associate Route Table with Subnet
az network vnet subnet update --resource-group myResourceGroup --vnet-name myVNet --name mySubnet --route-table myRouteTable
Step 4: Configure VPN Gateway BGP
az network vnet-gateway update --resource-group myResourceGroup --name myVpnGateway --enable-bgp true --bgp-peering-address 10.0.0.1 --asn 65000
Step 5: Configure Local Gateway
az network local-gateway update --resource-group myResourceGroup --name myLocalGateway --local-address-prefixes 0.0.0.0/0 --bgp-peering-address 192.168.1.1 --asn 65001
Step 6: Verify Configuration
az network route-table route list --resource-group myResourceGroup --route-table-name myRouteTable --output table