VNet Peering

Perhaps the simplest and quickest way to connect your VNets is to use 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. When creating a global
peering, the peered virtual networks can exist in any Azure public cloud region or China cloud regions, but
not in Government cloud regions. You can only peer virtual networks in the same region in Azure
Government cloud regions.

Benefits of virtual network peering

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 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.

Global VNet peering special requirements

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

 Cloud regions. When creating a global peering, the peered virtual networks can exist in any Azure
public cloud region or China cloud regions, but not in Government cloud regions. You can only peer virtual
networks in the same region in Azure Government cloud regions.
 Virtual network resources. Resources in one virtual network cannot communicate with the IP address
of an Azure internal load balancer in the peered virtual network. The load balancer and the resources that
communicate with it must be in the same virtual network.

For more information, Virtual network peering

Gateway Transit and Connectivity
When virtual networks are peered, you can configure a VPN gateway in the peered virtual network as a transit
point. In this case, a peered virtual network can use the remote gateway to gain access to other resources. A
virtual network can have only one gateway. Gateway transit is supported for both VNet Peering and Global
VNet Peering.

When you Allow Gateway Transit the virtual network can communicate to resources 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 share the gateway and get access to
resources. This means you do not need to deploy a VPN gateway in the peer virtual network.

✔️The default VNet peering configuration provides full connectivity. Network security groups can be applied
in either virtual network to block access to other virtual networks or subnets, if desired. When configuring
virtual network peering, you can either open or close the network security group rules between the virtual
networks.

Configure VNet Peering

Here are the steps to configure VNet peering. Notice you will need two virtual networks. To test the peering,
you will need a virtual machine in each network. Initially, the VMs will not be able to communicate, but after
configuration the communication will work. The step that is new is configuring 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 few optional configuration parameters to
consider.

Allow forwarded traffic. Allows traffic not originating from within the peer virtual network into your virtual
network.

Allow gateway transit. Allows the peer virtual network to use your virtual network gateway. The peer cannot
already have a gateway configured.

✔️When you add a peering on one virtual network, the second virtual network configuration is automatically
added.

✔️If you select ‘Allow gateway transit’ on one virtual network; then you should select ‘Use remote gateways’
on the other virtual network.

Service Chaining
VNet Peering is nontransitive. This means that if you establish VNet Peering between VNet1 and VNet2 and
between VNet2 and VNet3, VNet Peering capabilities do not apply between VNet1 and VNet3. However, you
can leverage user-defined routes and service chaining to implement custom routing 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 can host infrastructure components
such as a 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.

User-defined routes and service chaining

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

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

Checking connectivity

You can check the status of the VNet peering. The peering is not successfully established until the peering
status for both virtual network peerings shows Updating.

 Updating. When you create the peering to the second virtual network from the first virtual network, the
peering status is Initiated.
 Connected. When you create the peering from the second virtual network to the first virtual network,
the status is changed from Initiated to Connected.

Demonstration - VNet Peering

Note: For this demonstration you will need two virtual networks.

Configure VNet peering on the first virtual network

1. In the Azure portal, select the first virtual network.

2. Under SETTINGS, select Peerings.
3. Select + Add.
 Provide a name for the first virtual network peering. For example, VNet1toVNet2.
  In the Virtual network drop-down, select the second virtual network you would like to peer
with.
 Note the region, this will be needed when you configure the VPN gateway.
 Provide a name for the second virtual network peering. For example, VNet2toVNet1.
 Use the informational icons to review the network access, forwarded traffic, and gateway transit
settings.
 Check the box for Allow gateway transit. Note the error that the virtual network does not have a
gateway.
 Make sure the Allow gateway transit check box is not selected.
 Click OK to save your settings.

Configure a VPN gateway

1. In the Azure portal, search for virtual network gateways.

2. Select + Add.
 Provide a name for your virtual network gateway. For example, VNet1Gateway.
 Ensure the gateway is in the same region as the first virtual network.
 In the virtual network drop-down select the first virtual network.
 In the Public IP address area, Create new and give the IP address a name.
 Click Create and review. Address any validation errors.
 Click Create.
3. Monitor the notifications to ensure the gateway is successfully created.

Allow gateway transit

1. In the Azure portal, return to your first virtual network.

2. On the Overview blade, notice the new Connected device for your VPN gateway.
3. Select the gateway and notice you can perform a health check and review access statistics.
4. Return to the previous page and under SETTINGS, select Peerings.
 Select the peering and enable Allow gateway transit. Notice the previous error has been
resolved.
 Notice after making this selection, Use remote gateways is disabled.
5. Save your changes.

Confirm VNet peering on the second virtual network

1. In the Azure portal, select the second virtual network.

2. Under SETTINGS, select Peerings.
3. Notice that a peering has automatically been created. The name is what you provided when the first
virtual network peering was configured.
4. Notice that the Peering Status is Connected.
5. Click the peering.
 Notice that Allow gateway transit cannot be selected.
 Use the informational icon to review the Use remote gateways setting.
6. Discard your changes.

VPN Gateways
A VPN gateway is a specific type of virtual network gateway that is used to send encrypted traffic between an
Azure virtual network and an on-premises location over the public Internet. You can also use a VPN gateway to
send encrypted traffic between Azure virtual networks over the Microsoft network. Each virtual network can
have only one VPN gateway. However, you can create multiple connections to the same VPN gateway. When
you create multiple connections to the same VPN gateway, all VPN tunnels share the available gateway
bandwidth.

 Site-to-site connections connect on-premises datacenters to Azure virtual networks

 Network-to-network connections connect Azure virtual networks (custom)
 Point-to-site (User VPN) connections connect individual devices to Azure virtual networks

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.

VPN gateways can be deployed in Azure Availability Zones. This 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.

✔️Creating a virtual network gateway can take up to 45 minutes to complete.

Implement Site-to-Site Connections

Here are the steps to creating a VNet-to-VNet connections. The on-premises part is necessary only if you are
configuring Site-to-Site. We will review in detail each step.

Create VNets and subnets. By now you should be familiar with creating virtual networks and subnets.
Remember for this VNet to connect to an on-premises location. You need to coordinate with your on-premises
network administrator to reserve an IP address range that you can use specifically for this 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 resources that are deployed to your virtual network, you should specify a DNS
server in the virtual network configuration.

✔️Take time to carefully plan your network configuration. If a duplicate IP address range exists on both sides
of the VPN connection, traffic will not route the way you may expect it to.
Create the Gateway Subnet
Before creating a virtual network gateway for your virtual network, you first need to create the gateway subnet.
The gateway subnet contains the IP addresses that are used by the virtual network gateway. If possible, it's best
to create a gateway subnet by using a CIDR block of /28 or /27 to provide enough IP addresses to accommodate
future additional configuration requirements.

When you create your gateway subnet, gateway VMs are deployed to the gateway subnet and configured with
the required VPN gateway settings. You must never deploy other resources (for example, additional VMs) to
the gateway 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 network security group (NSG) to the gateway
subnet. Associating a network security group to this subnet may cause your VPN gateway to stop functioning as
expected.

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

VPN Gateway Configuration

The VPN gateway settings that you chose are critical to creating a successful connection.
 Gateway type. VPN or ExpressRoute.
 VPN Type. Route based or Policy based. The type of VPN you can choose depends on the make and
model of your VPN device, and the kind of VPN connection you intend to create. Choose a route-based
gateway if you intend to use point-to-site, inter-virtual network, or multiple site-to-site connections; if you
are creating a VPN type gateway to coexist with an ExpressRoute gateway; or if you need to use IKEv2.
Policy-based gateways support only IKEv1. Most VPN types are Route-based.
 SKU. Use the drop-down to select a gateway SKU. Route-based VPN types are offered in three SKUs:
Basic, Standard, and High performance. Standard or High performance must be chosen if you are using
ExpressRoute. A high performance SKU must be selected if you are using active-active mode. Your choice
will affect the number of tunnels you can have and the aggregate throughput benchmark. The benchmark is
based on measurements of multiple tunnels aggregated through a single gateway. It is not a guaranteed
throughput due to Internet traffic conditions and your application behaviors.
 Generation. Generation1 or Generation2. Changing generation or changing SKUs across generations is
not allowed. Basic and VpnGw1 SKUs are only supported in Generation1. VpnGw4 and VpnGw5 SKUs
are only supported in Generation2.
 Virtual Networks. The virtual network that will be able to send and receive traffic through the virtual
network gateway. A virtual network cannot be associated with more than one gateway.

✔️After the gateway is created, view the IP address that has been assigned to it by looking at the virtual
network in the portal. The gateway should appear as a connected device.

VPN Gateway Types

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

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

 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 usually defined as an access list in the VPN device
configuration. When using a Policy-based VPN, keep in mind 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 1 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.

✔️Once a virtual network gateway has been created, you can't change the VPN type.

Gateway SKUs and Generations

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

Ge S2S/VNet-to-VNet P2S IKEv2 Aggregate Throughput

SKU
n Tunnels Connections Benchmark

1 VpnGw1/Az Max. 30 Max. 250 650 Mbps

1 VpnGw2/Az Max. 30 Max. 500 1.0 Gbps

2 VpnGw2/Az Max. 30 Max. 500 1.25 Gbps

1 VPNGw3/Az Max. 30 Max. 1000 1.25 Gbps

2 VPNGw3/Az Max. 30 Max. 1000 2.5 Gbps

2 VPNGw4/Az Max. 30 Max. 5000 5.0 Gbps

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

✔️The Basic SKU (not shown) is considered a legacy SKU.

Create the Local Network gateway

The local network gateway typically refers to the on-premises location. You give the site a name by which
Azure can refer to it, then specify the IP address of the on-premises VPN device for the connection. You also
specify the IP address prefixes that will be routed through the VPN gateway to the VPN device. 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) that define your local network's address
space. For example: 192.168.0.0/16. If you 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 BGP Peer IP address on
your VPN device.

Configure the On-Premises VPN device

Microsoft has validated a list of standard VPN devices that should work well with the VPN gateway. This list
was created in partnership with device manufacturers like Cisco, Juniper, Ubiquiti, and Barracuda Networks. If
you don’t observe your device listed in the validated VPN devices table (reference link), your device may still
work with a Site-to-Site connection. Contact your device 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 when creating the VPN connection
(next step).
 The public IP address of your VPN gateway. When you created the VPN gateway you may have
configured a new public IP address or used an existing IP address.

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

For more information, Validated VPN devices list.

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.

 Name. Enter a name for your connection.

 Connection type. Select Site-to-Site (IPSec) from the drop-down.
 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
virtual network gateway connection. The concept is similar here, except that rather than connecting to a
VPN device, you're connecting to another virtual network gateway.

Verify the VPN Connection

After you have configured all the Site-to-Site components it is time to verify that everything is working. You
can verify the connections either in the portal, or by using PowerShell.
High Availability Scenarios
Active/standby
Every Azure VPN gateway consists of two instances in an active-standby configuration. For any planned
maintenance or unplanned disruption that happens to the active instance, the standby instance would take over
(failover) automatically, and resume the S2S VPN or VNet-to-VNet connections. The switch over will cause a
brief interruption. For planned maintenance, the connectivity should be restored within 10 to 15 seconds. For
unplanned issues, the connection recovery will be longer, about 1 minute to 1 and a half minutes in the worst
case. For P2S VPN client connections to the gateway, the P2S connections will be disconnected and the users
will need to reconnect from the client machines.

Active/active
You can now create an Azure VPN gateway in an active-active configuration, where both instances of the
gateway VMs will establish S2S VPN tunnels to your on-premises VPN device.

In this configuration, each Azure gateway instance will have a unique public IP address, and each will establish
an IPsec/IKE S2S VPN tunnel to your on-premises VPN device specified in your local network gateway and
connection. Note that both VPN tunnels are actually part of the same connection. You will still need to
configure your on-premises VPN device to accept or establish two S2S VPN tunnels to those two Azure VPN
gateway public IP addresses.

Because the Azure gateway instances are in active-active configuration, the traffic from your Azure virtual
network to your on-premises network will be routed through both tunnels simultaneously, even if your on-
premises VPN device may favor one tunnel over the other. Note though the same TCP or UDP flow will always
traverse the same tunnel or path, unless a maintenance event happens on one of the instances.

When a planned maintenance or unplanned event happens to one gateway instance, the IPsec tunnel from that
instance to your on-premises VPN device will be disconnected. The corresponding routes on your VPN devices
should be removed or withdrawn automatically so that the traffic will be switched over to the other active IPsec
tunnel. On the Azure side, the switch over will happen automatically from the affected instance to the active
instance.
Demonstration - VPN Gateway Connections
In this demonstration, we will explore virtual network gateways.

Note: This demonstration works best with two virtual networks with subnets. All the steps are in the portal.

Explore the Gateway subnet blade

1. For one of your virtual network, select the Subnets blade.

2. Select + Gateway subnet. Notice the name of the subnet cannot be changed. Notice the address
range of the gateway subnet. The address must be contained by the address space of the virtual network.
3. Remember each virtual network needs a gateway subnet.
4. Close the Add gateway subnet page. You do not need to save your changes.

Explore the Connected Devices blade

1. For the virtual network, select the Connected Devices blade.

2. After a gateway subnet is deployed it will appear on the list of connected devices.

Explore adding a virtual network gateway

1. Search for Virtual network gateways.

2. Click + Add.
3. Review each setting for the virtual netowrk gateway.
4. Use the Information icons to learn more about the settings.
5. Notice the Gateway type, VPN type, and SKU.
6. Notice the need for a Public IP address.
7. Remember each virtual network will need a virtual network gateway.
8. Close the Add virtual network gateway. You do not need to save your changes.

Explore adding a connection between the virtual networks

1. Search for Connections.
2. Click + Add.
3. Notice the Connection type can be VNet-to-VNet, Site-to-Site (IPsec), or ExpressRoute.
4. Provide enough information, so you can click the Ok button.
5. On the Settings page, notice that you will need select the two different virtual networks.
6. Read the Help information on the Establish bidirectional connnectivity checkbox.
7. Notice the Shared key (PSK) information.
8. Close the Add connection page. You do not need to save your changes.

ExpressRoute
Azure ExpressRoute lets you extend your on-premises networks into the Microsoft cloud over a dedicated
private connection facilitated by a connectivity provider. With ExpressRoute, you can establish connections to
Microsoft cloud services, such as Microsoft Azure, Office 365, and CRM Online.

Make your connections fast, reliable, and private

Use Azure ExpressRoute to create private connections between Azure datacenters and infrastructure on your
premises or in a colocation environment. ExpressRoute connections don't go over the public Internet, and they
offer more reliability, faster speeds, and lower latencies than typical Internet connections. In some cases, using
ExpressRoute connections to transfer data between on-premises systems and Azure can give you significant
cost benefits.

With ExpressRoute, establish connections to Azure at an ExpressRoute location, such as an Exchange provider
facility, or directly connect to Azure from 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 with bandwidths up to 100 Gbps, which makes
it excellent for scenarios like periodic data migration, replication for business continuity, disaster recovery, and
other high-availability strategies. It can be a cost-effective option for transferring large amounts of data, such as
datasets for high-performance computing applications, or moving large virtual machines between your dev-test
environment in an Azure virtual private cloud and your on-premises production environments.

Extend and connect your datacenters

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

Build hybrid applications

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

For more information, ExpressRoute.

ExpressRoute Capabilities
ExpressRoute is supported across all Azure regions and locations. The following map provides a list of Azure
regions and ExpressRoute locations. ExpressRoute locations refer to those where Microsoft peers with several
service providers. You will have access to Azure services across all regions within a geopolitical region if you
connected to at least one ExpressRoute location within the geopolitical region.

