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
I didn’t take the greatest of notes for this free self-paced course (FCA – FortiGate 7.4 Operator Self-Paced) and free exam but I’ll share the shorthand notes that I did take down below:
Overview
NGFW
Antivirus
Web Filter
IPS
FortiOS
Security Processing Units (SPUs)
Models:
Fortigate VM
Entry Level – FG-80F, FWF-80F
Mid-range – FG-100F, FG-1000F, FG-4200F
High-end – FG-4800F, FG-7081F, FG-7121F, FG-5114C
Features:
Firewall Auth, local and remote
VPN
Security Scanning: antivirus, web filtering, app control
Monitoring and logging
Fortinet Security Fabric
FortiGuard Labs – threat intelligence and security research
Trusted machine learning and AI
Realtime thread intelligence
Threat hunting and outbreak alerts
Configuring Interfaces and Routing
Alias – name for ref
IP Address
Administrative Access (HTTPS, PING, SSH, ETC)
DHCP Servers
DHCP Server
Address Range
Mask
Default. Gateway
DNS Server (by default same as used by fortigate
Static Routing:
Default route to gateway for internet
Destination – Used to match incoming traffic to the correct route
Gateway – IP address Fortigate forwards traffic to
Interfaces – Interface FortiGate uses to forward traffic towards destination
Distance, Priority
Default Route – when no exact destination
Monitoring Static Routes:
Network > Static Route
Reasons may prevent route from being added to table:
Misconfigured route
Port associated with route is down or disabled
Better route to use for destination
To check routing tabled:
Dashboard > Network > Static and dynamic routing
Firewall Policies
Sets of rules to control whether traffic is accepted by FortiGate and how it processes it
Match based on:
Incoming and outgoing. Interfaces
Source: IP or User
Destination: IP or Internet Service
Service: Destination port
Schedule
Action:
Accept
Deny
IP Subnet:
Create a firewall address that corresponds to the IP subnet address
Can also create firewall address for a specific device
Source/Destination:
Default “ALL” option available for both source/dest to match all possible IP addresses
Internet Service:
Select from ISDB (Internet service database)
Policy Table:
Contains all rules. Top down
If no match default deny
Place most specific policy rules at top as it’s first match
Accepted Traffic:
Next is other features such as antivirus, web filtering
Applies NAT and logs based on policy settings
Inspection modes:
Flow based – examines file as passes through without buffering
Proxy based – buffers and examines as a whole – more thorough but slower due to buffering
Authenticating Network Users
Require users to authenticate to access network resources
Add source user or user group to policy
Methods:
Local password (individuals and groups)
Guest groups expire after time including auto generated accounts
Remote password authentication
Local Authentication Steps:
Create user account
Create user group
Add user group as source to policy
Verify and monitor
Remote Authentication Steps:
Connect FortiGate to remote server
Create user group and map remote auth users to group
Add group as source to policy
Verify and monitor
Inspect SSL Traffic
Certification Inspection:
Inspects the SSL/TLS Handshake
Verifies identity of web server
Used only with web filtering
Only used security feature is web filtering
Causes certificate warning only when fortigate displays an encrypted replacement message
Deep Inspection:
Like man-in-the-middle also causes certificate errors in browser
Decrypts incoming traffic to inspect
Re-encrypts to send if safe
Used with all types of security scanning
Can be used with things such as SMTPS, POP3s, IMAPS, FTPS
Preloaded SSL Inspection Profiles:
Certificate-inspection – read only profile
Deep-inspection – read only profile
No-inspection – read only profile
Deep-inspection
Edit custom-deep-inspection or Clone or Create your own profile
Certificate Warnings
Certificate warnings occur when fortigate encrypts traffic using self-signed certificate
Fortigate uses it’s own CA certificate to re-encrypt
To avoid
Download fortinet CA certificate and install into clients
Use CA certificate and install into browsers
Blocking Malware
FortiGuard Labs provides database of signatures
Schedules for updates
Antivirus Scan
Detects known malware – first fastest simplest – exact match in database
Grayware Scan
Detects unsolicited programs installed with user knowing or consent – uses fortiguard grayware signature
Machine Learning/AI Scan
Used to detect zero day attacks for new/unknown signatures
Notes from MS Learn AZ-700 Module 1: Introduction to Azure Virtual Networks – Unit 10: Configure Internet Access with Azure Virtual NAT
NAT came out of aa need for internal resources on private networks to gain access to external resource on a public network with public IPv4 addresses being in short supply. NAT is an alternative to a public IP for each internal resource and allows multiple resources to share a single public IP.
NAT provides mapping a single IP or range of IP (defined by prefixes) and ports. It is compatible with the Azure standard SKU for public IP address resources or public IP prefix resources (or both). Use a public IP prefix directly or distribute address from that prefix with multiple NAT gateway resources. NAT maps all traffic to the range of IP’s in that prefix. Flows are created outbound and inbound traffic is only allowed for an active flow.
Defined for each subnet within a VNet by specifying with NAT gateway resource to use. Once configured, UDP and TCP outbound flows from an VM will utilize NAT for internet connectivity with no further configuration needed. No need for user-define routes. NAT takes over other outbound and replaces the default Internet destination of the subnet
Support dynamic workloads y scaling NAT
No need for extensive preplanning or. Preallocation of addresses – NAT scales to support dymaic workloads
Using Port Network Address Translation (PNAT/PAT) allows up to 64000 concurrent flows for both UDP and TCP (each)
Supports up to 16 public IP addresses
Deploying NAT
Create regional or zonal (zone-isolated) NAT Gateway Resource
Assign IP addresses
Modify TCP idle timeout if needed (optional)
Coexistence of inbound and outbound
NAT compatible with following standard SKU resources
Load Balancer
Public IP Address
Public IP Prefix
NAT and the SKU’s aware of direction flow started – inbound and outbound can coexist
Limitations
Compatible with standard SKU Public IP, Public IP Prefix, Load Balancers but no basic SKU’s
IPv4 only with NAT. Can’t be on a subnet with an IPv6 prefix
Notes from MS Learn AZ-700 Module 1:Introduction to Azure Virtual Networks – Unit 9: Implement Virtual Network Traffic Routing
Azure automatically creates route tables for each subnet in a VNet and adds system default routes. Override some Azure system routes with custom routes, add more custom routes to a table. Azure routes outbound based on the routes in the subnets route table
System Routes
Azure automatically creates system routes in each subnet in a VNet
You cannot create or remove system routes
Override with custom routes
Default Routes
Each route contains address prefix and next hop type
When VNet is created Azure creates the following default system routes for each subnet within a VNet (Table taken from MS Learn)
Next Hop Types
Virtual Network
Routes traffic between address ranges within address space of VNet
Created for each address range created within a VNet
Azure automatically routes traffic between subnets in a range
Internet
Routes traffic by address prefix to internet
Default 0.0.0.0/0 for anything that isn’t in a specific range or Azure servicce
Can override with custom routes
None
Traffic is dropped
Azure automatically creates default routes for RFC 1918 and RFC 6598 (100.64.0.0/10)
Optional Default Routes
Azure adds default system routes for Azure capabilities enabled. Optional default route to either specific subnets within VNet or all subnets in VNet.
Potential Azure added routes and types (table taken from MS Learn)
Next Hop Types
VNet Peering
When peering created between two VNets route added for each address range within the space of each VNet
Virtual Network Gateway
When virtual network gateway added to VNet Azure adds one or more routes of this type. Source is VNet Gateway because gateway adds route to the subnet
Limits to number of routes propagated to an Azure Virtual Network Gateway so summarize on prem routes to largest address ranges possible
VirtualNetworkServiceEndpoint
Azure adds public IP address for certain services when enabling a service endpoing to a service
Enabled for individual subnets within a VNet – only added to route table of subnet the service endedpoing is enabled for
Public address for Azure services change – Azure updates route table as needed
VNet Peering and VirtualNetworkServiceEndpoint next hop only added to subnet route table created through Azure Resource Manager deployment model – Not added to those created through classic deployment model
Custom Routes
Used to override default routes Azure creates using user-defined routes (UDR). Think when you want traffic to route through a FW
User-defined Routes
Custom (static) route to override Azure default system routes or add other routes to subnet route table
Subnet can have zero or one route table associated
When route table created and associated – combines with or overrides default routes Azure adds to subnet
Can specify next hop type when creating
Virtual Appliance
VM running a network app such as FW
When creating route with next hop type Virtual Appliance specify next hop IP
Private IP of NIC on VM
Private IP of Azure internal load balancer
Virtual Network Gateway
Specify when traffic desired to be destined for specific address prefix to route to a virtual network gateway
Virtual Network Gateway must be type VPN
None
Specify when dropping traffic to a prefix is desired
Virtual Network
Specify when overriding default routing in VNet is desired
Internet
Specify when traffic to a specific prefix is desired destined to Internet
Configuring User-Defined Routes
Create a Routing Table
Name
Subscription
Resource Group
Location
Optional – Decide to use Virtual Network Gateway Route Propagation
With this routes automatically added to route table for all subnets that it’s enabled
Create a Custom Route
Name
Destination Type
Destination IP Addresses/CIDR ranges
Next Hop Type
Next Hop Address
Associate Route Table
Select VNET
Select Subnet
Secure a VNet using forced tunneling
Redirect all Internet-bound traffic back to on-prem via Site-2-Site VPN
If not used Internet bound traffic travels of Azure direct to internet
Configured using Azure PowerShell – can’t be done via Azure Portal
Configuring forced tunneling
VNet Subnet has built-in system routing table with three groups of routes
Local VNet Routes
Direct to destination VM in same VNet
On-premises Routes
Route to Azure VPN gateway
Default Route
Direct to internet
Configure Azure Route Server
Azure Route Server for simplified dynamic routing between network virtual appliance (NVA) and VNet
Fully managed service with HA
Simplied configuration, management and deployment of NVA
No manual update to routing table on NVA needed when VNet addresses updated
No manual updates needed to User-Define Route when NVA announces new routes or removes routes
Peer multiple instance of NVA with Azure Route Server
Interface between NVA and Azure Route Server on common standard protocol – BGP
Deploy in any new or existing VNet
View Effective Routes in Azure Portal
Search for VM in Portal
Select VM
Select Networking in the settings
Select the NIC
Select Effective Routes under the “Support + Troubleshooting” section in the settings panel
Notes from MS Learn AZ-700 Module 1: Introduction to Azure Virtual Networks – Unit 8: Exercise – Connect Two Azure Virtual Networks Using Global Virtual Network Peering
Tasks (taken from MS Learn: Items without “Task” in front of them are personal additions)
Task 1: Deploy the infrastructure.
Create VMs
Open Azure Cloud Powershell (button next to search bar in Azure Portal)
Upload template and parameters files (Upload/Download button in Powershell bar)
View account/subscription information and set variable
az account show –output table
az account set –subscription “AZ subscription name”
Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-exercise-connect-two-azure-virtual-networks-using-global-virtual-network-peering/
Notes from MS Learn AZ-700 Module 1: Introduction to Azure Virtual Networks – Unit 7: Enable Cross-Virtual Network Connectivity with Peering
VNet peering allows you to connect separate VNets in same Azure region (VNet Peering) or different regions (Global VNet Peering).
Traffic between peered is private and appears as one for connectivity purposes. Traffic between VMs in peered VNets use MS backbone infrastructure – no internet, gateways, encryption needed
Terms:
Regional VNet Peering – wihin same region
Global VNet Peering – VNets in difference regions peered
Can be in any Azure public cloud region
Can be in any China cloud region
CANNOT be in Government cloud region
Only VNets in same region peerable in Government cloud regions.
Benefits:
Low latency, high bandwidth connection between resource in different VNets
Ability for network security groups in either VNet for blocking purposes
Ability to transfer data between VNets in different subscriptions, MS Entra tenants, deployment models, and regions
Ability to peer VNets created using Azure Resource Manager
Ability to peer VNet created in Azure Resource Manager with one created through classic deployment model
No downtime to resource when creating peering or when peering creation is complete
Steps to configure VNet Peering:
Create 2 VNets
Peer VNets
Create VMs in each VNet
Test communication between VMs
Configuration done through the “Add peering” page. When peering is added on 1 VNet it is automatically added to second VNet
Gateway Transit and Connectivity
VNets are peered – Configure a VPN gateway in them as a transit point. In this case peered VNet uses remote gateway to access other resources.
VNet can have only one gateway. Gateway transit support for both VNet and Global VNet peerings
When. Gateway Transit allowed VNet can access resource outside of peering – examples
Site-2-Site VPN to on-prem
VNet-2-VNet connectivity to another VNet
Point-2-Site VPN to client
Allows peered VNets to share gateway for resource access
Service Chaining to direct traffic to gateway
Create user defined route directing traffic from one VNet to network virtual appliance in another
User defined routes point to VM in another VNet as next hop or a virtual network gateway
Can be utilized to create a hub and spoke topology
