Navigating the End of Azure VM Direct Internet Access: Part 5 - Implementing Azure VPN Gateway with Site to Site VPN

Azure VM Internet - VPN Gateway, S2S VPN and Default Site

Welcome to the final installment of our series addressing the deprecation of direct internet access for Azure Virtual Machines (VMs). Throughout this journey, we’ve explored several robust solutions to maintain and secure outbound internet connectivity:

  1. Part 1: Implemented a NAT Gateway for scalable and simplified outbound connectivity.
  2. Part 2: Deployed an Azure Firewall to enhance security and control over network traffic.
  3. Part 3: Leveraged Network Virtual Appliances (NVAs) for advanced networking capabilities.
  4. Part 4: Using Azure Load Balancer with Outbound Rules as an method to provide outbound internet traffic.

In this final part we will explore the solution using VPN Gateways connected to an on-prem environment and leverage a default site configuration to send traffic back to on-prem for internet access.

Introduction

Modern enterprise connectivity is shifting. Today’s organisations are leaving behind the legacy of direct internet access on Azure VMs in favor of more secure, manageable, and scalable models. In this installment, we detail how to implement an Azure VPN Gateway using a Site-to-Site VPN approach—and equip you with the tools to configure a “default site” that streamlines your routing. Whether you prefer a hands-on GUI approach via the Azure Portal, an automated deployment using Bicep, or fine-tuning with PowerShell, this guide covers all bases. We’ve also included a diagram (in Mermaid) to visualize the network path as your traffic journeys from Azure, through the VPN Gateway, into your on-premises network, and finally out to the internet.

Prerequisites

Before you begin, ensure you have the following:

  • Resource Group: A dedicated container for your Azure resources.
  • Virtual Network (VNet) & Gateway Subnet: Your VNet should contain an appropriately sized gateway subnet.
  • Public IP Address: Provisioned and associated with the VPN Gateway.
  • Access Tools:
    • Azure Portal: For GUI-based deployment.
    • Bicep: For Infrastructure-as-Code deployments.
    • PowerShell (Az Module): For post-deployment configuration adjustments.

Deployment Options

In this guide, we’ll walk through three deployment methods:

  1. Azure Portal Deployment – A visual, step-by-step process.
  2. Bicep Template Deployment – Automated infrastructure-as-code for repeatable builds.
  3. PowerShell Configuration – Post-deployment tweaks to set the default site property.

Azure Portal Deployment

The Azure Portal provides an intuitive process to deploy your VPN Gateway. Follow these steps:

  1. Sign In and Prepare:

    • Log into the Azure Portal.
    • Confirm that your Resource Group, Virtual Network, and Gateway Subnet are in place.
    • Create a Public IP Address resource if it isn’t already available.
  2. Create the Virtual Network Gateway:

    • Click Create a resource and search for Virtual network gateway.
    • In the Basics tab, provide:
      • Subscription and Resource Group: Select your existing group.
      • Name: For example, MyVpnGateway.
      • Region: Ensure it matches your VNet’s region.
      • Gateway Type: Choose VPN.
      • VPN Type: Select Route-based.
      • SKU: Pick an option such as VpnGw1.
  3. Configure Networking:

    • Under Virtual Network, select your preconfigured VNet.
    • Confirm the correct Gateway Subnet appears.
    • Associate the Public IP Address you prepared.
  4. Set the Default Site:

    • If provided in the deployment wizard, specify the default site name (e.g., DefaultSite).
    • If the option is missing from the GUI, you can adjust it later using PowerShell (see below).
  5. Review and Create:

    • Review all settings and click Create.
    • After creation, validate the gateway’s connectivity using Azure Monitor or Network Watcher.

Bicep Template Deployment

For those seeking repeatable, automated deployments, the following Bicep template provisions an Azure VPN Gateway with the default site property configured.

Save the content below as deployVpnGateway.bicep:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
// Parameters
@description('VPN Gateway Name')
param vpnGatewayName string = 'MyVpnGateway'

@description('Resource Location is using the Resource Groups location')
param location string = resourceGroup().location

@description('VPN Gateway SKU https://learn.microsoft.com/en-us/azure/vpn-gateway/about-gateway-skus')
param skuName string = 'VpnGw1'

@description('Azure Virtual Network Name')
param vnetName string = 'myVNet-01'

@description('VPN Gateway Public IP Name')
param publicIpName string = 'myVNG-PublicIP'

@description('Local Network Gateway Name')
param localNetworkGatewayName string = 'myLNG'

@description('Local Network Gateway Shared Key for Authentication')
@secure()
param sharedKey string

@description('Site-to-Site Connection Name')
param SiteToSiteConnectionName string = 'myS2SConnection'

@description('Local Network Gateway IP Address')
param localNetworkGatewayIpAddress string = '111.111.222.222'