ExpressRoute benefits
Layer 3 connectivity
Microsoft uses BGP, an industry standard dynamic routing protocol, to exchange routes between your on-
premises network, your instances in Azure, and Microsoft public addresses. We establish multiple BGP sessions
with your network for different traffic profiles.

Redundancy

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

Connectivity to Microsoft cloud services

ExpressRoute connections enable access to the following services: Microsoft Azure 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 access regions within the geopolitical region.
For example, if you connect to Microsoft in Amsterdam through ExpressRoute, you'll have access to all
Microsoft 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 extend connectivity across geopolitical
boundaries. For example, if you connect to Microsoft in Amsterdam through ExpressRoute, you will have
access to all Microsoft cloud services hosted in all regions across the world (national clouds 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 you have a private data center in California connected to ExpressRoute
in Silicon Valley, and another private data center in Texas connected to ExpressRoute in Dallas, with
ExpressRoute Global Reach, you can connect your private data centers together through two ExpressRoute
circuits. Your cross-data-center traffic will traverse through Microsoft's network.

Bandwidth options

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

Flexible billing models

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

 Unlimited data. Billing is based on a monthly fee; all inbound and outbound data transfer is included
free of charge.
 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. Data transfer rates vary by region.
 ExpressRoute premium add-on. This add-on includes increased routing table limits, increased number
of VNets, global connectivity, and connections to Office 365 and Dynamics 365. Read more in the FAQ
link.
Coexisting Site-to-Site and ExpressRoute
ExpressRoute is a direct, private connection from your WAN (not over the public Internet) to Microsoft
Services, including Azure. Site-to-Site VPN traffic travels encrypted over the public Internet. Being able to
configure Site-to-Site VPN and ExpressRoute connections for the same virtual network has several advantages.

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

ExpressRoute and VPN Gateway coexisting connections example

ExpressRoute connection models

You can create a connection between your on-premises network and the Microsoft cloud in three different
ways, Co-located at a cloud exchange, Point-to-point Ethernet Connection, and Any-to-any (IPVPN)
Connection. Connectivity providers can offer one or more connectivity models. You can work with your
connectivity provider to pick the model that works best for you.
Co-located at a cloud exchange

If you are co-located in a facility with a cloud exchange, you can order virtual cross-connections to the
Microsoft cloud through the co-location provider’s Ethernet exchange. Co-location providers can offer either
Layer 2 cross-connections, or managed Layer 3 cross-connections between your infrastructure 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 cloud through point-to-point Ethernet
links. Point-to-point Ethernet providers can offer Layer 2 connections, or managed Layer 3 connections
between your site and 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-any connectivity between your branch offices and datacenters. The
Microsoft cloud can be interconnected to your WAN to make it appear just like any other branch office. WAN
providers typically offer managed Layer 3 connectivity.

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

Intersite Connections Comparison

There are many intersite connection choices. This table summarizes how to make a selection.

Azure Services
Connection Bandwidths Protocols Typical Use Case
Supported

Azure IaaS Dev, test, and lab

Virtual
services, Azure Based on the environments for
network, point- Active/passive
Virtual gateway SKU cloud services and
to-site
Machines virtual machines.

Dev, test, and lab

Azure IaaS
Virtual Typically < 1 environments. Small-
services, Azure Active/passive,
network, site- Gbps scale production
Virtual Active/active
to-site aggregate workloads and virtual
Machines
machines.

Azure IaaS and

Enterprise-class and
PaaS services,
50 Mbps up to mission-critical
ExpressRoute Microsoft Active/active
100 Gbps workloads. Big data
Office 365
solutions.
services

Virtual WANs
Azure Virtual WAN is a networking service that provides optimized and automated branch connectivity to, and
through, Azure. Azure regions serve as hubs that you can choose to connect your branches to. You can leverage
the Azure backbone to also connect branches and enjoy branch-to-VNet connectivity. There is a list of partners
that support connectivity automation with Azure Virtual WAN VPN.

Azure Virtual WAN brings together many Azure cloud connectivity services such as site-to-site VPN, User
VPN (point-to-site), and ExpressRoute into a single operational interface. Connectivity to Azure VNets is
established by using virtual network connections. It enables global transit network architecture based on a
classic hub-and-spoke connectivity model where the cloud hosted network ‘hub’ enables transitive connectivity
between endpoints that may be distributed across different types of 'spokes'.

Virtual WAN advantages

 Integrated connectivity solutions in hub and spoke. Automate site-to-site configuration and
connectivity between on-premises sites and an Azure hub.
 Automated spoke setup and configuration. Connect your virtual networks and workloads to the Azure
hub seamlessly.
 Intuitive troubleshooting. You can see the end-to-end flow within Azure, and then use this information
to take required actions.

Virtual WAN types

There are two types of virtual WANs: Basic and Standard.

Virtual WAN Hub

Available configurations
type type

Basic Basic Site-to-site VPN only

 Virtual WAN Hub
Available configurations
type type

ExpressRoute, User VPN (P2S). VPN (site-to-site), Inter-hub and

Standard Standard
VNet-to-VNet transiting through the virtual hub.

For more information, About Azure Virtual WAN.

Lab 05 - Implement Intersite Connectivity

Lab scenario
Contoso has its datacenters in Boston, New York, and Seattle offices connected via a mesh wide-area network
links, with full connectivity between them. You need to implement a lab environment that will reflect the the
topology of the Contoso's on-premises networks and verify its functionality.
Objectives
In this lab, you will:
 Task 1: Provision the lab environment.
 Task 2: Configure local and global virtual network peering.
 Task 3: Test intersite connectivity.

✔️Consult with your instructor for how to access the lab instructions and lab environment (if provided).

Module 05 Review Questions

Review Question 1
You want to connect different VNets in the same region as well as different regions and decide to use VNet
peering to accomplish this. Which of the following statements are true benefits of VNet peering? Select two.

 The virtual networks can exist in any Azure cloud region.

 Network traffic between peered virtual networks is private.

 Peering is easy to configure and manage, requiring little to no downtime.

 Gateway transit can be configured regionally or globally.

Explanation

Peering is efficient as there is no downtime to resources in either virtual network when creating the peering, or
after the peering is created. Also, for security, Network traffic between peered virtual networks is private.
Traffic between the virtual networks is kept on the Microsoft backbone network. While virtual networks can
exist in any Azure public cloud region, they cannot exist in Azure national clouds. National clouds have very
specific customer requirements to their use and operation. These services are confined within the geographic
borders of specific countries and operated by local personnel. Gateway transit only applies to regional VNet
peering and not to global VNet peering.

Check Answers

Review Question 2
Your company is preparing to implement a Site-to-Site VPN to Microsoft Azure. You are selected to plan and
implement the VPN. Currently, you have an Azure subscription, an Azure virtual network, and an Azure
gateway subnet. You need to prepare the on-premises environment and Microsoft Azure to meet the
prerequisites of the Site-to-Site VPN. Later, you will create the VPN connection and test it. What should you
do? (Each answer presents part of the solution. Select three.

 Obtain a VPN device for the on-premises environment.

 Obtain a VPN device for the Azure environment.

 Create a virtual network gateway (VPN) and the local network gateway in Azure.

 Create a virtual network gateway (ExpressRoute) in Azure.

 Obtain a public IPv4 IP address without NAT for the VPN device.

 Obtain a public IPv4 IP address behind NAT for the VPN device.

Explanation

The prerequisites for a Site-to-Site VPN are having a compatible VPN device on-premises, having a public IPv4
IP without NAT on the on-premises VPN device, and creating a VPN gateway and local network gateway in
Azure. IPv6 is not supported for VPNs. ExpressRoute is a different setup and not part of a Site-to-Site VPN.

Check Answers

Review Question 3
Your company is preparing to implement persistent connectivity to Microsoft Azure. The company has a single
site, headquarters, which has an on-premises data center. The company establishes the following requirements
for the connectivity:

 Connectivity must be persistent.

 Connectivity must provide for the entire on-premises site.

You need to implement a connectivity solution to meet the requirements. What should you do? Select one.

 Implement a Site-to-Site VPN.

 Implement a Virtual Private Cloud (VPC).

 Implement a Virtual Private Gateway (VGW).

 Implement a VNet-to-VNet VPN.

 Implement a Point-to-Site VPN.

Explanation

In this scenario, only one of the answers provides persistent connectivity to Azure - the Site-to-Site VPN. A
VNet-to-VNet connects two Azure virtual networks together. A Point-to-Site VPN is used for individual
connections (such as for a developer). A VPC and VGW are relevant to Amazon AWS.

Check Answers

Review Question 4
You are configuring VNet Peering across two Azure two virtual networks, VNET1 and VNET2. You are
configuring the VPN Gateways. You want VNET2 to be able to use to VNET1's gateway to get to resources
outside the peering. What should you do? Select one.

 Select allow gateway transit on VNET1 and use remote gateways on VNET2.

 Select allow gateway transit on VNET2 and use remote gateways on VNET1.
 Select allow gateway transit and use remote gateways on both VNET1 and VNET2.

 Do not select allow gateway transit or use remote gateways on either VNET1 or VNET2.

Explanation

Select allow gateway transit on VNET1 and use remote gateways on VNET2. VNET1 will allow VNET2 to
transit external resources, and VNET2 will expect to use a remote gateway.

Check Answers

Review Question 5
You are configuring a site-to-site VPN connection between your on-premises network and your Azure network.
The on-premises network uses a Cisco ASA VPN device. You have checked to ensure the device is on the
validated list of VPN devices. Before you proceed to configure the device what two pieces of information
should you ensure you have? Select two.

 The shared access signature key from the recovery services vault.

 The shared key you provided when you created your site-to-site VPN connection.

 The gateway routing method provided when you created your site-to-site VPN connection.

 The static IP address of your virtual network gateway.

 The public IP address of your virtual network gateway.

 The user and password for the virtual network gateway.

Explanation

You will need two things: shared key and the public IP address of your virtual network gateway. The shared key
was provided when you created the site-to-site VPN connection.

Check Answers

Review Question 6
You manage a large datacenter that is running out of space. You propose extending the datacenter to Azure
using a Multi-Protocol Label Switching virtual private network. Which connectivity option would you select?
Select one.

 Point-to-Site

 VPN Peering

 Multi-site
 Site-to-Site

 ExpressRoute

 VNet-to-VNet

Explanation

ExpressRoute is the best choice for extending the datacenter, as it can use an any-to-any (IPVPN) connectivity
model. An MPLS VPN, as typically provided by an IPVPN network, enables connectivity between the
Microsoft cloud and your branch offices and datacenters.

Check Answers

Review Question 7
You are creating a connection between two virtual networks. Peformance is a key concern. Which of the
following will most influence performance? Select one.

 Ensuring you select a route-based VPN.

 Ensuring you select a policy-based VPN.

 Ensuring you specify a DNS server.

 Ensuring you select an appropriate Gateway SKU.

Explanation

The Gateway SKU selection directly affects performance. Gateway SKUs control the number of tunnels and
connections that are available. This affects the overall aggregate throughput of the connection.

Check Answers

Review Question 8
Your manager asks you to verify some information about Azure Virtual WANs. Which of the following
statements are true? Select three.

 You must use one of the approved connectivity partner providers.

 You must use a VPN device that provides IKEv2/IKEv1 IPsec support.

 Virtual WAN supports ExpressRoute.

 Virtual WAN supports site-to-site connections.

 Virtual WAN does not support point-to-site connections.

 You can switch between the Basic and Standard plans at any time.

Explanation

Virtual WAN supports ExpressRoute and any VPN device that is IKEv2/IKEv1 IPSec compliant.

Check Answers

Additional Study
Microsoft Learn provides self-paced skills training on a variety of topics. These Learn modules cover the
content you have just learned. You can search for additional modules by product, role, or level.

 Distribute your services across Azure virtual networks and integrate them by using virtual network
peering
 Connect your on-premises network to Azure with VPN Gateway
 Connect your on-premises network to the Microsoft global network by using ExpressRoute