MST400: Microsoft Azure Administration Module 5 PDF

MST400: Introduction to Microsoft Azure Administration Module 5: Intersite connectivity Hooshang Kazemi, Ph.D. Module 5: Topics • VNet Peering • VPN Gateway Connections • ExpressRoute and Virtual WAN MST400 VNet Peering • Virtual network peering enables you to seamlessly connect two Azure virt...

MST400: Introduction to Microsoft Azure Administration Module 5: Intersite connectivity Hooshang Kazemi, Ph.D. Module 5: Topics • VNet Peering • VPN Gateway Connections • ExpressRoute and Virtual WAN MST400 VNet Peering • Virtual network peering enables you to seamlessly connect two Azure virtual networks. • Once peered, the virtual networks appear as one, for connectivity purposes. • There are two types of VNet peering. • • Regional VNet peering connects Azure virtual networks in the same region. Global VNet peering connects Azure virtual networks in different regions. • In creating a Global VNet peering, any Azure public cloud region or China cloud regions can be used, but not in Government cloud regions. • VNet peering of government VNets can only be done in the same Azure Government cloud regions. MST400 Benefits of virtual network peering • Private. Network traffic between peered virtual networks is private. Traffic between the virtual networks is kept on the Microsoft backbone network. No public Internet, gateways, or encryption is required in the communication between the virtual networks. • Performance. A low-latency, high-bandwidth connection between resources in different virtual networks. • Communication. The ability for resources in one virtual network to communicate with resources in a different virtual network, once the virtual networks are peered. • Seamless. The ability to transfer data across Azure subscriptions, deployment models, and across Azure regions. • No disruption. No downtime to resources in either virtual network when creating the peering, or after the peering is created. MST400 • • • • Create two virtual networks. Peer the virtual networks. Create virtual machines in each virtual network. Test the communication between the virtual machines. MST400 Gateway Transit and Connectivity • A peered virtual network uses a remote gateway to gain access to the resources in the other Vnet. • Use Allow Gateway Transit in the virtual network to access resources outside the peering. • IP address spaces of connected networks should not overlap MST400 Service Chaining • VNet Peering is nontransitive. • To provide transitivity we can configure user-defined routes and service chaining. • This allows you to: • Implement a multi-level hub and spoke architecture. • Overcome the limit on the number of VNet peerings per virtual network. MST400 Service Chaining: Hub and spoke architecture • In hub-and-spoke networks, the hub virtual network can host infrastructure components like the network virtual appliance or VPN gateway. • All the spoke virtual networks can then peer with the hub virtual network. • Traffic can flow through network virtual appliances or VPN gateways in the hub virtual network. MST400 Service Chaining: User-Defined Routes (UDR) and service chaining • Service chaining allows UDRs. These routes direct traffic from one virtual network to the IP address of a VM (virtual appliance) in a peered virtual network or a VPN gateway. • The IP address of a virtual machine in a Vnet, or a VPN gateway can be used as the next hop in a userdefined route. MST400 VPN Gateways • A VPN gateway is used to: • Send encrypted traffic between an Azure virtual network and an on-premises datacentre over the Internet. • Send encrypted traffic between Azure virtual networks over the Microsoft network. • Each Vnet can have only one VPN gateway. However, you can create multiple connections to it. • A virtual network gateway is composed of two or more VMs that are deployed to a specific subnet you create called the gateway subnet. • Virtual network gateway VMs contain routing tables and run specific gateway services. These VMs are created when you create the virtual network gateway. You can't directly configure the VMs that are part of the virtual network gateway. MST400 VPN Gateway Connections • Site-to-site connections connect on-premises datacenters to Azure virtual networks • VNet-to-VNet connections connect Azure virtual networks (custom) • Point-to-site (User VPN) connections connect individual devices to Azure virtual networks MST400 Implement Site-to-Site Connections High-level steps to create Site-to-Site connection. • Create VNets and subnets. Remember for Site-to-Site connections you need to connect to an on-premises location. • Specify the DNS server (optional). Only if you need name resolution for resources that are deployed to your virtual network, you should specify a DNS server in the virtual network configuration. MST400 Site-to-Site Connection: Create the Gateway Subnet • The gateway subnet contains the IP addresses that are used by the virtual network gateway. • It's best to use a CIDR block of /28 or /27 to provide for future configurations. • Gateway VMs are deployed to the gateway subnet and configured with the required VPN gateway settings. • Never deploy other resources (for example, additional VMs) to the gateway subnet. • The gateway subnet must be named GatewaySubnet. MST400 Site-to-Site Connection: VPN Gateway Configuration • The type of VPN you choose depends on the make and model of your VPN device, and the kind of VPN connection you intend to create. • Most VPN types are Route-based • Your choice of SKU will affect the number of tunnels you can have and the aggregate throughput benchmark. • The Vnet that has the Gateway subnet should be associated with the VPN Gateway. • The gateway needs a public IP MST400 Site-to-Site Connection: VPN Gateway Types • Route-based VPNs. Route-based VPNs use routes in the IP forwarding or routing table to direct packets into their corresponding tunnel interfaces. The tunnel interfaces then encrypt or decrypt the packets in and out of the tunnels. The policy (or traffic selector) for Route-based VPNs are configured as any-to-any (or wild cards). • Policy-based VPNs. Policy-based VPNs encrypt and direct packets through IPsec tunnels based on the IPsec policies configured with the combinations of address prefixes between your on-premises network and the Azure VNet. The policy (or traffic selector) is defined as an access list in the VPN device configuration. • Policy-based VPNs, have the following limitations: • Policy-Based VPNs can only be used on the Basic gateway SKU and is not compatible with other gateway SKUs. • You can have only one tunnel when using a Policy-based VPN. • You can only use Policy-based VPNs for S2S connections, and only for certain configurations. Most VPN Gateway configurations require a Route-based VPN. MST400 Site-to-Site Connection: Gateway SKUs and Generations The Gateway SKU affects the number of connections and the throughput benchmark. MST400 Site-to-Site Connection: Create the Local Network Gateway • The local network gateway name typically refers to the onpremises location. • You give the site a name by which Azure can refer to it, then specify the IP address or FQDN of the on-premises VPN device for the connection. • IP Address. The public IP address of the local gateway. • Address Space. One or more IP address ranges (in CIDR notation) that define your local network's address space. MST400 Site-to-Site Connection: Configure the On-Premises VPN device • There is a validated list of standard VPN devices that work well with the VPN gateway. • This list was created in partnership with device manufacturers like • • • • Cisco, Juniper, Ubiquiti, and Barracuda Networks. • To configure your VPN device, you will need: • A shared key. The same shared key that you specify when creating the VPN connection (next topic). • The public IP address of your VPN gateway. The IP address can be new or existing. MST400 Site-to-Site Connection: Create the VPN Connection Once your VPN gateways are created, you can create the connection between them. If your VNets are in the same subscription, you can use the portal. You can verify the connections either in the portal, or by using PowerShell. MST400 High Availability Scenarios • Active/Standby • Active/Active MST400 • • • • VPN Gateways Explore Gateway Subnets Explore Connected Devices Explore adding a Virtual Network Gateway MST400 ExpressRoute and Virtual WAN With ExpressRoute, you can establish connections to Microsoft cloud services, such as Microsoft Azure, Microsoft 365, and CRM Online via a private connection. You can use ExpressRoute to: • Make your connections fast, reliable, and private • Use a virtual private cloud for storage, backup, and recovery • Extend and connect your datacenters • Build hybrid applications MST400 ExpressRoute and Virtual WAN: ExpressRoute benefits • Layer 3 connectivity using BGP routes • Redundancy with the use of dual connections to Microsoft Enterprise edge routers (MSEEs) • Connectivity to Microsoft cloud services like Microsoft Azure services, Microsoft 365 services, and Microsoft Dynamics 365. • Connectivity to all regions within a geopolitical region • Global connectivity with ExpressRoute premium add-on • Across on-premises connectivity with ExpressRoute Global Reach • Bandwidth options are available from 50 Mbps to 100 Gbit • Flexible billing models; • Unlimited data. Billing is based on a monthly fee; free inbound and outbound traffic. • Metered data. Billing is based on a monthly fee; all inbound data transfer is free of charge. Outbound data transfer is charged per GB of data transfer • ExpressRoute premium add-on. This add-on includes increased routing table limits, increased number of VNets, global connectivity, and connections to Microsoft 365 and Dynamics 365. MST400 ExpressRoute and Virtual WAN: Coexisting Site-to-Site and ExpressRoute Configuring Site-to-Site VPN and ExpressRoute connections for the same virtual network has several advantages: • A Site-to-Site VPN as a secure failover path for ExpressRoute • A Site-to-Site VPNs link to connect to sites that are not part of your network, but that are connected through ExpressRoute. MST400 ExpressRoute and Virtual WAN: Intersite Connections Comparison MST400 Virtual WANs Azure Virtual WAN is a global transit network architecture based on a hub-and-spoke connectivity model. Advantages: • Integrated connectivity solutions in hub and spoke • Automated spoke setup and configuration • Intuitive troubleshooting There are two types of virtual WANs: • Basic • Standard. MST400 Thank you! MST400