Onboarding : Azure Infrastructure

key concepts

  • Azure Virtual Network
  • Subnet
  • Virtual VPN Gateway
    • is deployed in virtual network
    • uses IPsec IKE S2S encyption
    • only one VPN gateway in each virtual network
    • uses one gateway to connect to multiple location in azure and on-prem
      • both types use pre-shared key as the only method of authentication
      • both types rely on IKE (Internet Key Exchange) for security & encryption agreement between endpoints and IPsec (Internet Protocol Security) encrypt and decrypt the packets.
  • Virtual VPN Gateway Connectivity:
    • Connect on-prem datacenter azure virtual network through site-to-site
    • Connect individual device to azure virtual network through point-to-site
    • Connect azure virtual network to other azure virtual network
  • Network security group (NSG)
  • Application security group (ASG)
  • Virtual Network Service Endpoint
  • ExpressRoute & Circuite
  • Service Endpoints
  • VPN: is a type of interconnected network, uses encrypted tunnel, connects two or more trusted private networks to one another over an untrusted netwotk (internet).

Connect on-premises network to azure by using site-to-site VPN gateway

Key concepts

  • Virtual Network
  • Subnet
    • Default
    • GatewaySubnet /27 -> is used for VPN Gateways
  • Public IP Address -> is used for VPN
  • Local Network Gateway -> represents the on-premises network
  • Virtual Network Gateway
    • VPN (Virtual Private Network)
      • Policy-based
      • Route-based
    • Expressroute
  • Connection -> to connect local network gateway to virtual network gatzteway.
  • Endpoint -> this topic is discussed 000
  • Poblic IP address
  • Local Network Gateway
  • VPN connection

Scenario: Healthcare providers can use VPN to share sensitive data

Virtual VPN Gateway Types
Policy-based: specifies statically the IP address behind each tunnel and encryption method for the packets, this type of device evaluates every data packet for the IP address to choose the right tunnel for sending, in azure supports IKEv1 only.
Policy-based key feature in azure: uses static routing because combinations of address prefixes specifies the encryption and decryption through tunnel and we don’t need routing table anymore, must be used in specific scenarios e.g. for compatibility with legacy on-prem VPN device.
Route-based: uses IPsec model or Virtual Tunnel Interface (VTI), IP routing (dynamic/static), preferred method for on-prem devices because it’s more resilient to topology change.
Route-based key featurres in azure: supports IKEv2, any-to-any wildcard traffic, can use dynamic routing protocol and rout table is created dynamically by using rout protocol like BGP (Border Gateway Protocol), encryption is based on routing table.
Route-based connectivities:
– connection between virtual networks
– point-to-point connections
– multisite connections
– coexistance with an azure expressoute gateway

Virtual VPN Gateway sizes
Basic -> max 10 tunnel, 100 Mbps, BGP not supported, only for dev/test not changable to other SKUs.
VpnGw1 -> max 30 tunnel, 650 Mbps, BGP supported
VpnGw2 -> max 30 tunnel, 1 Gbps, BGP supported
VpnGw3 -> max 30 tunnel, 1.25 Gbps, BGP supported

Virtual VPN Gateway’s subnet: is necessary for VPN Gateway, name must be GatewaySubnet, address mask must be /27, this subnet cannot be used for other services.

Connect on-premises network to Microsoft Global Network by using ExpressRoute

This section is only “what should we know about ExpressRoute”. To read more refer to Configure ExpressRoute.

Overview

  • ExpressRoute can be used for extending on-prem into cloud
  • It works by peering on-prem network with Microsoft Cloud (resources on the both sides can communicate with each other)
  • Connection over private high-bandwidth, secure, and reliable connection
  • Is used to connenct on-prem to Azure Cloud Services e.g. Office 365, Dynamic 365
  • Connectivity is not over internet.
  • But DNS queries, certificate revokaion list checking, Azure Content Delivery Network requests are still sent over public internet.

Prerequisites

  • An ExpressRoute partner or cloud exchange provider is needed to set up connection between on-prem and cloud
  • Azure subscription which is registered by your expressroute partner
  • an azure accunt that can request an expressroute circuite
  • If you want to access office 365 services, an office 365 subscription is needed
High-level overview of the Azure ExpressRoute service
Architecture of EXpressRoute

