VNET peering – Network Connectivity and Security
Any two VNETs can be connected using peering, and there are two types of peering available:
- VNET peering, which connects two VNETs in the same region
- Global VNET peering, which connects two VNETs in different regions
You can connect two VNETs that are in different subscriptions. However, you must ensure that the address spaces in each VNET do not overlap. So, if VNET 1 and VNET 2 both use the address range of 10.0.0.0/16, the peering will fail.
Peerings between VNETs are also non-transitive – this means that if you have three VNETs – VNET 1, VNET 2, and VNET 3 – and you create a peering between VNET 1 and VNET 2 and VNET 2 and VNET 3, devices in VNET 1 will not be able to access a resource in VNET 3 – in other words, you cannot traverse the two peers. Instead, you would have to explicitly connect VNET 1 to VNET 3 as well, as we can see in the following diagram:
Figure 8.11 – Peerings are not transitive
Peerings between VNETs are not the only type of network you may need to connect; the other common scenario is connecting on-premises networks into Azure. For this, we can use a VPN gateway.
VPN gateways
When you need to connect an on-premises network to Azure, you can use a VPN gateway. A VPN gateway uses a gateway device on your corporate network and a gateway device in Azure. The two are then connected with a VPN that uses the public network to create an encrypted route between your two gateways. In other words, you use the internet but your traffic is encrypted and, therefore, secure.
You can use two types of VPN – a Point to Site (P2S) VPN, used by individual clients to connect directly to a remote gateway, and a Site to Site (S2S) VPN, used to connect networks.
When creating a VPN connection, you can choose between a policy-based VPN or a route-based VPN.
Policy-based VPNs
Policy-based VPNs are generally used for connections using legacy VPN gateways, as they are not as flexible as route-based. Policy-based VPNs use IKEv1 protocols and static routing to define the source and destination network ranges in the policy, rather than in a routing table.
Route-based VPNs
Route-based VPNs are the preferred choice and should be used unless legacy requirements prevent it. Route-based VPNs use IKEv2 and support dynamic routing protocols whereby routing tables direct traffic based on discovery.
Important Note
Internet Key Exchange (IKE) v1 and v2 are VPN encryption protocols that ensure traffic is encrypted between two points by authenticating both the client and the server and then agreeing on an actual encryption method. IKEv2 is the successor to IKEv1. It is faster and provides greater functionality.
When creating a VPN, you have different sizes available, and the choice of size, or SKU, is dependent on your requirements. The following table shows the current differences:
The basic VPN is only recommended for use for dev/test and not for production. Also, basic does not support IKEv2 or RADIUS authentication. This may impact you depending on the clients using the VPN. For example, Mac computers do not support IKEv1 and cannot use a basic VPN for a P2S connection.
When creating a VPN connection, you need several services and components set up.