Azure Networking - The First Technical Challenge

© Cloud Mechanix 2020 www.cloudmechanix.com
Azure Networking
The First Technical Challenge
Aidan Finn, MVP
Cloud Mechanix & Innofactor Norway

• 13 year MVP – currently Microsoft Azure
• Previously Hyper-V and SCCM
• Owner of Cloud Mechanix
• Custom-written Azure training
• Principal Consultant for Innofactor Norway
• Azure infrastructure – networking & security
• Working as consultant/sys admin since 1996
• Windows Server, Hyper-V, System Center, desktop managment, and Azure
• http://aidanfinn.com
• http://innofactor.com
• http://www.cloudmechanix.com
• @joe_elway
Aidan Finn
Introduction

Why You Should Care

• Azure networking is always present
• Obvious scenarios:
• Virtual machines (IaaS)
• Less obvious scenarios:
• Platform-as-a-Service (PaaS)
• Connecting across the Internet
• Playing a bigger role than ever in PaaS:
• Governance & security frameworks
• Private Link / Private Endpoint
• Compliance
• Performance
• Azure Front Door, Azure Peering Service
Networking Is Always Relevant
Even with PaaS

• Define strategy
• Engage with the business
• Plan
• High-level assessments
• Ready the organisation
• Govern & Manage
• Build the scaffolds
• Ready
• The landing zone
• AZURE NETWORKING!
• Adopt
• Use what you built
The First Technical Challenge
The Microsoft Azure Cloud Adoption Framework

Scalability

Microsoft Global Network
Connecting all Microsoft cloud services
• Over 165,000 miles of
backbone cable
• Over 170 edge data centers
• Over 60 Azure regions
• And you use this:
• To connect to Azure Portal,
Office 365, Xbox Live, etc
• And you can use this, even
for a “small” service

Ready – VNet Basics

• VNets are needed for virtual machines
• Platform services are often built using VMs under-the-covers
• Some PaaS resources have VNet integration abilities
• App Service Environment (ASE)
• SQL Managed Instance
• API Management
• Compliance/governance/security pulling PaaS to the virtual network
• Private Link / Private Endpoint
Virtual Network Scenarios
Not just VMs/IaaS

• An abstraction of physical network
• Data transmission is encapsulated on a physical network
• A memory transfer between physical hosts
• Many network functions a virtualised in the fabric
• There is no Default Gateway
• You can’t ping it
• Handled in the fabric:
• Routing
• Load balancing
Virtual Network (VNet)
Software Defined

• Virtual Network
• Address space
• 1 or more CIDR blocks
• Parts or whole assigned to subnets
• DNS
• Azure default or chosen DNS servers for resources attached to the Vnet
• Subnets
• 1 or more subnets per Vnet
• Some Azure resources require exclusive use of a subnet
• Name
• A human friendly name, sometimes forced by Azure resources
• Address space
• A whole or part of a VNet address space
• Default Gateway
• A representation of a first hop “router”
• It does not exist – does not respond to ICMP (ping or tracert)
Virtual Network Components
What makes up a VNet
VNet
1:
10.1.0.0/16
DNS
Default Gateway

• Public IP address
• Connects an Azure resource to the Internet
• Address assigned by Azure
• Stays with the resource while it is allocated
• Some PIPs can be statically assigned, e.g. virtual machines/appliances NICs
• See public IP address prefix
• Private IP address
• From the address pace of a subnet
• It looks like DHCP but it is not DHCP (no broadcasts in Azure VNets)
• Address remains assigned while the resource is allocated
• Some resources allow the address to be statically assigned, e.g. VM/appliance NICs
• Not directly routable on the Internet
IP Address Types
Public and private
https://docs.microsoft.com/azure/virtual-network/public-ip-address-prefix

• There is support for IPv6 in Azure
• Very limited, including:
• Virtual networks
• Virtual machines
• Most critical services do not support IPv6
• It’s an IPv4 world!
IPv6 Support
It’s the year of … STOP THAT!
https://docs.microsoft.com/azure/virtual-network/public-ip-address-prefix

Virtual Machines