Architecture: EXpressRoute partner provides the edge service: an authorized and authenticated connection that operates through a partner-controlled router. The edge service is responsible for extending your network to the microsoft cloud.
The partner sets up connection to an endpoint in an expressroute location (implemented by microsoft edge router). This connection enable to peer the on-prem network with virtual network through the network (this connection is called circuite).
A circuite provides a physical connection for transmitting data through the expressroute provider’s edge router to the microsoft’s edge routers. A circuite is established across a private wire rather than the public internet. the on-prem network is connected to the expressRoute provider’s edge router. Microsoft edge routers provide the entry point to the microsoft cloud.

Features

  • Layer 3 connectivity: this is address-level connectivity. This connection can be from a point-to-point, any-to-any network, or can be virtual cross-connetion through an exchange.
  • Built-in redundancy: conncetivity providers uses redundant devices for high availability. We can have multiple circuits to completement this feature. All redundant connections are configured with layer 3 connectivity to meet the SLAs.
  • Enable direct access to cloud services
    • Microsoft office 365 (generally is designed for internal, express route recommend for spesific scenarios)
    • Microsoft Dynamic 365
    • Azure compute services e.g. VMs
    • Azure cloud services e.g. Azure cosmos db, Azure storage
  • Across on-prem & Global reach: we can enable ExpressRoute Global Reach to exchange data across your on-premises sites by connecting your expressroute circuits and the cross datacenter traffic will trvel through the microsoft network.
  • Dynamic routing: uses Border Gateway Protocol (BGP) for routing traffic between on-prem network and resources running in azure.
without
Usual ExpressRoute Circuite: Both branch offices can have high speed connectivity to Azure resources in US West and UK South. However, the branch offices cannot exchange data directly with each other. In other words, 10.0.1.0/24 can send data to 10.0.3.0/24 and 10.0.4.0/24, but NOT to 10.0.2.0/24.
with
ExpressRoute Global Reach: with the addition of ExpressRoute Global Reach, your San Francisco office (10.0.1.0/24) can directly exchange data with your London office (10.0.2.0/24) through the existing ExpressRoute circuits and via Microsoft’s global network.

Scenario

  • For systems that need to communicate between an on-prem and cloud and their requirements are not to use the internet for the traffic, hight band-width, and consistent network performance.
  • Low-latency connectivity to services in the cloud, because of eliminating or reducing the network overhead will have an significant impact on the performance of your applications.
  • Accessing high-volum for systems that consuming or producing massive volumes of data quickly.
  • Consuming Microsoft Cloud Services e.g. office 365 or dynamic 365. Useful for organization with large number of users and access services concurrently.
  • Organizations that have migrated large-scale-on-premises clients.Result have to be seamless for on-prem clients even they can notice an improvment because of the better bandwith.
  • For situations that data should not traverse the public internet because of security reasons.
  • Large datacenters, with a high number of users and systems accessing SaaS offering.

ExpressRoute connectivity models

  1. CloudExchange co-location:
  2. Point-to-point ethernet connectivity
  3. Any-to-any connection
Azure connectivity models

Design IP address

A good Azure IP addressing schema provides flexibility, room for growth, and integration with on-premises networks. The schema ensures that communication works for deployed resources, minimizes public exposure of systems, and gives the organization flexibility in its network. If not properly designed, systems might not be able to communicate, and additional work will be required to remediate.

Scenario: Your company is beginning a project to move many services out of its existing datacenter and into the Azure cloud. The company wants to integrate the existing network with Azure. You need to plan the public and private IP addresses for the network carefully, so you don’t run out of addresses and will have capacity for future growth. A good IP addressing scheme provides flexibility, room for growth, and integration with on-premises networks.

on-prem network

typical components

  • Routers
  • Firewalls
  • Switches
  • Network segmentation
Typical on-premises network design
simplified version of a typical on-premises network
  • routers faced with Internet service provider (ISP) has punlic IP, that used for outbound internet traffic
  • this public ip is used for inbound traffic as well
  • ISP assign you a block of ip addresses for systems that you want to make accessible from the internet
  • perimeter internal zone have private ip addresse
  • Administrator has full control over
    • IP address assignment
    • name resolution
    • security settings
    • security rules
    • can add or remove subnet via specifying classless inter-domain routing (CIDR)
  • three range of non-routable ip addresses that won’t be sent over internet router
    • 10.0.0.0 to 10.255.255.255
    • 127.16.0.0 to 172.31.255.255
    • 192.168.0.1 to 192.168.255.255

