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.

Network Architecture

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

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.

On-Link Routes

it’s just a route that’s directly reachable, the NIC is in direct contact with it; on the same subnet. To explain a little further though: by contrast, the routes that have a gateway IP listed must be contacted through that gateway.

https://wiert.me/2012/05/11/the-meaning-of-on-link-in-the-ipv4-result-of-the-route-print-command-windows-7-2008-vista-via-super-user/

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.

Tracert to 10.1.0.4 happens in 1 hop, directly to the machine and not through the VPN GW
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?

Azure routes traffic between address ranges within the address space of a virtual network. Azure creates a route with an address prefix that corresponds to each address range defined within the address space of a virtual network. If the virtual network address space has multiple address ranges defined, Azure creates an individual route for each address range

https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#system-routes
SourceAddress prefixesNext hop type
DefaultUnique to the virtual networkVirtual network
The How

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