@description('VPN Remote Side Network Address Space')
param remoteNetworkAddressSpace string = '192.168.1.0/24'

resource publicip 'Microsoft.Network/publicIPAddresses@2024-05-01' = {
  name: publicIpName
  location: location
  sku: {
    name: 'Standard'
  }
  properties: {
    publicIPAllocationMethod: 'Static'
  }
}

resource vnet 'Microsoft.Network/virtualNetworks@2024-05-01' existing = {
  name: vnetName
}

resource subnet 'Microsoft.Network/virtualNetworks/subnets@2024-05-01' existing = {
  parent: vnet
  name: 'GatewaySubnet'
}

resource vpnGateway 'Microsoft.Network/virtualNetworkGateways@2024-05-01' = {
  name: vpnGatewayName
  location: location
  properties: {
    gatewayType: 'Vpn'
    vpnType: 'RouteBased'
    sku: {
      name: skuName
      tier: skuName
    }
    vpnGatewayGeneration: 'Generation1'
    enableBgp: false
    ipConfigurations: [
      {
        name: 'vnetGatewayConfig'
        properties: {
          privateIPAllocationMethod: 'Dynamic'
          publicIPAddress: {
            id: publicip.id
          }
          subnet: {
            id: subnet.id
          }
        }
      }
    ]
  }
}

resource localNetworkGateway 'Microsoft.Network/localNetworkGateways@2024-05-01' = {
  name: localNetworkGatewayName
  location: location
  properties: {
    localNetworkAddressSpace: {
      addressPrefixes: [
        remoteNetworkAddressSpace
      ]
    } 
    gatewayIpAddress: localNetworkGatewayIpAddress
  }
}

resource vpnConnection 'Microsoft.Network/connections@2024-05-01' = {
  name: SiteToSiteConnectionName
  location: location
  properties: {
    connectionType: 'IPsec'
    virtualNetworkGateway1: {
      id: vpnGateway.id
    }
    localNetworkGateway2: {
      id: localNetworkGateway.id
    }
    routingWeight: 10
    sharedKey: sharedKey
  }
}

To deploy via the Azure CLI:

  1. Sign in:

    1
    
    az login
    
  2. Run the deployment command:

    1
    2
    3
    
    az deployment group create \
      --resource-group MyResourceGroup \
      --template-file deployVpnGateway.bicep
    

Monitor the output to confirm the VPN Gateway and the default site have been established correctly.

PowerShell Configuration for the Default Site

If you didn’t set the default site during deployment (or need to modify it), the following PowerShell commands let you update the VPN Gateway configuration.

ℹ️
The DefaultSite is the name of the connection associated with the vpn gateway that you are going to define as the default site for traffic.
  1. Establish Your Variables:

    1
    2
    3
    
    $resourceGroupName = "MyResourceGroup"
    $gatewayName = "MyVpnGateway"
    $defaultSiteName = "DefaultSite"
    
  2. Retrieve and Update the Gateway:

    1
    2
    3
    4
    5
    6
    7
    8
    
    # Retrieve the existing VPN Gateway
    $gateway = Get-AzVirtualNetworkGateway -ResourceGroupName $resourceGroupName -Name $gatewayName
    
    # Update the default site property
    $gateway.DefaultSite = $defaultSiteName
    
    # Apply the configuration update
    Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gateway
    
  3. Verify the Change:

    1
    
    Get-AzVirtualNetworkGateway -ResourceGroupName $resourceGroupName -Name $gatewayName | Select-Object Name, DefaultSite
    

This confirms that all unmatched traffic will follow the specified default path, simplifying your routing configuration.

Network Traffic Flow

To capture the journey of your traffic—from Azure workloads, through the VPN Gateway (configured with your default site), into your on-premises network, and finally out to the internet—consider the following Mermaid diagram:

graph LR A[Azure Workload] B["Azure VPN Gateway
(Default Site)"] C[On-Premises Network] D[Internet] A -->|Outbound Traffic| B B -->|Routes to| C C --> D

This diagram illustrates the complete network path: traffic leaves an Azure workload, is routed through the VPN Gateway configured with a default site, traverses your on-premises network, and ultimately exits to the internet.

Final Thoughts

Transitioning from direct Azure VM internet access to a centralized connectivity model via a VPN Gateway is not merely a technical upgrade—it’s a strategic evolution. By deploying an Azure VPN Gateway with a comprehensive Site-to-Site VPN configuration and a default site, you enhance security and simplify network management in a scalable manner. Whether you deploy via the Azure Portal, automate with Bicep, or fine-tune via PowerShell, you’re laying the foundation for a resilient and future-proof infrastructure.

Have you faced challenges during your migration journey? Let’s discuss best practices, performance tuning, and monitoring enhancements as we continue navigating the complexities of modern cloud connectivity.

Learn More