Azure Fundamentals (6) | VNet, VPN Gateway

 

1. Virtual Network fundamentals

 

Azure Virtual Network fundamentals @MS; https://docs.microsoft.com/en-us/learn/modules/azure-networking-fundamentals/azure-virtual-network-fundamentals

 

 

• Azure virtual networks: Azure virtual networks enable Azure resources, such as VMs, web apps, and databases, to communicate with each other, with users on the internet, and with your on-premises client computers. You can think of an Azure network as an extension of your on-premises network with resources that links other Azure resources.
  
  
  • Isolation and segmentation: Azure virtual network allows you to create multiple isolated virtual networks. When you set up a virtual network, you define a private IP address space by using either public or private IP address ranges. The public IP range only exists within the virtual network and isn't internet routable. You can divide that IP address space into subnets and allocate part of the defined address space to each named subnet. For name resolution, you can use the name resolution service that's built in to Azure. You can also configure the virtual network to use an internal or an external DNS server.
    
    
  • Internet communications: A VM in Azure can connect to the internet by default. You can enable incoming connections from the internet by assigning a public IP address to the VM or by putting the VM behind a public load balancer. For VM management, you can connect via the Azure CLI, Remote Desktop Protocol, or Secure Shell.
    
    
  • Communicate between Azure resources:
    • Virtual networks: Virtual networks can connect not only VMs but other Azure resources, such as the App Service Environment for Power Apps, Azure Kubernetes Service, and Azure virtual machine scale sets.
      
      
    • Service endpoints: You can use service endpoints to connect to other Azure resource types, such as Azure SQL databases and storage accounts. This approach enables you to link multiple Azure resources to virtual networks to improve security and provide optimal routing between resources.
  • Communicate with on-premises resources: Azure virtual networks enable you to link resources together in your on-premises environment and within your Azure subscription. In effect, you can create a network that spans both your local and cloud environments. There are three mechanisms for you to achieve this connectivity:
    • Point-to-site virtual private networks: The typical approach to a virtual private network (VPN) connection is from a computer outside your organization, back into your corporate network. In this case, the client computer initiates an encrypted VPN connection to connect that computer to the Azure virtual network.
      
      
    • Site-to-site virtual private networks: A site-to-site VPN links your on-premises VPN device or gateway to the Azure VPN gateway in a virtual network. In effect, the devices in Azure can appear as being on the local network. The connection is encrypted and works over the internet.
      
      
    • Azure ExpressRoute: For environments where you need greater bandwidth and even higher levels of security, Azure ExpressRoute is the best approach. ExpressRoute provides a dedicated private connectivity to Azure that doesn't travel over the internet. 
      
      
  • Route network traffic: By default, Azure routes traffic between subnets on any connected virtual networks, on-premises networks, and the internet. You can also control routing and override those settings, as follows:
    
    • Route tables: A route table allows you to define rules about how traffic should be directed. You can create custom route tables that control how packets are routed between subnets.
      
      
    • Border Gateway Protocol: Border Gateway Protocol (BGP) works with Azure VPN gateways, Azure Route Server, or ExpressRoute to propagate on-premises BGP routes to Azure virtual networks.
      
      
  • Filter network traffic: Azure virtual networks enable you to filter traffic between subnets by using the following approaches:
    • Network security groups: A network security group is an Azure resource that can contain multiple inbound and outbound security rules. You can define these rules to allow or block traffic, based on factors such as source and destination IP address, port, and protocol.
      
      
    • Network virtual appliances: A network virtual appliance is a specialized VM that can be compared to a hardened network appliance. A network virtual appliance carries out a particular network function, such as running a firewall or performing wide area network (WAN) optimization.
      
      
  • Connect virtual networks: You can link virtual networks together by using virtual network peering. Peering enables resources in each virtual network to communicate with each other. These virtual networks can be in separate regions, which allows you to create a global interconnected network through Azure.
    
    User-defined routes (UDR) are a significant update to Azure’s Virtual Networks that allows for greater control over network traffic flow. This method allows network administrators to control the routing tables between subnets within a VNet, as well as between VNets.

 

[Differentiating between Azure Virtual Network (VNet) and AWS Virtual Private Cloud (VPC)]

Conceptually, both the Azure VNet and AWS VPC provide the bedrock for provisioning resources and service in the cloud. Both networks provide the same building blocks but with a degree of variability in implementation. Following is the summary of some of these building blocks:

Subnet – For effective design and control of resources deployed on the cloud, both Azure VNet and AWS VPC segregate the networks with subnets. An AWS VPC spans all the Availability Zones (AZs) in that region, hence, subnets in AWS VPC are mapped to Availability Zones (AZs). A subnet must only belong to one AZ and cannot span AZs. Azure VNet subnets are defined by the IP Address block assigned to it. Communications between all subnets in the AWS VPC are through the AWS backbone and are allowed by default. AWS VPC subnets can either be private or public. A subnet is public if it has an internet gateway (IGW) attached. AWS allows only one IGW per VPC and the public subnet allow resources deployed in them access to the internet. AWS creates a default VPC and subnets for each region. This default VPC has subnets for each region where the VPC resides, and any image (EC2 instance) deployed to this VPC will be assigned a public IP address and hence has internet connectivity. Azure VNet does not provide a default VNet and does not have private or public subnet as in AWS VPC. Resources connected to a VNet have access to the Internet, by default.

IP Addresses – Both AWS VPC and Azure VNET use non-globally routable CIDR from the private IPv4 address ranges as specified in RFC 1918 – addresses from this RFC are not globally routable — but customers can still use other public IP addresses. Azure VNet assigns resources connected and deployed to the VNet a private IP address from the CIDR block specified. In Azure VNet, the smallest subnet supported is /29 and the largest is a /8. AWS also allows IP addresses from the same RFC 1918 or publicly routable IP blocks. (...) Azure VNet offers more flexibilities in this area – IP addresses of the subnet can be changed after the initial design. But resources in the current subnet will need to be migrated off the current subnet.

Routing Table – AWS uses the route table to specify the allowed routes for outbound traffic from the subnet. All subnets created in a VPC is automatically associated with the main routing table, hence, all subnets in a VPC can allow traffic from other subnets unless explicitly denied by security rules. In Azure VNet, all resources in the VNet allow the flow of traffic by using the system route. You don’t have to configure and manage routes because by default, Azure VNet provides routing between subnets, VNets, and on-premises networks. The use of system routes facilitates traffic automatically but there are cases in which you want to control the routing of packets through a virtual appliance. Azure VNet uses the system route table to ensure that resources connected to any subnet in any VNet communicate with each other by default. However, there are scenarios when you might want to override the default routes. For such scenarios, you can implement the user-defined routes (UDR) — control where traffic is routed for each subnet — or/and BGP routes (your VNet to your on-premises network using an Azure VPN Gateway or ExpressRoute connection). The UDR applies to only traffic leaving the subnet and can provide a layer of security for Azure VNet deployment, if the goal of UDR is to send traffic to some kind of inspection NVA or the like. With UDR, packets sent to one subnet from another can be forced to go through a network virtual appliance on a set of routes. In a hybrid setup, Azure VNet may use any of the three route tables – UDR, BGP (if ExpressRoute is used) and System routing tables. In Azure VNet, the subnet relies on the system routes for its traffic until a route table is explicitly associated with a subnet. Once an association is established, i.e. a UDR and/or a BGP route exists, routing is done based on Longest Prefix Match (LPM). In cases where there is more than one route with the same prefix length, a route is selected based on its origin in the following order: User defined route, BGP route (when ExpressRoute is used) and System route. Whereas, in AWS VPC the routing tables may be more than one, but of the same type.

...

Differentiating between Azure Virtual Network (VNet) and AWS Virtual Private Cloud (VPC)
Developer S, 2017-09-17
https://devblogs.microsoft.com/premier-developer/differentiating-between-azure-virtual-network-vnet-and-aws-virtual-private-cloud-vpc/ 

Differentiating between Azure Virtual Network (VNet) and AWS Virtual Private Cloud (VPC)

 

VNet concepts

- Address space:
When creating a VNet, you must specify a custom private IP address space using public and private (RFC 1918) addresses. Azure assigns resources in a virtual network a private IP address from the address space that you assign. For example, if you deploy a VM in a VNet with address space, 10.0.0.0/16, the VM will be assigned a private IP like 10.0.0.4.

- Subnets:
Subnets enable you to segment the virtual network into one or more sub-networks and allocate a portion of the virtual network's address space to each subnet. You can then deploy Azure resources in a specific subnet. Just like in a traditional network, subnets allow you to segment your VNet address space into segments that are appropriate for the organization's internal network. This also improves address allocation efficiency. You can secure resources within subnets using Network Security Groups. For more information, see Network security groups.

- Regions:
VNet is scoped to a single region/location; however, multiple virtual networks from different regions can be connected together using Virtual Network Peering.

- Subscription:
VNet is scoped to a subscription. You can implement multiple virtual networks within each Azure subscription and Azure region.

...

Azure Virtual Network concepts and best practices
Article 04/13/2022
https://docs.microsoft.com/en-us/azure/virtual-network/concepts-and-best-practices 

Azure Virtual Network - Concepts and best practices

 

 

 

 

 

2. Azure Virtual Network settings

 

2.1. Create a virtual network

Configure the following settings for a basic virtual network

2.1.1. Subscription
(only applies if you have multiple subscriptions to choose from.)

2.1.2. Resource group
(Like any other Azure resource, a virtual network needs to exist in a resource group.)

2.1.3. Network name 
(must be unique in your subscription)

2.1.4. Region

2.1.5. Address space
(CIDR format. needs to be unique within your subscription and any other networks that you connect to.)