VNet DNS:
• 208.67.222.222
• 208.67.220.220
Virtual Machine IP Configuration
Automatic action by the VNet when the VM powers up
VNet:
10.0.0.0/16
Subnet 1: 10.0.0.0/24
VM1 IPconfig1:
• IP: 10.0.0.4
• Subnet mask: 255.255.255.0
• Default Gateway: 10.0.0.1
• DNS1: 208.67.222.222
• DNS2: 208.67.220.220
Guest OS DHCP Configuration:
• IP: 10.0.0.4
• Subnet mask: 255.255.255.0
• Default Gateway: 10.0.0.1
• DNS1: 208.67.222.222
• DNS2: 208.67.220.220
Automatic subnet Addresses:
• Default gateway: 10.0.0.1
• Default DNS1: 208.67.222.222
• Default DNS2: 208.67.220.220
• Next VM address: 10.0.0.5

• Dynamic by default
• A VM will pick up the first available address on the subnet
• DO NOT EDIT THE GUEST OS NETWORK CONFIGURATION
• Set the IPconfig of the Azure vNIC to static
• The guest OS will remain as a DHCP configuration
• DNS
• You can override with VNet DNS settings in the NIC Azure resource
Private IP Address Notes
Things to know

• Azure offers networking features in the platform:
• Layer-7 load balancing
• Web Application Firewall (WAF)
• Network Firewall
• Site-to-Site connectivity/routing
• Software-Defined WAN (SD-WAN)
• But third-parties are in the Marketplace
• Run as Linux virtual machines
• The complexity of IaaS
• Often no high availability
• No propagation of routes into Azure VNets
Network Virtual Appliances (NVAs)
3rd party networking appliances

• A shared frontend
• Performs two functions:
• Load balancer (Layer 4) application
servers
• Create NAT rules
• Can be used for:
• External (Internet) load balancing &
NAT
• Internal (VNet) load balancing
• Platform services also use the Load
Balancer
Azure Load Balancer
A function of the Azure fabric

Public IP Addresses

• A publicly routable public IP address (PIP)
• Can be associated to an Azure resource
• Not just virtual machines
• Can have a Microsoft-managed DNS name
• Must form a globally unique fully qualified domain name
• No charge
• I typically recommend configuring this
• Is dynamic by default
• Address is returned to Azure for reuse when the associated resource is
deallocated (stopped)
• Some resource types do not support changing the PIP to static
Public IP Addresses
Make Azure resources available on the Internet
https://docs.microsoft.com/azure/virtual-network/virtual-network-public-ip-address

• Azure Portal next>next>net
• A public IP address is associated with
the NIC of the VM
• 1 PIP for each VM
• Pros:
• Easy - it’s what the Azure Portal does
• Cons:
• Doesn’t scale well (at all)
• Hard to manage/secure
• Wasted money
• Impossible to do load balancing/scale-
out
Per-Virtual Machine PIP
Classic rookie mistake
Internet
Virtual machine
Network card
Virtual Network
Public IP Address Private IP Address
Virtual machine
Network card
Virtual machine
Network card
Virtual machine
Network card
https://docs.microsoft.com/azure/virtual-network/virtual-network-ip-addresses-overview-arm

• Azure Bastion
• A platform gateway
• Azure Portal/Azure AD
• Azure Security Center Just-In-
Time VM Access
• VM-based Gateway
• Citrix
• Remote Desktop
• Guacamole
Securing RDP/SSH to VMs
Don’t open up TCP 3389/22

Internet Services

• Legacy systems require legacy connectivity:
• Site-to-site networking
• RDP/SSH
• Client-server latency can be an issue
• Modern systems are built with HTTPS “clients”
• Already secure & private
• Don’t suffer from client-server latency
• Logical choice is to share the services over the Internet
• With authentication/authorisation
• Accessible from anywhere (subject to conditional access controls)
• Ideal for partner/customer/supplier/roaming/work-from-home scenarios
Modern Service Deployment
Preference to access over Internet via HTTPS

• Microsoft partnership with ISPs
• Enhances connectivity to Microsoft cloud
services over the Internet:
• M365
• Dynamics 365
• Azure
• Partners:
• ISPs
• Internet Exchange Partners
• Software-defined cloud interconnect
providers
• Features:
• High availability
• Low latency
Azure Peering Service
Enhancing public connectivity