Azure network

typical components

  • Virtual network
  • Subnets
  • Network security group
  • firewalls
  • load balancer
Typical Azure network design
Azure network design
  • uses private addresses
  • the range of private IPs are the same as on-prem
  • Administrator has full control over
    • IP address assignment
    • name resolution
    • security settings
    • security rules
    • can add or remove subnet via specifying classless inter-domain routing (CIDR)
  • there’s no hadware device like router, switch
  • infrastructure is virtual
  • typically implement network security group, and firewall
  • use subnet to isolate front-end services (web server and DNS) and backend
  • NSG filter internal and external traffic at network layer
  • firewall has more capability for network layer and application layer filtering
  • by default subnets communicate with each other
  • With NSG we can deny the communication
  • Smallest supported subnet has /29 mask and largest /8
Integrate Azure with on-prem
  • There must be no IP overlap for interconnect networks e.g. 192.168.0.0/16 and 192.168.0.0/24 are not acceptable
  • two different Ip classes are allowes e.g. 10.20.0.0/16 and 10.30.0.0/16
Public and Private IPs

Public IP

  • for public-facing services
  • you cannot bring pip from on-prem into azure
  • based on the resurce region, pip is assigned from regino pool
  • pip are unique for each region (region specific)
  • pip cannot move between regions
  • azure traffic manager is for balancing between region-specific instances
  • ip prefix can be specify

In Azure

  • PIP can be static or dynamic
  • can be assigned to
    • NIC
    • internet facing load balancer
    • vpn gateway
    • application gateway

Dynamic PIP

  • can be changed over the lifespan of azure resources
  • is allocated when vw is created or started
  • it’s released when resource is stoped to deleted
  • each region has it’s unique pip pool
  • default allocation is dynamic

Static PIP

  • won’t be changed over the lifespan of the azure resource
  • it’s released when the resource is deleted or the allocation method is changed to dynamic

PIP SKUs

  • Basic
    • pips before sku are basic
    • it can be dynamic or static
    • has adjustable inbound originated flow idle timeout 4-30 min, 4 min default
    • fixed outbound originated flow idle timeout 4 min
    • it’s open by default
    • use NSG to restrict inbound and outbound traffic
    • can be assigned to (any resource that use pip)
      • NIC
      • internet facing load balancer
      • vpn gateway
      • application gateway
    • it doesn’t support availability zone scenario
  • Standard
    • it support availability zone scenario/zone-redundent
    • always static allocation
    • adjustable inbound originated flow idle timeout 4-30 min, default is 4
    • fixed outbount originated flow of 4min
    • secure by default and closed to inbound traffic
    • inbound traffic must be explicitly allowed by NSG
    • can be assigned to
      • NIC
      • internet facing load balancer
      • vpn gateway
      • application gateway

Private IP

  • used for communication within vnet
  • they can be set to dynamic
    • DHCP lease : can be changed of the lifespan of the azure resource
  • they can be static
    • DHCP reservation: doesn’t change over the lifespan of the azure resource
    • it’s persist if resource is stopped or deallocated
  • these ips are seleced from reserved addresses by Internet Assigned Numbers Authority (IANA)
    • 10.0.0.0/8
    • 172.16.0.0/12
    • 192.168.0.0/16
  • first three and last ips of subnet are always reserved in azure, first and last ips are for protocol conformance
  • therefore avaibale ips in azure subnet is 2^n-5, n is host bits

Scenario: you have asked the operations and engineering teams about their requirements for the number of virtual machines in Azure. You’ve also asked them about their plans for expansion. Based on the results of this survey, you want to plan an IP addressing scheme that you won’t have to change in the foreseeable future.

Questions for finding out the network requirements

  • How many devices do you have on the network?
  • How many devices are you planning to add to the network in the future?
  • Based on the services running on the infrastructure, what devices do you need to separate?
  • How many subnets do you need?
  • How many devices per subnet will you have?
  • How many devices are you planning to add to the subnets in future?
  • Are all subnets going to be the same size?
  • How many subnets do you want or plan to add in future?
  • If they have fron-end server or back-end server? e.g. HR or financial apps and data
    • they have to secured/isolated (refer to the related topices)

Source


Resources


The only way to be truly satisfied is to do what you blieve is great work. And the only way to do geart work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle.

Steve Jobs


%d bloggers like this: