The following is from Azure Administrator Training lab for AZ-103

VNet Peering

VNet Peering

Perhaps the simplest and quickest way to connect your VNets is to use VNetpeering. Virtual network peering enables you to seamlessly connect two Azurevirtual networks. Once peered, the virtual networks appear as one, forconnectivity purposes. There are two types of VNet peering.

• Regional VNet peering connects Azure virtual networks in the sameregion.
• Global VNet peering connects Azure virtual networks in differentregions. When creating a global peering, the peered virtual networks canexist in any Azure public cloud region or China cloud regions, but not inGovernment cloud regions. You can only peer virtual networks in thesame region in Azure Government cloud regions.

The benefits of using local or global virtual network peering, include:

• Private. Network traffic between peered virtual networks is private.Traffic between the virtual networks is kept on the Microsoft backbonenetwork. No public Internet, gateways, or encryption is required in thecommunication between the virtual networks.
• Performance. A low-latency, high-bandwidth connection betweenresources in different virtual networks.
• Communication. The ability for resources in one virtual network tocommunicate with resources in a different virtual network, once thevirtual 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 whencreating the peering, or after the peering is created.

✔️ The default VNet peering configuration provides full connectivity. Canyou see how network security groups could be applied to block or deny accessto specific subnets or virtual machines? For more information, you can see: Virtual network peering – https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview

Configure VNet Peering

Here are the steps to configure VNet peering. Notice you will need two virtualnetworks. To test the peering, you will need a virtual machine in eachnetwork. Initially, the VMs will not be able to communicate (ping), but afterconfiguration the communication will work. The step that is new isconfiguring the peering of the virtual networks.

1. Create two virtual networks.
2. Peer the virtual networks.
3. Create virtual machines in each virtual network.
4. Test the communication between the virtual machines.

To configure the peering use the Add peering page. There are only a fewoptional configuration parameters to consider.

• Allow forwarded traffic. Allows traffic not originating from within thepeer virtual network into your virtual network.
• Allow gateway transit. Allows the peer virtual network to use yourvirtual network gateway. The peer cannot already have a gatewayconfigured.
• Use remote gateways. Use your peer’s virtual gateway. Only one virtualnetwork can have this enabled.

✔️ You must configure peering on each virtual network. If you select ‘allowgateway transit’ on one virtual network; then you should select ‘use remotegateways’ on the other virtual network.

Gateway Transit

When you allow gateway transit the virtual network can communicate toresources outside the peering. For example, the subnet gateway could:

• Use a site-to-site VPN to connect to an on-premises network.
• Use a VNet-to-VNet connection to another virtual network.
• Use a point-to-site VPN to connect to a client.

In these scenarios, gateway transit allows peered virtual networks to sharethe gateway and get access to resources. This means you do not need todeploy a VPN gateway in the peer virtual network.

Global VNet Peering

Global VNet peering has the same benefits and configuration steps asregional peering, but there are some special requirements.

• Public clouds. The virtual networks can exist in any Azure public cloudregion, but not in Azure national clouds. National clouds are physicaland logical network-isolated instances of Microsoft enterprise cloudservices, which are confined within the geographic borders of specificcountries and operated by local personnel. There are very specificcustomer requirements to using and operating national clouds.
• Virtual network resources. Resources in one virtual network cannotcommunicate with the IP address of an Azure internal load balancer inthe peered virtual network. The load balancer and the resources thatcommunicate with it must be in the same virtual network.
• Gateway transit. You should not configure ‘use remote gateways’ or‘allow gateway transit’. Gateway transit only applies to regional VNetpeering.
• Transitivity. VNet global peerings are not transitive meaningdownstream VNets in one region cannot talk with downstream VNets inanother region. If you create peerings between VNet1-VNet2 and VNet2-VNet3, there is no implied peering between VNet1 and VNet3.

You can check the status of the VNet peering. The peering is not successfullyestablished until the peering status for both virtual network peerings showsConnected.

• Initiated. When you create the peering to the second virtual networkfrom the first virtual network, the peering status is Initiated.
• Connected. When you create the peering from the second virtualnetwork to the first virtual network, its peering status is Connected. Ifyou view the peering status for the first virtual network, you see its statuschanged from Initiated to Connected.

Service Chaining

VNet Peering is nontransitive. This means that if you establish VNet Peeringbetween VNet1 and VNet2 and between VNet2 and VNet3, VNet Peeringcapabilities do not apply between VNet1 and VNet3. However, you canleverage user-defined routes and service chaining to implement customrouting that will provide transitivity. This allows you to:

• Implement a multi-level hub and spoke architecture.
• Overcome the limit on the number of VNet Peerings per virtual network.

Hub and spoke architecture

You can deploy hub-and-spoke networks, where the hub virtual network canhost infrastructure components such as a network virtual appliance or VPNgateway. All the spoke virtual networks can then peer with the hub virtualnetwork. Traffic can flow through network virtual appliances or VPNgateways in the hub virtual network.

User-defined routes and service chaining

Virtual network peering enables the next hop in a user-defined route to be theIP address of a virtual machine in the peered virtual network, or a VPNgateway.

Service chaining enables you to direct traffic from one virtual network to avirtual appliance, or virtual network gateway, in a peered virtual network,through user-defined routes.

VNet to VNet

VNet-to-VNet Connections

You can connect your VNets with a VNet-to-VNet VPN connection. Using thisconnection method, you create a VPN gateway in each virtual network. Asecure tunnel using IPsec/IKE provides the communication between thenetworks.

With a VNet-to-VNet connection your VNets can be:

• in the same or different regions.
• in the same or different subscriptions.
• in the same or different deployment models.
• in Azure or on-premises.

Benefits

Cross region geo-redundancy and geo-presence

• You can set up your own geo-replication or synchronization with secureconnectivity without going over Internet-facing endpoints.
• With Azure Traffic Manager and Load Balancer, you can set up highlyavailable workload with geo-redundancy across multiple Azure regions.

Regional multi-tier applications with isolation or administrative boundary

• Within the same region, you can set up multi-tier applications withmultiple virtual networks connected together due to isolation oradministrative requirements.
• VNet-to-VNet communication can be combined with multi-siteconfigurations. This lets you establish network topologies that combinecross-premises connectivity with inter-virtual network connectivity.

✔️ You will use VNet-to-VNet connections when you cannot use VNetpeering.

✔️ Connections to on-premises viirtual networks are called Site-to-Site (S2S)connections.

For more information, you can see:

VNet-to-VNet Connectivity – https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-vnet-vnet-resource-manager-portal#vnet-to-vnet

Site-to-Site Connectivity – https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-site-to-site-resource-manager-portal

Implement VNet-to-VNet Connections

Here are the steps to creating a VNet-to-VNet connections. The on-premisespart is necessary only if you are configuring Site-to-Site. We will look indetail at each step.

Create VNets and subnets. By now you should be familiar with creatingvirtual networks and subnets. Remember for this VNet to connect to an on-premises location. You need to coordinate with your on-premises networkadministrator to reserve an IP address range that you can use specifically forthis virtual network.

Specify the DNS server (optional). DNS is not required to create a Site-to-Site connection. However, if you want to have name resolution for resourcesthat are deployed to your virtual network, you should specify a DNS server inthe virtual network configuration.

✔️ Take time to carefully plan your network configuration. If a duplicate IPaddress range exists on both sides of the VPN connection, traffic will notroute the way you may expect it to.

Create the Gateway Subnet

Before creating a virtual network gateway for your virtual network, you firstneed to create the gateway subnet. The gateway subnet contains the IPaddresses that are used by the virtual network gateway. If possible, it’s best tocreate a gateway subnet by using a CIDR block of /28 or /27 to provideenough IP addresses to accommodate future additional configurationrequirements.

When you create your gateway subnet, gateway VMs are deployed to thegateway subnet and configured with the required VPN gateway settings. Youmust never deploy other resources (for example, additional VMs) to thegateway subnet. The gateway subnet must be named GatewaySubnet.

To deploy a gateway in your virtual network simply add a gateway subnet.

✔️ When working with gateway subnets, avoid associating a networksecurity group (NSG) to the gateway subnet. Associating a network securitygroup to this subnet may cause your VPN gateway to stop functioning asexpected.

✔️ This is the same step in configuring VNet Peering.

Create the VPN Gateway

A VPN gateway is a specific type of virtual network gateway that is used tosend encrypted traffic between an Azure virtual network and an on-premiseslocation over the public Internet. You can also use a VPN gateway to sendencrypted traffic between Azure virtual networks over the Microsoft network.Each virtual network can have only one VPN gateway. However, you cancreate multiple connections to the same VPN gateway. When you createmultiple connections to the same VPN gateway, all VPN tunnels share theavailable gateway bandwidth.

• Name and Gateway Type. Name your gateway and use the VPNGateway type.
• VPN Type. Most VPN types are Route-based.
• SKU. Use the drop-down to select a gateway SKU. Your choice willaffect the number of tunnels you can have and the aggregate throughputbenchmark. The benchmark is based on measurements of multipletunnels aggregated through a single gateway. It is not a guaranteedthroughput due to Internet traffic conditions and your applicationbehaviors.
• Virtual Networks. Associate a virtual network with the gateway. Beforeyou do this, you must configure the Gateway subnet. Each virtualnetwork will need its own VPN gateway.
• Public IP Address. The gateway needs a public IP address to enable itto communicate with the remote network. Make a note of thisinformation. You will need the address when you configure your VPNdevice.

It can take up to 45 minutes to provision the VPN gateway.

✔️ After the gateway is created, view the IP address that has been assignedto it by looking at the virtual network in the portal. The gateway shouldappear as a connected device. In this last step you will create a connectionfor the device.

VPN Types

When you create the virtual network gateway for a VPN gatewayconfiguration, you must specify a VPN type. The VPN type that you choosedepends on the connection topology that you want to create. For example, aPoint-to-Site (P2S) connection requires a Route-based VPN type. A VPN typecan also depend on the hardware that you are using. Site-to-Site (S2S)configurations require a VPN device. Some VPN devices only support acertain VPN type.

The VPN type you select must satisfy all the connection requirements for thesolution you want to create. For example, if you want to create a S2S VPNgateway connection and a P2S VPN gateway connection for the same virtualnetwork, you would use VPN type Route-based because P2S requires a Route-based VPN type. You would also need to verify that your VPN devicesupported a Route-based VPN connection.

There are two VPN types:

• Policy-based VPNs. Policy-based VPNs encrypt and direct packetsthrough IPsec tunnels based on the IPsec policies configured with thecombinations of address prefixes between your on-premises network andthe Azure VNet. The policy (or traffic selector) is usually defined as anaccess list in the VPN device configuration. When using a Policy-basedVPN, keep in mind the following limitations:
  • Policy-Based VPNs can only be used on the Basic gateway SKU andis not compatible with other gateway SKUs.
  • You can have only 1 tunnel when using a Policy-based VPN.
  • You can only use Policy-based VPNs for S2S connections, and onlyfor certain configurations. Most VPN Gateway configurationsrequire a Route-based VPN.
• Route-based VPNs. Route-based VPNs use routes in the IP forwardingor routing table to direct packets into their corresponding tunnelinterfaces. The tunnel interfaces then encrypt or decrypt the packets inand out of the tunnels. The policy (or traffic selector) for Route-basedVPNs are configured as any-to-any (or wild cards).

Once a virtual network gateway has been created, you can’t change the VPNtype.

Gateway SKUs

When you create a virtual network gateway, you need to specify the gatewaySKU that you want to use. Select the SKU that satisfies your requirementsbased on the types of workloads, throughputs, features, and SLAs.

Aggregate Throughput Benchmark is based on measurements of multipletunnels aggregated through a single gateway. The Aggregate ThroughputBenchmark for a VPN Gateway is S2S + P2S combined. The AggregateThroughput Benchmark is not a guaranteed throughput due to Internet trafficconditions and your application behaviors.

These connection limits are separate. For example, you can have 128 SSTPconnections and also 250 IKEv2 connections on a VpnGw1 SKU.

✔️ The Basic SKU is considered a legacy SKU. The Basic SKU has certainfeature limitations. You can’t resize a gateway that uses a Basic SKU to one ofthe new gateway SKUs, you must instead change to a new SKU, whichinvolves deleting and recreating your VPN gateway.

Create the Local Network Gateway

The local network gateway typically refers to the on-premises location. Yougive the site a name by which Azure can refer to it, then specify the IP addressof the on-premises VPN device for the connection. You also specify the IPaddress prefixes that will be routed through the VPN gateway to the VPNdevice. The address prefixes you specify are the prefixes located in the on-premises network.

IP Address. The public IP address of the local gateway.

Address Space. One or more IP address ranges (in CIDR notation) thatdefine your local network’s address space. For example: 192.168.0.0/16. Ifyou plan to use this local network gateway in a BGP-enabled connection,then the minimum prefix you need to declare is the host address of your BGPPeer IP address on your VPN device.

Configure the On-Premises VPN Device

Microsoft has validated a list of standard VPN devices that should work wellwith the VPN gateway. This list was created in partnership with devicemanufacturers like Cisco, Juniper, Ubiquiti, and Barracuda Networks. If youdon’t see your device listed in the validated VPN devices table (referencelink), your device may still work with a Site-to-Site connection. Contact yourdevice manufacturer for additional support and configuration instructions.

To configure your VPN device, you need the following:

• A shared key. This is the same shared key that you will specify whencreating the VPN connection (next step).
• The public IP address of your VPN gateway. When you created theVPN gateway you may have configured a new public IP address or usedan existing IP address.

✔️ Depending on the VPN device that you have, you may be able todownload a VPN device configuration script.

For more information, you can see:

Validated VPN devices list – https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices#devicetable

Create the VPN Connection

Once your VPN gateways are created, you can create the connection betweenthem. If your VNets are in the same subscription, you can use the portal.

• Name. Enter a name for your connection.
• Connection type. Select VNet-to-VNet from the drop-down.
• First virtual network gateway. This field value is automatically filled inbecause you’re creating this connection from the specified virtualnetwork gateway.
• Second virtual network gateway. This field is the virtual networkgateway of the VNet that you want to create a connection to.
• Shared key (PSK). In this field, enter a shared key for your connection.You can generate or create this key yourself. In a site-to-site connection,the key you use is the same for your on-premises device and your virtualnetwork gateway connection. The concept is similar here, except thatrather than connecting to a VPN device, you’re connecting to anothervirtual network gateway.

✔️ If your VNets are in different subscriptions, you must use PowerShell tomake the connection. You can use the New-AzVirtualNetworkGatewayConnection.

Verify the VPN Connection

After you have configured all the Site-to-Site components it is time to verifythat everything is working. You can verify the connections either in the portal,or by using PowerShell.

Portal

When you view your connection in the Azure portal the Status should beSucceeded or Connected. Also, you should have data flowing in the Data inand Data out information.

PowerShell

To verify your connection with PowerShell, use the Get-AzVirtualNetworkGatewayConnection cmdlet. For example,

Get-AzVirtualNetworkGatewayConnection -Name MyGWConnection -ResourceGroupName MyRG

After the cmdlet has finished, view the values. The connection status shouldshow ‘Connected’ and you can see ingress and egress bytes.

"connectionStatus": "Connected", "ingressBytesTransferred": 33509044, "egressBytesTransferred": 4142431

ExpressRoute

ExpressRoute

Azure ExpressRoute lets you extend your on-premises networks into theMicrosoft cloud over a dedicated private connection facilitated by aconnectivity provider. With ExpressRoute, you can establish connections toMicrosoft cloud services, such as Microsoft Azure, Office 365, and CRMOnline.

Make your connections fast, reliable, and private

Use Azure ExpressRoute to create private connections between Azuredatacenters and infrastructure on your premises or in a colocationenvironment. ExpressRoute connections don’t go over the public Internet, andthey offer more reliability, faster speeds, and lower latencies than typicalInternet connections. In some cases, using ExpressRoute connections totransfer data between on-premises systems and Azure can give you significantcost benefits.

With ExpressRoute, establish connections to Azure at an ExpressRoutelocation, such as an Exchange provider facility, or directly connect to Azurefrom your existing WAN network, such as a multiprotocol label switching (MPLS) VPN, provided by a network service provider.

Use a virtual private cloud for storage, backup, and recovery

ExpressRoute gives you a fast and reliable connection to Azure withbandwidths up to 100 Gbps, which makes it excellent for scenarios likeperiodic data migration, replication for business continuity, disaster recovery,and other high-availability strategies. It can be a cost-effective option fortransferring large amounts of data, such as datasets for high-performancecomputing applications, or moving large virtual machines between your dev-test environment in an Azure virtual private cloud and your on-premisesproduction environments.

Extend and connect your datacenters

Use ExpressRoute to both connect and add compute and storage capacity toyour existing datacenters. With high throughput and fast latencies, Azure willfeel like a natural extension to or between your datacenters, so you enjoy thescale and economics of the public cloud without having to compromise onnetwork performance.

Build hybrid applications

With predictable, reliable, and high-throughput connections offered byExpressRoute, build applications that span on-premises infrastructure andAzure without compromising privacy or performance. For example, run acorporate intranet application in Azure that authenticates your customerswith an on-premises Active Directory service, and serve all of your corporatecustomers without traffic ever routing through the public Internet.

For more information, you can see:

ExpressRoute – https://azure.microsoft.com/en-us/services/expressroute/

ExpressRoute Capabilities

ExpressRoute is supported across all Azure regions and locations. Thefollowing map provides a list of Azure regions and ExpressRoute locations.ExpressRoute locations refer to those where Microsoft peers with severalservice providers. You will have access to Azure services across all regionswithin a geopolitical region if you connected to at least one ExpressRoutelocation within the geopolitical region.

There are many benefits to using ExpressRoute.

Layer 3 connectivity

Microsoft uses BGP, an industry standard dynamic routing protocol, toexchange routes between your on-premises network, your instances in Azure,and Microsoft public addresses. We establish multiple BGP sessions with yournetwork for different traffic profiles.

Redundancy

Each ExpressRoute circuit consists of two connections to two MicrosoftEnterprise edge routers (MSEEs) from the connectivity provider/your networkedge. Microsoft requires dual BGP connection from the connectivityprovider/your network edge – one to each MSEE. The graphic on the previoustopics shows the primary and secondary connection.

Connectivity to Microsoft cloud services

ExpressRoute connections enable access to the following services: MicrosoftAzure services, Microsoft Office 365 services, and Microsoft Dynamics 365.Office 365 was created to be accessed securely and reliably via the Internet,so ExpressRoute requires Microsoft authorization.

Connectivity to all regions within a geopolitical region

You can connect to Microsoft in one of our peering locations and accessregions within the geopolitical region. For example, if you connect toMicrosoft in Amsterdam through ExpressRoute, you’ll have access to allMicrosoft cloud services hosted in Northern and Western Europe.

Global connectivity with ExpressRoute premium add-on

You can enable the ExpressRoute premium add-on feature to extendconnectivity across geopolitical boundaries. For example, if you connect toMicrosoft in Amsterdam through ExpressRoute, you will have access to allMicrosoft cloud services hosted in all regions across the world (nationalclouds are excluded).

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. For example, if youhave a private data center in California connected to ExpressRoute in SiliconValley, and another private data center in Texas connected to ExpressRoute inDallas, with ExpressRoute Global Reach, you can connect your private datacenters together through two ExpressRoute circuits. Your cross-data-centertraffic will traverse through Microsoft’s network.

Bandwidth options

You can purchase ExpressRoute circuits for a wide range of bandwidths from50 Mbps to 10 Gbps. Be sure to check with your connectivity provider todetermine the bandwidths they support.

Flexible billing models

You can pick a billing model that works best for you. Choose between thebilling models listed below.

• Unlimited data. Billing is based on a monthly fee; all inbound andoutbound data transfer is included free of charge.
• Metered data. Billing is based on a monthly fee; all inbound datatransfer is free of charge. Outbound data transfer is charged per GB ofdata transfer. Data transfer rates vary by region.
• ExpressRoute premium add-on. This add-on includes increased routingtable limits, increased number of VNets, global connectivity, andconnections to Office 365 and Dynamics 365. Read more in the FAQlink.

For more information, you can see:

FAQ – Azure ExpressRoute – https://docs.microsoft.com/en-us/azure/expressroute/expressroute-faqs

ExpressRoute Connections

You can create a connection between your on-premises network and theMicrosoft cloud in three different ways, CloudExchange Co-location, Point-to-point Ethernet Connection, and Any-to-any (IPVPN) Connection.Connectivity providers can offer one or more connectivity models. You canwork with your connectivity provider to pick the model that works best foryou.

CloudExchange Co-location

If you are co-located in a facility with a cloud exchange, you can ordervirtual cross-connections to the Microsoft cloud through the co-locationprovider’s Ethernet exchange. Co-location providers can offer either Layer 2cross-connections, or managed Layer 3 cross-connections between yourinfrastructure in the co-location facility and the Microsoft cloud.

Point-to-point Ethernet connections

You can connect your on-premises datacenters/offices to the Microsoft cloudthrough point-to-point Ethernet links. Point-to-point Ethernet providers canoffer Layer 2 connections, or managed Layer 3 connections between your siteand the Microsoft cloud.

Any-to-any (IPVPN) networks

You can integrate your WAN with the Microsoft cloud. IPVPN providers,typically Multiprotocol Label Switching (MPLS) VPN, offer any-to-anyconnectivity between your branch offices and datacenters. The Microsoftcloud can be interconnected to your WAN to make it look just like any otherbranch office. WAN providers typically offer managed Layer 3 connectivity.

✔️ ExpressRoute capabilities and features are all identical across all theabove connectivity models.

Coexisting Site-to-Site and ExpressRoute

ExpressRoute is a direct, private connection from your WAN (not over thepublic Internet) to Microsoft Services, including Azure. Site-to-Site VPNtraffic travels encrypted over the public Internet. Being able to configure Site-to-Site VPN and ExpressRoute connections for the same virtual network hasseveral advantages.

You can configure a Site-to-Site VPN as a secure failover path forExpressRoute or use Site-to-Site VPNs to connect to sites that are not part ofyour network, but that are connected through ExpressRoute. Notice that thisconfiguration requires two virtual network gateways for the same virtualnetwork, one using the gateway type VPN, and the other using the gatewaytype ExpressRoute.

ExpressRoute and VPN Gateway coexisting connections example

✔️ Currently, the deployment options for S2S and ExpressRoute coexistingconnections are only possible through PowerShell, and not the Azure portal.

References

https://github.com/MicrosoftLearning/AZ-103-MicrosoftAzureAdministrator