Sending Internet Traffic from P2S Clients Through an NVA

Azure can be used to offer Point-To-Site (P2S) connectivity for individual users, that by leveraging a VPN client on their systems (Windows, Linux or Mac) can get connectivity to Azure resources. This P2S connectivity is often limited to Azure resources, but by leveraging the Azure Route Server, additional access is offered.

For example, if an ExpressRoute connection exists in Azure, just by deploying the Route Server in the same Virtual Network as the VPN and ExpressRoute Virtual Network Gateways, the P2S clients will gain network connectivity to on-premises resources as well.

The goal of this post is verifying whether Internet connectivity can be achieved using the Azure Route Server too. Sneak preview: yes it can! This is the topology tested:

As you can see, the NVA can advertise prefixes to the Route Server, the Route Server will propagate them towards the VPN Gateway, and the latter will program them in the VPN Client. My first test was advertising the 0.0.0.0/0 from the NVA to the Route Server. All was propagated down to the VPN Client, as this screenshot shows:

By the way, you can ignore the 10.1.0.0/16, this is a prefix propagated by the NVA that is not relevant for this scenario.

However, Internet connectivity from the PC was still going directly, not through the VPN tunnel. The fact that Azure splits the VNet prefix (192.168.0.0/16) in two (192.168.0.0/17 and 192.168.128.0/17) made me try the same thing with the default, and advertise it in two halves (0.0.0.0/1 and 128.0.0.0/1). This is the result in the VPN client:

Before verifying connectivity, let’s check the environment. Firstly, the Route Server is peered correctly with the NVA:

$ az network routeserver peering list --routeserver rs -g nva -o table
Name    PeerAsn    PeerIp    ProvisioningState    ResourceGroup
------  ---------  --------  -------------------  ---------------
nva     65001      10.1.2.4  Succeeded            nva

The Route Server is receiving the routes advertised from the NVA, and you can see that the ASN is 65001, the one configured on the NVA as described in the diagram above:

$ az network routeserver peering list-learned-routes -n nva --routeserver rs -g $rg --query 'RouteServiceRole_IN_0' -o table
LocalAddress    Network      NextHop    SourcePeer    Origin    AsPath    Weight
--------------  -----------  ---------  ------------  --------  --------  --------
10.1.1.4        0.0.0.0/0    10.1.2.4   10.1.2.4      EBgp      65001     32768
10.1.1.4        128.0.0.0/1  10.1.2.4   10.1.2.4      EBgp      65001     32768
10.1.1.4        10.1.0.0/16  10.1.2.4   10.1.2.4      EBgp      65001     32768
10.1.1.4        0.0.0.0/1    10.1.2.4   10.1.2.4      EBgp      65001     32768

In the BGP adjacencies of the VPN Gateway you can see the Route Server (the following output has been split in two, each VPN Gateway instance has three BGP adjacencies). The ASN of the Route Server is 65515, a non-customizable value at this point in time:

$ az network vnet-gateway list-bgp-peer-status -n vpngw -g $rg -o table
Neighbor    ASN    State      ConnectedDuration    RoutesReceived    MessagesSent    MessagesReceived
----------  -----  ---------  -------------------  ----------------  --------------  ------------------
10.1.1.4    65515  Connected  00:46:04.5693819     2                 63              66
10.1.1.5    65515  Connected  00:46:04.5537540     2                 63              67
10.1.0.4    65501  Connected  01:02:04.4743764     2                 84              88
10.1.0.5    65501  Unknown                         0                 0               0

10.1.1.4    65515  Connected  00:46:05.0984084     2                 63              66
10.1.1.5    65515  Connected  00:46:05.0984084     2                 62              64
10.1.0.4    65501  Unknown                         0                 0               0
10.1.0.5    65501  Connected  01:01:39.1186661     2                 92              86

And the BGP routes of the VPN Gateway contain the routes coming from the NVA, with the right AS path (65515 for the route server, 65001 for the NVA):