2.1.6 Subnet
(create one or more subnets that partition the virtual network's address space)

2.1.7. Service endpoints 

2.1.8. NAT gateway 

(fully managed and highly resilient Network Address Translation (NAT) service)

2.1.9 Bastion Host
(secure and seamless RDP/SSH connectivity to your virtual machines directly in the Azure portal over SSL)

2.1.10. DDoS Protection Standard

(premium service)

2.1.11. Firewall

(managed cloud-based network security service that protects your Azure Virtual Network resources)

 

What is Virtual Network NAT?

Virtual Network NAT is a fully managed and highly resilient Network Address Translation (NAT) service. Virtual Network NAT simplifies outbound Internet connectivity for virtual networks. When configured on a subnet, all outbound connectivity uses the Virtual Network NAT's static public IP addresses.

https://docs.microsoft.com/en-us/azure/virtual-network/nat-gateway/nat-overview 

What is Azure Bastion?

Azure Bastion is a service you deploy that lets you connect to a virtual machine using your browser and the Azure portal. The Azure Bastion service is a fully platform-managed PaaS service that you provision inside your virtual network. It provides secure and seamless RDP/SSH connectivity to your virtual machines directly from the Azure portal over TLS. When you connect via Azure Bastion, your virtual machines don't need a public IP address, agent, or special client software.

https://docs.microsoft.com/en-us/azure/bastion/bastion-overview 

Azure DDoS Protection Standard overview

Azure DDoS Protection Standard, combined with application design best practices, provides enhanced DDoS mitigation features to defend against DDoS attacks. It is automatically tuned to help protect your specific Azure resources in a virtual network. Protection is simple to enable on any new or existing virtual network, and it requires no application or resource changes.

https://docs.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview 

What is Azure Firewall?

Azure Firewall is a cloud-native and intelligent network firewall security service that provides the best of breed threat protection for your cloud workloads running in Azure. It's a fully stateful, firewall as a service with built-in high availability and unrestricted cloud scalability. It provides both east-west and north-south traffic inspection. Azure Firewall is offered in two SKUs: Standard and Premium.

https://docs.microsoft.com/en-us/azure/firewall/overview 

 

 

2.2. Define additional settings

2.2.1. Network security group

Network security groups have security rules that enable you to filter the type of network traffic that can flow in and out of virtual network subnets and network interfaces. You create the network security group separately. Then you associate it with each subnet in the virtual network.

2.2.2. Route table

Azure automatically creates a route table for each subnet within an Azure virtual network and adds system default routes to the table. You can add custom route tables to modify traffic between subnets and virtual networks.

2.2.3. Subnet Delegation

(subnet to be used by a dedicate service.)

2.2.4. amend the service endpoints and NAT gateway configuration.

 

 

2.3. Configure virtual networks

Review and change settings in further subpanes. 

2.3.1. Address spaces

Add additional address spaces to the initial definition.

2.3.2. Connected devices

View a list of all connected host in the virtual network.

2.3.3. Subnets

Add additional subnets.

2.3.4. DDos protection

Enable/disable the Standard DDos protection plan.

2.3.5. Firewall

Configure firewall settings with Azure Firewall service for the virtual network.

2.3.6. Security

Provides security recommendation.

2.3.7. Network Manager

View connectivity and security admin configuration the virtual network is associated to.

2.3.8. DNS servers

Configure internal or external DNS servers the resources in the virtual network will use.

2.3.9. Peerings

Link virtual networks in peering arrangements.

2.3.10. Service endpoints

Enable service endpoints and apply them to multiple subnets.

2.3.11. Private endpoints

View a list of private endpoints enabled in a subnet.

2.3.12. Monitor and view metrics to troubleshoot your virtual networks.

 

 

 

 

 

3. Azure VPN Gateway fundamentals

VPNs use an encrypted tunnel within another network. They're typically deployed to connect two or more trusted private networks to one another over an untrusted network (typically the public internet). Traffic is encrypted while traveling over the untrusted network to prevent eavesdropping or other attacks. 

 

VPN gateways @MS; https://docs.microsoft.com/en-us/learn/modules/azure-networking-fundamentals/azure-vpn-gateway-fundamentals

 

(1) VPN Gateway Types

 

• VPN gateways
  • A VPN gateway is a type of virtual network gateway. Azure VPN Gateway instances are deployed in a dedicated subnet of the virtual network and enable the following connectivity:
    - Connect on-premises datacenters to virtual networks through a site-to-site connection.
    - Connect individual devices to virtual networks through a point-to-site connection.
    - Connect virtual networks to other virtual networks through a network-to-network connection.
    
    
  • (...) You can deploy only one VPN gateway in each virtual network, but you can use one gateway to connect to multiple locations, which includes other virtual networks or on-premises datacenters. When you deploy a VPN gateway, you specify the VPN type: either policy-based or route-based. The main difference between these two types of VPNs is how traffic to be encrypted is specified. In Azure, both types of VPN gateways use a pre-shared key as the only method of authentication. Both types also rely on Internet Key Exchange (IKE) in either version 1 or version 2 and Internet Protocol Security (IPSec). IKE is used to set up a security association (an agreement of the encryption) between two endpoints. This association is then passed to the IPSec suite, which encrypts and decrypts data packets encapsulated in the VPN tunnel.
    
    
• Policy-based VPNs
  
  • Policy-based VPN gateways specify statically the IP address of packets that should be encrypted through each tunnel. This type of device evaluates every data packet against those sets of IP addresses to choose the tunnel where that packet is going to be sent through.
    - Support for IKEv1 only.
    - Use of static routing, where combinations of address prefixes from both networks control how traffic is encrypted and decrypted through the VPN tunnel. The source and destination of the tunneled networks are declared in the policy and don't need to be declared in routing tables.
    - Must be used in specific scenarios that require them, such as for compatibility with legacy on-premises VPN devices.
    
    
• Route-based VPNs
  
  • If defining which IP addresses are behind each tunnel is too cumbersome, route-based gateways can be used. With route-based gateways, IPSec tunnels are modeled as a network interface or virtual tunnel interface. IP routing (either static routes or dynamic routing protocols) decides which one of these tunnel interfaces to use when sending each packet. Route-based VPNs are the preferred connection method for on-premises devices. They're more resilient to topology changes such as the creation of new subnets.
    - Supports IKEv2
    - Uses any-to-any (wildcard) traffic selectors
    - Can use dynamic routing protocols, where routing/forwarding tables direct traffic to different IPSec tunnels. In this case, the source and destination networks aren't statically defined as they are in policy-based VPNs or even in route-based VPNs with static routing. Instead, data packets are encrypted based on network routing tables that are created dynamically using routing protocols such as Border Gateway Protocol (BGP).
    
    
  • Use Cases: 
    - Connections between virtual networks
    - Point-to-site connections
    - Multisite connections
    - Coexistence with an Azure ExpressRoute gateway

 

 

(2) VPN gateways deployment

 

Deploy VPN gateways @MS; https://docs.microsoft.com/en-us/learn/modules/azure-networking-fundamentals/azure-vpn-gateway-fundamentals

 

You'll need these Azure resources before you can deploy an operational VPN gateway:

• Virtual network
  • Deploy a virtual network with enough address space for the additional subnet that you'll need for the VPN gateway. The address space for this virtual network must not overlap with the on-premises network that you'll be connecting to. You can deploy only one VPN gateway within a virtual network.
    
    
• GatewaySubnet
  • Deploy a subnet called GatewaySubnet for the VPN gateway. Use at least a /27 address mask to make sure you have enough IP addresses in the subnet for future growth. You can't use this subnet for any other services.
    
    
• Public IP address
  • Create a Basic-SKU dynamic public IP address if you're using a non-zone-aware gateway. This address provides a public-routable IP address as the target for your on-premises VPN device. This IP address is dynamic, but it won't change unless you delete and re-create the VPN gateway.
    
    
• Local network gateway
  • Create a local network gateway to define the on-premises network's configuration, such as where the VPN gateway will connect and what it will connect to. This configuration includes the on-premises VPN device's public IPv4 address and the on-premises routable networks. This information is used by the VPN gateway to route packets that are destined for on-premises networks through the IPSec tunnel.
    
    
• Virtual network gateway
  • Create the virtual network gateway to route traffic between the virtual network and the on-premises datacenter or other virtual networks. The virtual network gateway can be either a VPN or ExpressRoute gateway. (but this unit only deals with VPN virtual network gateways)
    
    
• Connection
  • Create a connection resource to create a logical connection between the VPN gateway and the local network gateway.
    - The connection is made to the on-premises VPN device's IPv4 address as defined by the local network gateway.
    - The connection is made from the virtual network gateway and its associated public IP address.
    
    

 

To connect your datacenter to a VPN gateway, you'll need these on-premises resources:

• A VPN device that supports policy-based or route-based VPN gateways
• A public-facing (internet-routable) IPv4 address

 

 

(3) High-availability scenarios (fault-tolerant configuration)

 

• Active/standby
  
  • By default, VPN gateways are deployed as two instances in an active/standby configuration, even if you only see one VPN gateway resource in Azure. When planned maintenance or unplanned disruption affects the active instance, the standby instance automatically assumes responsibility for connections without any user intervention. Connections are interrupted during this failover, but they're typically restored within a few seconds for planned maintenance and within 90 seconds for unplanned disruptions.
    
    
• Active/active
  
  • With the introduction of support for the BGP routing protocol, you can also deploy VPN gateways in an active/active configuration. In this configuration, you assign a unique public IP address to each instance. You then create separate tunnels from the on-premises device to each IP address. You can extend the high availability by deploying an additional VPN device on-premises.
    
    
• ExpressRoute failover
  
  • Another high-availability option is to configure a VPN gateway as a secure failover path for ExpressRoute connections. ExpressRoute circuits have resiliency built in. But they aren't immune to physical problems that affect the cables delivering connectivity or outages that affect the complete ExpressRoute location. In high-availability scenarios, where there's risk associated with an outage of an ExpressRoute circuit, you can also provision a VPN gateway that uses the internet as an alternative method of connectivity. In this way, you can ensure there's always a connection to the virtual networks.
    
    
• Zone-redundant gateways
  
  • In regions that support availability zones, VPN gateways and ExpressRoute gateways can be deployed in a zone-redundant configuration. This configuration brings resiliency, scalability, and higher availability to virtual network gateways. Deploying gateways in Azure availability zones physically and logically separates gateways within a region while protecting your on-premises network connectivity to Azure from zone-level failures. These gateways require different gateway SKUs and use Standard public IP addresses instead of Basic public IP addresses.

 

 

https://docs.microsoft.com/en-us/learn/modules/azure-networking-fundamentals/azure-vpn-gateway-fundamentals

Azure VPN Gateway fundamentals - Learn

 

 

 

 

 

[Appendix] ExpressRoute

Azure ExpressRoute fundamentals @MS; https://docs.microsoft.com/en-us/learn/modules/azure-networking-fundamentals/express-route-fundamentals

 

ExpressRoute lets you extend your on-premises networks into the Microsoft cloud over a private connection with the help of a connectivity provider. With ExpressRoute, you can establish connections to Microsoft cloud services, such as Microsoft Azure and Microsoft 365.

Connectivity can be from an any-to-any (IP VPN) network, a point-to-point Ethernet network, or a virtual cross-connection through a connectivity provider at a colocation facility. ExpressRoute connections don't go over the public Internet. This allows ExpressRoute connections to offer more reliability, faster speeds, consistent latencies, and higher security than typical connections over the Internet. 

 

• Layer 3 connectivity:
  ExpressRoute provides Layer 3 (address-level) connectivity between your on-premises network and the Microsoft cloud through connectivity partners. These connections can be from a point-to-point or any-to-any network. They can also be virtual cross-connections through an exchange.
  
  
• Built-in redundancy:
  Each connectivity provider uses redundant devices to ensure that connections established with Microsoft are highly available. You can configure multiple circuits to complement this feature. All redundant connections are configured with Layer 3 connectivity to meet service-level agreements.
  
  
• Connectivity to Microsoft cloud services:
  ExpressRoute enables direct access to the following services in all regions: Microsoft Office 365, Microsoft Dynamics 365, Azure compute services, such as Azure Virtual Machines, Azure cloud services, such as Azure Cosmos DB and Azure Storage
  
  
• Across on-premises connectivity with ExpressRoute Global Reach:
  You can enable ExpressRoute Global Reach to exchange data across your on-premises sites by connecting your ExpressRoute circuits. (...) Your cross-datacenter traffic will travel through the Microsoft network.
  
  
• Dynamic routing:
  ExpressRoute uses the Border Gateway Protocol (BGP) routing protocol. BGP is used to exchange routes between on-premises networks and resources running in Azure. This protocol enables dynamic routing between your on-premises network and services running in the Microsoft cloud.
• Security considerations:
  With ExpressRoute, your data doesn't travel over the public internet, so it's not exposed to the potential risks associated with internet communications. ExpressRoute is a private connection from your on-premises infrastructure to your Azure infrastructure. Even if you have an ExpressRoute connection, DNS queries, certificate revocation list checking, and Azure Content Delivery Network requests are still sent over the public internet.
  
  

 

ExpressRoute connectivity models @MS; https://docs.microsoft.com/en-us/learn/modules/azure-networking-fundamentals/express-route-fundamentals