Matt Ouellette is a certified information technology professional residing in Southwest Michigan. His technology findings and advice can be found on his PacketPilot blog. Mr. Ouellette spent 4 years as an I.T. Technician before stepping into a Network Engineer role at Bronson Health Group. Since completing his Associates Degree in Network Administration Matt has taken a head on approach to career enrichment through obtaining credentials such as CCNP, CCNA Voice, MCSA: Server 2008, and VCP5. This passion for continued learning allows him to deliver up to date quality technical solutions.
Notes from MS Learn AZ-700 Module 3: Design and Implement Azure ExpressRoute – Unit 2: Explore Azure ExpressRoute
ExpressRoute extends on-prem to Microsoft cloud via private connection with assistance of a provider. Creates connections to MS Cloud Services like Azure and MS 365. It can be any-to-any (IP VPN), point-to-point Ethernet, or virtual cross-connect through provider colo. Since no internet ExpressRoute connections are more reliable, faster, latency consistent, higher security.
ExpressRoute Capabilities
Key benefits
L3 connection between on-prem and MS Cloud via provider
Can be any-to-any (IPVPN), Point-to-Point Ethernet, Virtual Cross-Connect through an Ethernet Exchange
Connection to MS Cloud Services over all regions in a geopolitical region
Global connectivity to MS across all regions (with ExpressRoute premium)
Built-in redundancy in every peering location
Used to create private connectivity between Azure DC/infrastructure on-prem or a colo
Increased reliability, speed, and lower latency since it doesn’t go over the internet
Understand Use Cases for Azure ExpressRoute
Faster/Reliable connection to Azure
Not reliant on internet
Can be cheaper for on-prem or colo facility data transfer to Azure
Storage/Backup/Recovery
Gast Reliable connection to Azure
Bandwidths up to 100 Gbps
Great for periodic data migration/replication/DR/addition HA strategy
Extend DC Capabilities
Connect and add computer/storage capacity to existing DCs
High throughput and low latencies feel like natural extension
Predictable/reliable/high throughput connectivity
Build apps that span on-prem and Azure without compromising privacy/performance
Example run intranet app in Azure with auth against on-prem AD
Corp customers don’t have to route over public internet
ExpressRoute Connectivity Models
Many models available for on-prem/colo to the cloud in Azure. Examples
Co-location at Cloud Exchange
Facility with cloud exchange virtual cross-connects to MS cloud from providers Ethernet exchange
Colo provider offer either L2 or managed L3 cross connection between infrastructure and MS Cloud
Point-to-Point Ethernet
Provider can offer L2 or L3 between on-prem and MS Cloud
Any-to-Any (IPVPN)
Provider offer any-to-any between branch offices and DCs
MS Cloud can be interconnected to your WAN to look as a branch office
WAN provider typically offer manage L3
Direct from ExpressRoute
Dual 100 GbPS or 10Gbps
Active/Active at scale
Design Consideration for ExpressRoute Deployments
Choose model based on key considerations
ExpressRoute Direct
Connects direct to MS global network at peering location (distributed around world)
Dual 100 or 10 Gbps
Active/Active
Can work with any SP for ExpressRoute Direct
Features
Massive Data Ingest into services E.g. Storage and Cosmos DB
Physical isolation for regulated industries E.g. Bank, Gov, Retail
Granular control of circuit distribution per business unit
ExpressRoute Direct vs. Service Provider (Table from MS Learn)
Design Redundancy for an ExpressRoute deployment
Two ways to plan redundancy
Configure ExpressRoute and Site-to-Site coexisting
Advantages
Secure failover path for ExpressRoute
Connect to sites not connected through ExpressRoute
Zero downtime when adding new gateway or gateway connection
Network Limits and limitations
Route-Based VPN gateways only
ASN of Azure VPN Gateway must be 65515
Gateway subnet must be /27 or shorter
Dual stack VNet not supported
Create zone redundant virtual network gateway in Azure Availability Zones
VPN and ExpressRoute gateways can be deployed in Availability Zones
This physically and logically separates gateways in a region
Protects on-prem to Azure from zone-level failures
Zone-redundant gateways
Automatically deploy virtual network gateways across availability zones by using zone-redudant virtual gateways.
These benefit from zone-resiliency for mission critical services in Azure
Zonal Gateways
Used to. Deploy gateway in specific zone
When deployed, all instance deployed in same Availability Zone
Gateway SKUs
SKUs similar to corresponding existing SKKUs for ExpressRoute and VPN Gateway
Exception: they are specific SKU’s identifiable by AZ in SKU name
Public IP SKUs
Both Zone-redundant and Zonal GW require Azure Public IP resource Standard
Configure a Site-to-Site VPN as a Failover Path for ExpressRoute
Applies only to VNets linked to Azure private peering path
No VPN-based failover for services reachable through Azure MS Peering
ExpressRoute circuit always primary
Data through Site-to-Site VPN only if ExpressRoute circuit failure
Avoid asymmetrical routing, local config should also prefer ExpressRoute over Site-to-Site path
Set higher local pref to ExpressRoute received routes
Notes from MS Learn AZ-700 Module 2: Design and Implement Hybrid Networking – Unit 8: Create a Network Virtual Appliance (NVA) in a Virtual Hubct Devices to Networks with Point-to-Site VPN Connections
A benefit of Azure Virtual WAN is support for reliable connections from many different technologies. E.g.:
ExpressRoute
VPN Gateway
Barracuda CloudGen WAN
Cisco Cloud OnRamp for multicloud
VMware SD-WAN
These are known as NVAs and are deployed directly into a Virtual WAN Hub with an externally facing public IP. This enables customers to connect branch Customer Premises Equipment (CPE) to the same brand NVA in the hub to maintain advantage of SD-WAN capabilities. Once VNets are connected to hub, NVA allows transitive connectivity throughout the Virtual WAN
Manage an NVA in a Virtual Hub
NVA available in Azure Marketplace can be directly deployed into virtual hub only
Each is a Managed Application allowing Azure Virtual WAN to manage its configuration
Cannot be deployed within arbitrary VNets
Process for deployment
Choose NVA Offer
Azure Marketplace Managed App
Choose Deployment Settings
Choose Agg Capacity
NVA VM deployed in Virtual Hub
Subscription Resources
Managed Resource Group – Net Virtual Appliance ARM resource
Customer Resource Group – App Resource
Deploy an NVA in your Virtual Hub
Deploying an NVA in your virtual hub you access Azure Marketplace through the portal and select the Manage Application for the NVA partner desired
Two Resource Groups are created in subscription when NVA created in Virtual WAN Hub
Customer Resource Group
Contains app placeholder for Managed Application. Partners can use RG to expose customer chosen properties
Managed Resource Group
Customers cannot configure/modify resources in this RG directly
NVA configured automatically during deployment. Once provisioned cannot access directly
Unlike Azure VPN Gateway, no need to create the following for branch site to NVA connectivity (in Virtual WAN Hub
Site resources
Site-to-Site connection resources
Point-to-Site connection resources
Hub-to-VNet connections still required for Virtual WAN Hub to VNet connectivity
Create Network Virtual Appliance in Hub
Example based on Barracude CloudGen WAN Gateway (Other vendor products will vary)
Locate Virtual WAN Hub created in Azure Portal
Find NVA tile and click Create Link
Open NVA and choose Barracude CloudGen WAN
Click Create
Read terms and click Create
On Basics Page
Chose Subscription from dropdown
Chose Resource group from dropdown (one used to deploy Virtual WAN and Hub)
Chose Region from dropdown (same as hub)
Provide App Name
Enter Managed Resource Group
Select Next : CloudGen. WAN gateway > button
Select Virtual WAN Hub from dropdown
Select NVA Infrastructure Units from dropdown
Provide Token (required by Barracuda for auth/identification as valid registered user
NVA Infrastructure Units
When NVA created in Virtual WAN Hub this must be chosen
Is an aggregate bandwidth capacity for the NVA in the Virtual WAN Hub
Similar to VPN Scale Unit when thinking about capacity and sizing
One NVA Infra Unit represents 500 Mbps of agg bandwidth for all connecting sites
Azure supports 1-80 NVA Infra Units for a given NVA virtual hub deployment
Partners may offer different NVA Infra Unit bundles as a subset of all supports NVA Infra Unit configs
Notes from MS Learn AZ-700 Module 2: Design and Implement Hybrid Networking – Unit 6: Connect Remote Resources by Using. Azure Virtual WANs
Organizations are exploring options enabling employees, partners, customers to connect to resources from anywhere. This often happens across national and regional boundaries as well as time zones. This is where Virtual WANs can help
What is Azure Virtual WAN
Networking services bringing networking, security, routing functionalities into a single interface
Some features
Branch Connectivity
Through connectivity automation from partner devices such as SD-WAN or VPN CPE)
Site-to-Site VPN Connectivity
Remote user VPN Connectivity (Point-to-Site)
Private Connectivity (ExpressRoute)
Intra-cloud Connectivity (transitive for VNets)
VPN ExpressRoute inter-connectivity
Routing, Azure FW, Encryption for private connectivity
Configuration for end-to-end virtual WAN requires
Virtual WAN
Hub
Hub VNet connection
Hub-to-Hub connection
Hub route table
Choose Virtual WAN SKU
virtualWAN resource is a virtual overlay of Azure network
Collection of many resources
Contains links to all virtual hubs desired within the virtual WAN
Isolated from each other
Cannot have a common hub
Virtual hubs in different virtual WANs don’t communicate
Two types: Basic and Standard (table below from MS Learn)
Hub Private Address Space
Virtual Hub is MS managed virtual network
Hub contains various service endpoints for connectivity
From on-prem (vpnsite) connect
To a VPN gateway inside virtual hub
ExpressRoute circuit to virtual hub
Mobile users to Point-to-Site gateway within virtual hub
Hub is core of network in region. Multiple hubs possible in same region
Min address space is /24
Anything /25-/32 kicks error during creation
No need to specify as Azure creates subnets in virtual hub for different gateways/services it needs
Gateway Scale
Hub gateway not the same as virtual network gateway used for ExpressRoute and VPN Gateway
Virtual WAN you don’t create Site-to-Site from on-prem direct to VNet
Create Site-to-Site to the hub
Traffic goes through hub gateway
In Virtual WAN VNets take advantage of easy scaling through virtual hub and virtual hub gateway
Connect Cross-Tenant VNets to a Virtual WAN Hub
Ability to use Virtual WAN to connect VNet to virtual hub in diff tenant
Useful if client workloads must be connected to same network but exist on diff tenants
Configuration but be already in place before cross-tenants VNet connectivy to Virtual WAN Hub
Virtual WAN and Virtual Hub in parent subscription
VNet in subscription of remote tenant
Non overlapping addr space in remote tenant and any other VNet connected to parent Virtual Hub
Virtual Hub Routing
Provided by a route managing all routing between gateways using BGP
Virtual Hub can contain multiple gateways
Site-to-Site VPN Gateway
ExpressRoute Gateway
Point-to-Site Gateway
Azure FW
Route also provides transit connecivity between VNets connected to a virtual HUB
Support an aggregate throughput of 50 Gbps
Capabilities apply to Standard Virtual WAN customers
Notes from MS Learn AZ-700 Module 2: Design and Implement Hybrid Networking – Unit 5: Connect Devices to Networks with Point-to-Site VPN Connections
Point-to-Site (P2S) allows secure connection to VNet from an individual client. Connection started from client. Use for telecommuters or minimal amount of clients that need to connect.
Point-to-Site Protocols
OpenVPN
SSL/TLS based. Can penetrate firewall as most have TCP port 443 open outbound
Useful for:
Android
iOS 11 and up
Windows
Linux
Mac (macOS 10.13 and up)
Secure Socket Tunneling. Protocol (SSTP)
Proprietary TLS-based. Can penetrate most FW as TCP 443 based
Only supported on Windows
Azure supports all versions of Windows with SSTP (Windows 7 and up)
IKEv2
Standards based
Can be used for Macs (macOS 10.11 and up)
Point-to-Site Auth methods
Native Azure Certificate Auth
Client certificate on device used to auth user
Certificates generated from trusted root cert and installed on each client
Use root cert generated using Enterprise solution or generate self-signed cert
Validation of client cert happens during connection establishment
Root cert is required for validation, needs to be uploaded to Azure
Native MS Entra ID Auth
Native auth users connect using MS Entra ID Creds
Only supported for OpenVPN and Windows 10
Requires use of Azure VPN Client
Conditional access and MFA can be used
High Level Steps
Configure tenant
Enable auth on gateway
Download-Configure Azure VPN client
Auth using ADDS (Active Directory Domain Services)
Useful as it allows users to connect with Azure using org domain creds
Requires a RADIUS server (new or existing)
RADIUS Server on-prem or in Azure VNet
Azure VPN Gateway passes auth back and forth between RADIUS and connecting device
Gateway must have communication with RADIUS
If RADIUS on-prem a Site-to-Site VPN between Azure and on-prem required
RADIUS can integrate with certificate services
Integration means no need to upload root or revoked certs to Azure
RADIUS can also integrate with other external ID e.g. MFA
Configure Point-to-Site Clients
Utilize native Windows or Mac clients
Azure offers VPN client config zip with required settings
Zip provides values of some important settings on Azure side used to create own profile. Values:
VPN gateway address
Tunnel types
Routes
Root Cert
Windows
VPN config consists of installer package
Client must have admin rights on client device to initiate VPN to Azure
Notes from MS Learn AZ-700 Module 2: Design and Implement Hybrid Networking – Unit 2: Design and Implement Azure VPN Gateway
VPN provides secure, encrypted connections across another network. Often eployed. To connect 2 or more trusted private networks over an untrusted network (e.g. Internet) One option for connecting on-prem networks to an Azure VNet is VPN. A VPN Gateway is used as an endpoint for incoming connections to Azure VNet
Azure VPN Gateways
Specific type of virtual network gateway used to Tx/Rx encrypted traffic between Azure and On-Prem Networks
Can also be used to connect separate VNets encrypting over the MS network backbone
Made up of 2 or more special VM’s deployed to a specific subnet called the “gateway subnet”
Can take some time to complete so proper planning is important
When creating a Virtual Network Gateway the gateway VMs are created and deployed to the gateway subnet
VMs then have setting to configure on the gateway
Plan a VPN Gateway
Architectures to consider
Point-to-Site over internet
Site-to-Site over internet
Site-to-Site over dedicated network (e.g. Azure ExpressRoute)
Planning Factors
Factors to cover during planning
Throughput
Mbps
Gbps
Backbone
Internet
Private
Availability of public IP Address
VPN device compatibility
Multiple client connections vs Site-to-Site link
VPN Gateway type
Azure VPN Gateway SKU
Gateway SKU’s and Generations (Table
When creating you select the SKU that meets your requirements (Table taken from MS Learn)
Workload
Throughput
Features
SLA’s
(*) Virtual WAN used if more than 30 Site-to-Site VPN tunnels required
Resizing on VpnGw SKU’s allowed in same Gen but not the Basic SKU
Basic SKU is legacy with feature limitations
To move from Basic to VpnGw SKU deletion of Basic and rebuild with other Generation and SKU size combo required
Connection limits are separate
E.g. can have 128 @@TP connections and 250 IKEv2 connections on a single VpnGw1 SKU
Single tunnel
Max of 1Gbps
Aggregate Throughput Benchmark on VPN Gateway is Site-to-Site + Point-to-Site
Multiple Point-to-Site connection can negatively impact Site-to-Site due to throughput limitations
Aggregate Throughput Benchmark isn’t guaranteed due to Inet traffic conditions and app behavior
VPN Gateway Types
When creating a Virtual Network Gateway for a VPN Gateway config type must be specified
VPN type depends on connection topology desired
For example of above
Point-to-Site requires RouteBased VPN Type
VPN type selected must meet all connection requirements for desired solution
For example of above
Create a Site-to-Site VPN & Point-to-Site VPN gateway connections on same VNet use RouteBased
This is due to Point-to-Site requiring RouteBased VPN type
Would also require VPN device supports RouteBased VPN connections
PolicyBased type
Previously called “static routing gateways” in classic deployment model
Encrypt and direct packets through IPsec tunnels based on IPsec policies
Policy (traffic selector) defined as ACL in VPN device config
Value for PolicyBased VPN type is PolicyBased
Limitations
Support IKEv1 protocols and used with Basic Gateway SKU only
Only 1 tunnel can be used
Only use for Site-to-Site connections & only certain configs
Most VPN Gateway configs require RouteBased type
RouteBased
Previously called “Dynamec routing gateways” in classic deployment model (Table taken from MS Learn)
Table below (Table taken from MS Learn) applies to both Resource Manager and Classic deployment models
For classic model, PolicyBased VPN are the same as Static Gateways & Route-Based are the same as Dynamic Gateways
(*) No BGP in classic deployment model
Create VPN Gateway
VPN Settings chosen critical in successful connection
Name
Region
Gateway Type
VPN
ExpressRoute
VPN Type
Most are Route-Based for Point-toSite, Inter-virtual network, or multiple Site-to-Site
Route-based
Most are Route-Based for Point-toSite, Inter-virtual network, or multiple Site-to-Site
Also for ExpressRoute or if IKEv2 required
Policy-based
Only supports IKEv1
SKU
Affects number of tunnels
Can have the “aggregate throughput benchmark”
Based on multiple tunnels aggregated through single gateway – not guaranteed due to Inet traffic and app behavior
Generation
Gen 1 or 2
Cannot change generations or SKU’s across generations
Basic and VPNGw1 SKU only supported in Gen1
VpnGw4 and VpnGw5 SKU only in Gen2
Virtual Network
VNet able to Tx/Rx traffic through a virtual network gateway
Cannot associate with multiple gateways
Active-Active mode
Enabled
Disabled
BGP ASN
Enabled
Disabled
Gateway should appear as a connected device – can view IP address assigned to gateway
Gateway Subnet
Required for VPN. Gateways
Can create before you create the gateway
Contains IP addresses the VNet gateway VMs and Services use
Never deploy anything other than gateway VMs in this subnet
Must be named GatewaySubnet as it tells Azure which subnets to deploy virtual network gateway VMs and Services to
When creating gateway subnet specify the number of IP Addresses subnet contains
IP addresses are allocated to gateway VMs and Services
Some configs require more IP’s than others
Refer to documentation for desired configuration when planning gateway subnet size
E.g. ExpressRoute/VPN Gateway coexistant config requires a larger subnet than most other
Plan for possible future configurations
MS Learn recommendation – /27 or larger although the smallest is /29
Create Local Network Gateway
Local Network Gateway usually is the on-prem location
Settings
Give site a name that Azure can refer to
Specify IP address prefixes to route through VPN gateway to VPN devices
IP Address is the public IP of the local gateway
Address Space is 1 or more CIDR ranges defining local networks address space
If doing BGP-Enabled check the box
Min prefix declaration is the host address of BGP Peer IP on VPN device
Configure On-prem VPN Device
Reference validated list of standard VPN Devices Created with Vendors such as
Cisco
Juniper
Barracuda
My latest search came back with the following Azure support site
