Understanding Client Address Pool & On-link Routing in Azure P2S VPN

Question

Hi,

Network Setup-
A simple Hub and Spoke model with the VPN Gateway configured with path based routing hosted in the hub network. A couple of spoke networks that are peered to the hub. P2S connections are established from a couple client machines to the Azure Network.
Address details-
Hub Vnet - 10.0.0.0/24
Spoke 1 Vnet - 10.1.0.0/24
Spoke 2 Vnet - 10.2.0.0/24
Address Pool assigned to the P2S connection clients - 172.16.50.0/24
A VM hosted in the Spoke 1 - 10.1.0.4

A similar setup is shown in the attached image.

Observation:
When I connect to the VPN from a windows machine, the client receives an address from the pool, say 172.16.50.130
When I do a basic ping test (after enabling ICMP) from the windows client to the VM in spoke 1, it works fine. This confirms the correctness of the setup.

When I check the routes in the windows client (using route print command),
IPv4 Route Table

===========================================================================

Active Routes:
NetworkDestination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.29.1 192.168.29.37 25
10.0.0.0 255.255.0.0 On-link 172.16.50.130 43
10.0.255.255 255.255.255.255 On-link 172.16.50.130 281
10.1.0.0 255.255.0.0 On-link 172.16.50.130 43
10.1.255.255 255.255.255.255 On-link 172.16.50.130 281
20.193.245.69 255.255.255.255 92.168.29.1 192.168.29.37 26

The Gateway in the route to the hub and the spoke networks from the windows client is marked as "On-Link".
Upon some reading from the following 2 articles, my understanding is that routes that don't need a gateway as the next hop will be marked as "On-Link"

https://superuser.com/questions/59996/what-does-on-link-mean-on-the-result-of-route-print-command

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/

The important piece of the answers,

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.

Also doing a tracert to the VM from the windows client shows just 1 hop and that is to the VM directly
Tracing Route to 10.1.0.4 over a maximum of 30 hops
1 29ms 28ms 28ms 10.1.0.4
Trace complete

Question
I understand the basic working of a VPN. The client machine is allocated an IP from the VPN server's address range. This is like virtually connecting the laptop to the cloud network so that it receives an IP from the same network.
However, the client's IP address is in 172.16.50.0/24 range and the hub and spokes are in the 10.0.0.0/24 and 10.1.0.0/24 address ranges.
How is the direct connection to the VM in the spoke accomplished? The answers from the forum posts for "On-Link" state that it is as if the VM's NIC is in the same subnet as the network destination it is trying to reach.

Any help to understand this concept would be much appreciated.

Thanks,
Sriram

Answer 1

I did some studying about the way that Azure handles the default routing between the multiple address spaces of a VNET. Refer to "Network" heading under the Default Routes section in this article for more information
https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#default

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

So when multiple address spaces are configured for a VNET, Azure automatically adds a default route for each of the address spaces. You can check this by deploying a VM in one of the Vnet's subnet and check the "effective routes" from its Nic's properties. You would find default routes to the below stated with "Virtual Network" as the next hop.
a) every other address space in the same VNET
b) every other address space of the peered or connected VNETS

The only tricky part is that when we configure the address pool for P2S connections, Azure creates and manages this as an additional address space of the Vnet. This would not be seen in the portal though. I did not try to check the same with PowerShell though.
When the client connects to the VPN, it receives an IP from the configured address pool. Since Azure manages the routing between the multiple address ranges the client would be able to access the VM's in the same hub VNET and the peered VNETS directly (without any gateway or involving multiple hops)

One quick test that I did to confirm my understanding -
a) Configured the P2S client address pool as stated in the ques - 172.16.100.0/24
b) Now tried to add a conflicting address space as a second one in the Hub Vnet - 172.16.0.0/16
This operation resulted in an error because of the conflict of address spaces.

One other post that talks about the working of routing when multiple address spaces (a more complicated one though)
learn.microsoft.com/en-us/answers/questions/48699/azure-virtual-network-gateway-subnet-with-multiple.html

Regards,
Sriram