• Frontend:
• Features include:
• Single site / Multiple sites
• Ingress controller for AKS
• SSL offload
• Re-encryption (end-to-end)
• Automatic scaling
• Services on:
• VMs
• VM Scale Sets
• Azure App Services
• Azure Kubernetes Services (AKS)
• Any valid “endpoint”
Azure Application Gateway
Platform-based HTTP/S load balancing

• Hosted in Microsoft “Edge Data
Centers”
• Over 170 around the world
• Provides clients with close-by entry
point to Microsoft WAN
• Reduce latency to reach the service
• Scale-out at regional level
• Use cases include:
• Lower latency connections to
interactive services
• Scale-out
Azure Front Door
Leveraging the Microsoft WAN for HTTP/S services

• A lot of HTTP GETs are for static
content
• Does that request/content need to:
• Travel all the way to/from the web
server?
• Consume web server
CPU/RAM/network?
• Geo-cache static content close to
the client
• Design the app to redirect static
requests to the CDN
• Interactive requests go to the web
server
Azure Content Delivery Network (CDN)
Geo-sharing of static web content

• Not restricted to HTTP/S
• Load balance services in multiple
regions
• Direct traffic to region “closest”
to the client
• Instant global failover
• Nested load balancers
• Ability to scale up/down
The Azure Load Balancer
Cross-region load balancing

• Enables multi-region
deployment for:
• Scale-out
• Performance
• A-B deployments
• DNS based:
• Service DNS points to Traffic
Manager profile
• Traffic Manager profile resolves to
next endpoint
Traffic Manager
DNS-based redirection

Private Remote Connections

• Legacy systems
• Azure VMware Services
• ADDS replication
• Legacy systems with on-premises integrations
• Compliance
• Some nations/industries require private (even encrypted) network channels
• Service Level Agreement
• Microsoft cannot give you an SLA on the Internet
• Private connectivity providers can
• “An SLA is not a promise of uptime – it’s a promise of compensation”
Private Remote Networking
Still required in The Cloud

• A third-party appliance acts as a router
• Public IP Address
• Supports VPN connections
• Site-to-site
• End user (point-to-site)
• Pros:
• Might support IPv6
• Might have some features not in Azure
• Cons:
• Usually a single appliance with no HA
• Cannot propagate routes into the virtual network
• Multi-vendor support issues
Connection Options
Third-Party Network Virtual Appliance (NVA)
Azure Firewall
AzureFirewallSubnet
AzureGatewaylSubnet
Hub
Virtual
Network
Spoke VirtualNetwork Spoke VirtualNetwork Spoke VirtualNetwork
VirtualNetwork
Peering
VirtualNetwork
Peering
buildin
NVA

• Point-to-Site (P2S) VPN
• A client device
• Clients: Azure VPN & Open VPN
• Authentication: Certificate & RADIUS
• Site-to-Site (S2S) VPN
• Private encrypted tunnel over the Internet
• Cheap
• Wide range of supported on-premises appliances
• No SLA
• ExpressRoute
• Connection to Microsoft Edge Data Center supplied by service provider
• Low latency
• SLA by the service provider
• Various architectural features *
Types of Azure Supported Connections
Depending on client and requirements
* Introduction to Azure ExpressRoute

• Platform based appliance
• Highly available
• Active/passive
• Active/active
• Zonal/zone redundant in available regions
• Propagates routes into the VNet as BGP
• Supports:
• P2S VPN
• S2S VPN
• ExpressRoute
• Including HA with S2S or S2S inside ExpressRoute
Connection Options
Azure Virtual Network Gateway
Azure Firewall
VirtualNetwork Gateway
AzureFirewallSubnet
AzureGatewaylSubnet
Hub
Virtual
Network
Spoke VirtualNetwork Spoke VirtualNetwork Spoke VirtualNetwork
VirtualNetwork
Peering
VirtualNetwork
Peering
buildin

• Typically associated with SD-WAN
• SD-WAN is not a requirement!
• Features:
• Simplifies complex architectures
• Reduced Azure routing
• Any-to-any transit connections
leveraging the Microsoft WAN
• Integrations with SaaS security vendors
• Supports combinations of P2S, S2S,
and ExpressRoute
• New variant with third-party router
appliances in preview
Connection Options
Azure Virtual WAN
VirtualWAN
VirtualHub
West Europe
VirtualHub
North Europe
HQ
Branch Office
S2S VPN
Gateway
ExpressRoute
Gateway
P2S VPN
Gateway
Spoke VirtualSubnets Spoke VirtualSubnets
Firewall Firewall
FirewallManager

