Basics of P2S in Azure
Point to Site (P2S) VPN connections in Azure create a connection between a client machine and the target Azure Virtual Network. If you had watched the installation of the VPN client package closely, you would have seen a step where static routes would be created in your Windows/Linux systems. These routes tell the client how to reach a connected network, Azure VNET in this case. The installed routes can extend beyond this step and contain information about how to reach a VNET that is peered to a directly connected VNET.
Below shown is the network architecture diagram for the P2S setup. The client is connected to Azure network through the route-based VPN Gateway. On the completion of the connection, 2 things happen.
- The client receives an IP address from the client address pool and
- The Gateway publishes routes that get added to the client device
CIDR Range details
- Azure VNET – 10.0.0.0/16 (address space 1, HUB VNET)
- VPN Gateway Subnet – 10.0.1.0/27
- Azure VNET – 172.16.50.0/24 (address space 2- client address pool)
- Azure VNET – 10.10.0.0/16 (Spoke VNET)
- Storage Account , public IP of blob STA- 188.8.131.52
This is an image from the “route print” command after the P2S connection is established. You would see routes to the hub vnet and the spoke. The traffic exchange to these networks would happen through the second network interface card with an IP from the 172.16.50.0/24 address pool. However the gateway is shown as “On-Link“. What does that mean? This is one of the key takeaways of this post.
This is how the conventional VPN’s work. The behavior is as if the client’s machine has been ported and planted in the Azure Network. This is illustrated in the architecture diagram as well. How do we verify this though? try a Tracert command to a VM in the connected network.
System Defined Routes in Azure VNET
So far so good. At this point the obvious question would be
- How is a machine with an IP in the range 172.16.50.0/24 able to communicate with VMs in the 10.0.0.0/16 and 10.1.0.0/16 ranges?
|Source||Address prefixes||Next hop type|
|Default||Unique to the virtual network||Virtual network|
This table is an excerpt from the documentation, link to which is added in the citation. This means that routes are added between the multiple address spaces of the hub vnet. A representation of the routes would be
- 10.0.0.0/16 to 172.16.50.0/24
- 172.16.50.0/24 to 10.0.0.0/16
- 10.0.0.0/16 to 10.1.0.0/16 (Peered VNET)
- 172.16.50.0/24 to 10.1.0.0/16 (Peered VNET)
This answers the question of how a machine with an IP 172.16.50.130 is able to ping a VM with an IP 10.1.0.4 and how the same happens in 1 hop.
In the next post, we will discuss how traffic to an Azure PAAS service’s public endpoint can be kept within the VPN connection?
#AzureNetworking #P2SVPN #AzureSystemDefinedRoutes #NetworkInternals