Matt Ouellette

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.

Most commented posts

  1. Cisco SD-WAN ISR 4k Getting Started – Part 2 – Bootstrap Process — 4 comments
  2. Burnout or just a Reset? – It’s Okay it Happens — 2 comments
  3. Cisco Live US 2019 – Explorer Guide — 2 comments
  4. What Happened? I’m Back! — 1 comments

Author's posts

Microsoft AZ-700: Exercise – Configure an ExpressRoute Gateway

Reading Time: < 1 minute

Notes from MS Learn AZ-700 Module 3: Design and Implement Azure ExpressRoute – Unit 4: Exercise – Configure an ExpressRoute Gateway

Tasks (taken from MS Learn: Items without “Task” in front of them are personal additions)

  • Task 1: Create the virtual network and gateway subnet
    • Navigate to Virtual Networks in Azure Portal
    • Click Create
      • Select Create new under Resource group dropdown
        • Enter name
        • Select OK
      • Enter Name under Instance Details
      • Select Next : IP Addresses >
        • Delete existing default address space (trash can icon next to addr range
        • Add new addr range
        • Select Add subnet
          • In right panel add subnet name
          • In right panel add subnet addr range
          • In right panel click Add
      • Select Review + create
      • Once validated select Create
  • Task 2: Create the virtual network gateway
    • Search and Click Virtual Network Gateways in Azure Portal
    • Click Create
      • Enter Name under Instance details
      • Select ExpressRoute for Gateway type under Instance Details
      • Select VNet from dropdown under Instance details
      • Enter Public Ip address name under Public IP address section
      • Click Review + create
      • Once validated click Create
      • Once complete click Go to resource
Share this article:

Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-exercise-configure-an-expressroute-gateway/

Microsoft AZ-700: Design an ExpressRoute Deployment

Reading Time: 2 minutes

Notes from MS Learn AZ-700 Module 3: Design and Implement Azure ExpressRoute – Unit 3: Design an ExpressRoute Deployment

ExpressRoute used to connect on-prem with Azure. Plan decisions prior to deployment of an ExpressRoute Circuit

  • ExpressRoute Circuit SKUs
    • Three SKUs have different charges
      • Local SKU
        • Automatically charged Unlimited Data Plan
      • Standard SKU
        • Select Between Metered or Unlimited Data Plan
          • Ingress are free except when using Global Reach
      • Premium SKU
        • Select Between Metered or Unlimited Data Plan
          • Ingress are free except when using Global Reach
    • Use Azure Pricing Calculator to estimate costs
  • Choose a Peering Location
    • Azure Region
      • Global DCs housing Azure computer/network/storage resources
      • Resource Location determins Azure DC or availability zone created in
    • ExpressRoute Location (Peering Location)
      • May be called Peering Location or Meet-me-location
      • Colo where MS Enterprise Edge (MSEE) devices live
      • Entry point to MS network – globally distributed allowing connectivity to MS network around the world
      • Where ExpressRoute partners and ExpressRoute Direct customers cross-connect to MS network
    • Azure regions to ExpressRoute location in geopolitical region
    • ExpressRoute Connectivity Provider
    • Connectivity through Exchange providers
      • If connectivity provider not listed in above, still able to create connection
      • Several providers already connected to Eth exchanges
    • Connectivity through satellite operators
      • Remote and no fiber
      • Want to explore other options
      • Other options
        • Other service providers
        • DC providers
        • National Research and Education Networks (NERN)
        • System integrators
  • Choose the Right ExpressRoute Circuit and Billing Model
    • MS various Express Route options based on desired bandwidth. Evaluate current usage as a starting point
    • Deterring ExpressRoute based on requirements: keep in mind budge/SLAs
    • Choose appropriate SKU and if applicable Metered vs Unlimited within the SKU
    • Consider ExpressRoute Direct
      • Connects network to closet MS Edge which connects to MS Global Network
      • Usage of Global MS Network charged on top of ExpressRoute Direct
    • Express Route pricing for metered and unlimited bandwidth details
    • Available in range of bandwidths – check with provider for what they support
  • Choose a billing model
    • Unlimited
      • Billing based monthly
      • All Inbound/Outbound included
    • Metered
      • Billing based on monthly fee. Inbound free, Outbound per GB
      • Rates vary by region
    • ExpressRoute Premium add-on
      • Additional Capabilities
        • Increased route limits for Azure public/private peering from 4k to 10k routes
        • Global connectivity for services. Circuit in any region (exclude national clouds) has access to resource in any other region
        • Increased VNet links per ExpressRoute circuit from 10 based on bandwidth
Share this article:

Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-design-an-expressroute-deployment/

Microsoft AZ-700: Explore Azure ExpressRoute

Reading Time: 3 minutes

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
Share this article:

Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-explore-azure-expressroute/

Microsoft AZ-700: Create a Network Virtual Appliance (NVA) in a Virtual Hub

Reading Time: 2 minutes

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
Share this article:

Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-create-a-network-virtual-appliance-nva-in-a-virtual-hub/

Microsoft AZ-700: Exercise – Create a Virtual WAN by Using the Azure Portal

Reading Time: < 1 minute

Notes from MS Learn AZ-700 Module 2: Design and Implement Hybrid Networking – Unit 7: Create a Virtual WAN by Using the Azure Portal

Tasks (taken from MS Learn: Items without “Task” in front of them are personal additions)

  • Task 1: Create a Virtual WAN.
    • Search and Select Virtual WANs in Azure Portal
    • Select Create
      • Choose Resource Group from dropdown
      • Choose Region from dropdown
      • Provide Virtual WAN Name
    • Chose Review + Create > Create after validation
  • Task 2: Create a hub by using Azure portal.
    • Navigate to new Virtual WAN in Azure Portal
      • There is a “Go to resource” button on the deployment complete page of step above
    • Selects Hubs under Connectivity in left Panel
    • Select New Hub
      • Select Region from dropdown
      • Provide Name
      • Provide Private Address Space
      • Select Virtual Hub Capacity from dropdown
      • Select Next: Site to Site button at bottom of page
        • Under Site to site settings
          • Set “do you want to create a Site to Site (VPN gateway)? To Yes
          • Select Gateway scale units from dropdown
          • Select Review + Create > Create (once validation passes
  • Task 3: Connect a VNet to the Virtual Hub.
    • Search and Select Virtual WANs in Azure Portal
    • Select the newly created Virtual Wan
    • Choose Virtual Network Connections under Connectivity in the left panel
    • Select Add Connection
      • Provide Connection Name
      • Select Hub from dropdown
      • Select Resource group from dropdown
      • Select Virtual network from dropdown
      • Toggle propagate to none to Yes
      • Select Route Table from dropdown
      • Select Create
Share this article:

Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-exercise-create-a-virtual-wan-by-using-the-azure-portal/

Microsoft AZ-700: Connect Remote Resources by Using. Azure Virtual WANs

Reading Time: 2 minutes

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
    • MS Link to more configuration details on routing: https://learn.microsoft.com/en-us/azure/virtual-wan/how-to-virtual-hub-routing
  • Hub Route Table
    • Create a virtual Hub Route and apply to Virtual Hub Route Table
    • Can apply multiple route to table
Share this article:

Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-connect-remote-resources-by-using-azure-virtual-wans/

Microsoft AZ-700: Connect Devices to Networks with Point-to-Site VPN Connections

Reading Time: 2 minutes

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
    • Mac
      • VPN config consists of mobileconfig file
Share this article:

Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-connect-devices-to-networks-with-point-to-site-vpn-connections/

Microsoft AZ-700: Connect Networks with Site-to-Site VPN Connections

Reading Time: < 1 minute

Notes from MS Learn AZ-700 Module 2: Design and Implement Hybrid Networking – Unit 4: Connect Networks with Site-to-Site VPN Connections

Site-to-Site VPN Gateway Connection creates a secure connection to VNet from another VNet or physical network

Diagram from MS Learn

  • Info based on diagram
    • On-prem network has on prem services such as AD
    • Gateway sends encrypted traffic to virtual IP when using public connection
    • VNet contains cloud apps and VPN Gateway components
    • Azure VPN Gateway provides encrypted tunnel to on-prem
      • Virtual Network Gateway
      • Local Network Gateway
      • Connection
      • Gateway Subnet
    • Internal load balance handles routing cloud traffic to proper cloud app or resource
  • Benefits
    • Simplified config and maintenance
    • Secure encrypted data/traffic from on-prem and Azure gateways
    • Allow for future network requirements
Share this article:

Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-connect-networks-with-site-to-site-vpn-connections/

Microsoft AZ-700: Exercise – Create and Configure a Virtual Network Gateway

Reading Time: 2 minutes

Notes from MS Learn AZ-700 Module 2: Introduction to Azure Virtual Networks – Unit 3: Exercise – Create and Configure a Virtual Network Gateway

Tasks (taken from MS Learn: Items without “Task” in front of them are personal additions)

  • Task 1: Create CoreServicesVnet and ManufacturingVnet
    • Open Azure PowerShell (button next to Azure Portage Search Bar)
    • Upload ARM Template and Parameters File (Upload/Download button in cloud shell menu bar)
      • Azuredeploy.json
      • Azuredeploy.parameters.json
      • View and set subscription
        • Az account show –output table
        • Az account set –subscription “Subscription Name”
      • Set new resource group variable
        • $RGName = “NewResourceGroupName”
        • New-AzResourceGroup -Name $RGName -Location “eastus” – Tag value1 -Force
      • Deploy ARM template for subnets and resources needed
        • New-AzResourceGroupDeployment – ResourceGroupName $RGName – TemplateFile armtemplatename.json -TemplateParameterFile armtemplatename.parameters.json
  • Task 2: Create CoreServicesTestVM
    • Upload ARM Template and Parameters File (Upload/Download button in cloud shell menu bar)
      • Azuredeploy.json
      • Azuredeploy.parameters.json
    • Deploy ARM template for subnets and resources needed
      • New-AzResourceGroupDeployment – ResourceGroupName $RGName – TemplateFile armtemplatename.json -TemplateParameterFile armtemplatename.parameters.json
  • Task 3: Create ManufacturingTestVM
    • Upload ARM Template and Parameters File (Upload/Download button in cloud shell menu bar)
      • Azuredeploy.json
      • Azuredeploy.parameters.json
    • Deploy ARM template for subnets and resources needed
      • New-AzResourceGroupDeployment – ResourceGroupName $RGName – TemplateFile armtemplatename.json -TemplateParameterFile armtemplatename.parameters.json
    • Verify VM Created
      • Search Virtual Machines in Azure Portal
      • Select Virtual Machines
  • Task 4: Connect to the Test VMs using RDP
    • Select VM and note Private IP
    • Return to VMs page
    • Select the second VM
      • Select Connect > RDP
      • Select Download RDP File
      • In right panel select Open File to connect to VM
      • Select Connect
        • Enter credentials
        • Select OK
  • Task 5: Test the connection between the VMs
    • Search for PowerShell on VM in RDP Session and open
    • Verify no connectivity to other VM
      • Test-NetConnection X.X.X.X (noted IP of other VM) -port 3389
      • Output should contain TcpTestSucceeded : False
      • Close RDP Session
  • Task 6: Create CoreServicesVnet Gateway
    • Search and Select Virtual Networks in Azure Portal
    • Select first VMs VNet
      • Under Settings select Subnets
        • Note ARM template created GatewaySubnet
    • Search and select Virtual Network Gateway in Azure Portal
      • Select Create
        • Enter Name
        • Select Region
        • Select SKU and Generation
        • Select Virtual Network
        • Enter Gateway subnet address range
        • Enter Public Ip address name
        • Enable or Disable active-active mode per desired deployment
        • Select Review and Create
        • Select Create
  • Task 7: Create ManufacturingVnet Gateway
    • ManufacturingVnet does not have a GatewaySubnet and will be created while creating the gateway
    • Navigate to virtual network gateways in Azure Portal
    • Select Create
  • Task 8: CoreServicesVnet to ManufacturingVnet
    • Navigate to Virtual Network Gateways in Azure Portal
    • Select the first VNet used earlier
      • Select Connections under settings
      • Select Add
        • Enter Name
        • Chose the Second Virtual Network Gateway
        • Enter PSK
        • Select OK
  • Task 9: Connect ManufacturingVnet to CoreServicesVnet
    • Navigate to Virtual Network Gateways in Azure Portal
    • Select the second VNet used earlier
    • Select Connections under settings
    • Select Add
      • Enter Name
      • Chose the Second Virtual Network Gateway
      • Enter PSK
      • Select OK
  • Task 10: Verify that the connections connect
    • Search for and select Connections in Azure Portal
    • Click Refresh
    • Both show Connected
  • Task 11: Test the connection between the VMs
    • Navigate to Virtual Machines in Azure Portal
    • Select Second VM created
      • Select Connect > RDP
      • Test connectivity in PowerShell
        • Test-NetConnection X.X.X.X (IP of first VM) -port 3389
        • Output should show TcpTestSucceeded : True
Share this article:

Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-exercise-create-and-configure-a-virtual-network-gateway/

Microsoft AZ-700: Design and Implement Azure VPN Gateway

Reading Time: 6 minutes

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
    • When not listed contact manufacturer for support/configuration help
    • There may be pre-build configuration scripts available
    • Required
      • Shared Key
      • Public IP address of VPN gateway
  • Create VPN Connection
    • Once VPN Gateways created connection between them can be created
    • If VNets are in the same subscription you can use the portal
      • Under Add Connection
        • Name connection
        • Select Connection type – Site-to-Site
        • Enter the Pre-shared Key
  • Verify VPN Connection
    • Use either Portal or PowerShell
  • High Availability options
    • VPN Gateway Redundancy (Active-Standby)
      • Every Azure VPN Gateway has active-standby
      • Automatic failover for planned maintenance or unplanned outages
        • Brief interruption
      • For planned restoration usually in 10-15 seconds (site-to-site)
      • For unplanned restoration around 1-3 minutes (site-to-site)
      • Point-to-Site connections are disconnect and users need to reconnect
    • Multiple on-prem VPN devices
      • Requirements and Constraints
        • Need multiple Site-to-Site VPN connections from VPN devices to Azure created
          • When connecting multiple VPN devices from same on-prem to Azure one local network gateway required for each VPN device
          • One connection from Azure VPN Gateway to each local network gateway
        • Local Network Gateways corresponding to VPN devices must have unique public IP in the GatewayIpAddress property
        • BGP required
          • Each local network gateway reping a VPN device must have unique BGP peer IP specified in BgpPeerIpAddress property
          • Use BGP to advertise same prefixes of same on-prem network prefixes to Azure VPN Gateway – traffic forwarded through these tunnels at same time
        • Must use ECMP
        • Each connection counts against max number of tunnels for Azure VPN Gateway
          • 10 for Basic and Standard SKU’s
          • 30 for HighPerformance SKU
      • Stil active-standby but guards against failures/interruptions on on-prm network and VPN devices
    • Active-Active Azure VPN Gateway
      • Both Azure VPN Gateways create Site-to-Site tunnels to on prem VPN device
      • Each Azure gateway has unique public IP and establishes Ipsec/IKE Site-to-Site VPN tunnel to on-prem VPN device
      • Configure on-prem VPN device to accept 2 Site-to-Site VPN tunnels two the 2 Azure VPN Gateway public IP’s
      • Traffic from Azure VNet to on-prem network routed through both tunnels
      • For single TCP/UDP flow Azure attempts to use same tunnel
    • Combo of both
  • Dual-redundancy: active-active for both Azure and On-Prem Networks
    • Create and setup Azure VPN Gateway in active-active
    • Create two local network gateways and two connections for 2 on-prem VPN devices
    • Makes full mesh connectivity of 4 Ipsec tunnels between Azure VNet and on-prem network
    • All gateways and tunnels are active from Azure side so traffic spread across 4 tunnels
    • May result in better throughput
    • BGP required
  • Highly Available VNet-to-VNet
    • Follows same idea as Azure to on-prem active active
    • Only requires on connection for each gateway
    • BGP optional unless transit routing required
  • Troubleshoot Azure VPN Gateway Using Logs
    • Use of logs to troubleshoot such as
      • Configuration Activity
      • VPN Tunnel Connectivity
      • IPSec
      • BGP Route Exchanging
      • Point-to-Site Advanced Logging
    • Example Logs
      • GatewayDiagnosticLog
        • Configuration events, primary changes, maintenance events
      • TunnelDiagnosticLog
        • Tunnel state changes
        • Connect/Disconnect events summarized reasons if applicable
      • RouteDiagnosticLogs
        • Changes to Static and BGP routes
      • IKEDiagnosticLog
        • IKE control messages and events on gateway
      • P2SDiagnosticLog
        • Control messages and events on gateway
Share this article:

Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-design-and-implement-azure-vpn-gateway/

Load more