❯ az network vnet-gateway list-learned-routes -n vpngw -g $rg -o table
Network           Origin    SourcePeer    AsPath       Weight    NextHop
----------------  --------  ------------  -----------  --------  ---------
10.1.0.0/16       Network   10.1.0.5                   32768
0.0.0.0/0         EBgp      10.1.1.4      65515-65001  32768     10.1.1.4
0.0.0.0/0         EBgp      10.1.1.5      65515-65001  32768     10.1.1.5
0.0.0.0/0         IBgp      10.1.0.4      65515-65001  32768     10.1.0.4
128.0.0.0/1       EBgp      10.1.1.4      65515-65001  32768     10.1.1.4
128.0.0.0/1       EBgp      10.1.1.5      65515-65001  32768     10.1.1.5
128.0.0.0/1       IBgp      10.1.0.4      65515-65001  32768     10.1.0.4
0.0.0.0/1         EBgp      10.1.1.4      65515-65001  32768     10.1.1.4
0.0.0.0/1         EBgp      10.1.1.5      65515-65001  32768     10.1.1.5
0.0.0.0/1         IBgp      10.1.0.4      65515-65001  32768     10.1.0.4
192.168.0.0/17    IBgp      10.1.0.4                   32768     10.1.0.4
192.168.128.0/17  Network   10.1.0.5                   32768
192.168.0.0/17    EBgp      10.1.1.5      65515-65501  32768     10.1.1.5
192.168.0.0/17    EBgp      10.1.1.4      65515-65501  32768     10.1.1.4

10.1.0.0/16       Network   10.1.0.4                   32768
0.0.0.0/0         EBgp      10.1.1.4      65515-65001  32768     10.1.1.4
0.0.0.0/0         IBgp      10.1.0.5      65515-65001  32768     10.1.0.5
0.0.0.0/0         EBgp      10.1.1.5      65515-65001  32768     10.1.1.5
128.0.0.0/1       EBgp      10.1.1.4      65515-65001  32768     10.1.1.4
128.0.0.0/1       EBgp      10.1.1.5      65515-65001  32768     10.1.1.5
128.0.0.0/1       IBgp      10.1.0.5      65515-65001  32768     10.1.0.5
0.0.0.0/1         EBgp      10.1.1.4      65515-65001  32768     10.1.1.4
0.0.0.0/1         EBgp      10.1.1.5      65515-65001  32768     10.1.1.5
0.0.0.0/1         IBgp      10.1.0.5      65515-65001  32768     10.1.0.5
192.168.0.0/17    Network   10.1.0.4                   32768
192.168.128.0/17  IBgp      10.1.0.5                   32768     10.1.0.5
192.168.128.0/17  EBgp      10.1.1.5      65515-65501  32768     10.1.1.5
192.168.128.0/17  EBgp      10.1.1.4      65515-65501  32768     10.1.1.4

And sure enough, the client should have connectivity to the public Internet. To verify whether we are going through the NVA, I use ifconfig.co, a web site that will return the public IP of the client:

> curl -s4 ifconfig.co
20.86.190.96

If the Internet flow is going through the NVA, that public IP should be the one assigned to the NVA, which is easy to check:

$ az network public-ip show -n nva-pip -o table -g $rg
Name     ResourceGroup    Location    Zones    Address       AddressVersion    AllocationMethod    IdleTimeoutInMinutes    ProvisioningState
-------  ---------------  ----------  -------  ------------  ----------------  ------------------  ----------------------  -------------------
nva-pip  nva              westeurope           20.86.190.96  IPv4              Dynamic             4                       Succeeded

So all works as expected! The only caveat is that instead of advertising a 0.0.0.0/0, we had to send the default route in two halves (0.0.0.0/1 and 128.0.0.0/1). Note that only IPv4 routes are supported by the VPN Gateway today, so if the client has a dual stack, IPv6 traffic would flow outside of the tunnel. Something else I observed is that traffic originated in the Windows Subsystem for Linux (WSL2 in my case) doesn’t seem to work through the tunnel, maybe something to investigate in a future post.

Thanks for reading!