Network Security

You Still Need Firewalls!
The Cloud changes nothing here

Micro-Segmentation
What could/should have been done on-premises
Firewall
Virtual Network
Network Security
Group
Virtual Network
Network Security
Group
Virtual Network
Network Security
Group
East
-
West
North - South
SQL Server
VirtualMachineWindows
Storage Account Table

• Some (expensive) SKUs offer VNet integration
• Most (and soon all) resources will have Private Link /Private Endpoint
• Private Link
• Enables a resource to connect to a VNet using a Private Endpoint
• A PaaS resource:
• Connects to a VNet subnet to receive stateful connections
• Has a NIC with a private IP address in the subnet
• FQDN provided by a designated Azure Private DNS zone
• Can be isolated from “Internet”
Platform Resources
This is relevant to you too!

• Many resource types have a final layer of network security
• Guest OS firewall
• Allow/deny connection
• Virtual machines
• Resource firewall
• Allow/deny connection
• Examples: Storage Account, Key Vault, Azure SQL Server
• Access Rules
• Allows connection, but can allow/deny service
• Example: App Service
Protection at the Resource
Various kinds

• Stateful firewall associated with
• NICs (not recommended)
• Subnets (recommended)
• Rules:
• Inbound/outbound
• Allow/deny
• Priorities
• Service tags to abstract Azure service
Ips
• Logging
• Flow logs to storage accounts
• Traffic Analytics in Log Analytics
Network Security Groups
Basic form of firewall in Azure

Azure DDoS Protection Options
In the VNet and the WAF
https://docs.microsoft.com/azure/virtual-network/ddos-protection-overview

• Provide central point of network security
• Typically seen in scaled-out environments
• Hub & spoke VNet architectures
• Centralised deployment of public IP addresses
• Edge security maintained by IT security, not Devs/Ops
• Options
• Third-party NVA (IaaS)
• Azure Firewall (Platform) – including Azure WAN Secure Virtual Hub
• My preference to focus on security, not Iaas maintenance, and management as code
Network Firewall
North-south and east-west isolation

• Add-on to:
• Azure Application Gateway
• Azure Front Door
• Provides application layer security:
• Volumetric attacks
• Protocol attacks
• Resource/application-layer attacks (DDoS Standard Tier)
Web Application Firewall
Protection of HTTP/S services

PaaS Private Connections

• Hybrid connections
• From (outbound HTTPS tunnel) a VM agent to a PaaS/SaaS resource
• Examples: Power BI online, Azure Data Factory, Azure App Services/Functions
• VNet connections
• Outbound connectivity, e.g. App Services
• Network integration
• Private IP, e.g. App Service Environment, SQL MI, API Management
• Private Link/Private Endpoint
Options
PaaS can require compliance/security too

• Private endpoint
• NIC that allows inbound only
connections
• And stateful replies
• Assigned to a PaaS resource
• Including Azure load balancer!
• Clients connect to IP via new DNS
name
• mysa.privatelink.blob.core.windows.n
et instead of
mysa.blob.core.windows.net
• Configure Azure Private DNS –
forward requests to (Azure Firewall,
DNS server) to 168.63.129.16
Private Link / Private Endpoint
Use private IP addresses

Troubleshooting

• Software-defined network
• Traceroute is nearly useless
• Resource logging: storage account (JSON/blob), Event Hub, Log
Analytics
• Especially Azure Firewall and NSG Traffic Analytics logs
• Configure on day 0
• Azure Monitor Insights
• Connection Monitor
• Network Watcher tools
• PowerShell (Windows Guest OS) Test-NetConnection
Tools
Subject to regional availability & possible cost

Wrap Up

• http://aidanfinn.com
• http://www.cloudmechanix.com
• http://www.innofactor.com
• @joe_elway
Thank You!
Aidan Finn, Cloud Mechanix

Azure Networking - The First Technical Challenge

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Azure Networking - The First Technical Challenge

Similar to Azure Networking - The First Technical Challenge (20)

More from Aidan Finn

More from Aidan Finn (20)

Recently uploaded

Recently uploaded (20)

Azure Networking - The First Technical Challenge