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:

Internet traffic flow from P2S client through NVA

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:

Azure VPN Client for Windows

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!

18 thoughts on “Sending Internet Traffic from P2S Clients Through an NVA

  1. Aris

    Would you advise this pattern? Seems like a lot of work to configure a P2S VPN connection as a proxy gateway instead of split tunneling.

    There is not a lot of information out there about the different options for P2S VPN connections towards Azure with the forward proxy functionality, although it should be in high demand for cloud only companies who’d like their traffic to go through a VPN 🙂

    Liked by 1 person

    1. Hey Aris, in some of my customer interactions forced tunneling is a must. It is really not a lot of work, since the NVA would probably already exist in the VNet. If you prefer split tunneling, that is certainly easier though 🙂

      Liked by 1 person

  2. dw5304

    any chance you could provide a complete setup or how to for the entire deployment? seem to be getting stuck at the first step verifying the route server is good lol….

    Liked by 1 person

    1. Hey there! Not exactly this scenario with P2S, but the rest can probably be deployed using snippets from https://github.com/erjosito/azcli/blob/master/routeserver.azcli

      Liked by 1 person

  3. daviswe

    This is an excellent post. I’ve setup my NVA in azure but there’s no ASN for it in any of the configuration pages. Is this something that can be added? Also what type of NVA did you use? Lastly where did you add prefixes in NVA for 0.0.0.0/1 etc to be advertised to Route Server? Thank you!!!

    Like

    1. Hey daviswe, happy you liked the post! I am normally using an Ubuntu VM with BIRD as NVA, but any other one supporting BGP should do. The ASN can be anything out of the reserved ones by Microsoft (65515-65520 and a few more). Your advertisements need to be defined in the NVA.

      Like

  4. Hi
    first of all, thanks for the detailed posts on VPN/network tunneling. I have created this topoloy with Azure VPN gateway and Ubuntu Bird (as your other postes) and route server. I am using P2S OpenVPN with Azure AD authentication. I can see the BGP route advertised from NVA to Azure Gateway via RouteServer and all peering looks ok but when i connect VPN client. the only routes there are for the vNet and VPN range, it does not advertise default 0.0.0.0/1 and 128.0.0.0/1 to client. any suggestion?

    many thanks

    Like

  5. Most Lourh

    Thank you for this interesting Article.
    The router is required to deploy this design so P2S clients can connect to the Internet only by using VPN Gateway and NVA?

    Thanks

    Like

    1. Happy this is helpful! Azure Route Server is required so that the firewall in Azure (NVA) can advertise the default route to the P2S clients through the VPN Gateway, but it is actually not in the data path.

      Like

      1. Most Lourh

        Thank you Jose, I am looking for a less expensive solution to connect more than 15 remote VPN clients through a unique Public IP address to the Internet: clients will connect to the VPN Gateway and subsequently go out to the Internet (to connect à secured Web sites using IP Restriction, hosted on a partner Datacenters) via the same public IP. Using route server and Azure Firewall is more expensive especially, I am not looking for a security solution but only routing / SNAT, is it possible to use tow Ubuntu VMs for the both roles (Router and NVA)? thanks

        Like

      2. The design above doesnt work wit Azure Firewall, since it doesnt support BGP.
        The cheapest solution I know would be installing an OpenVPN server in Azure.

        Like

  6. Jean-François Doyon

    Why si the Route Server required? If the NVA and the Virtual Gateway can both talk BGP, can’t they talk directly to each other?

    Like

    1. No, the VNG’s BGP stack is not configurable. If you don’t use the route server, you need to advertise routes through methods other than BGP: static routing or an “advertising VNet”

      Like

  7. Jean-François Doyon

    “No, the VNG’s BGP stack is not configurable.” Well you can set the AS number, and you get a Peering IP. But it’s limited. Thing is the docs don’t seem to mention any requirement for the peer to be a route server (https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-bgp-overview), although this may be about BGP peering over the remote link, not within the VNet? I’m trying to put a VGW in a spoke vnet, with the NVA and ER in the hub vnet. Not having much success. I guess I’ll have to try it the way you suggest with the VGW and ER in the same VNet as the NVA (You have another post on that). It’s just that that Route Server is expensive for what it’ll do! Thanks a lot!

    Like

    1. Hey, that’s right, you cannot talk BGP to the VPN GW if it’s not via an IPsec tunnel.

      In the article I have both models, with the VPN GW in the same VNet and in a different one from the ER GW.

      If you don’t want to use ARS, the “advertising VNet” trick is usually a good one.

      One thing to consider is that if you place the gateways in different VNets, you are probably going to need NVAs (such as Azure Firewall)

      Like

  8. Vincent

    Thanks for the sharing. I would like to confirm a question about if azure does support P2S and ER transit with ARS. from the FQA, it looks like it’s not supported.
    https://learn.microsoft.com/en-us/azure/route-server/route-server-faq#can-azure-route-server-provide-transit-between-expressroute-and-a-point-to-site-p2s-vpn-gateway-connection-when-enabling-the-branch-to-branch
    but from this sharing. “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.” it sounds like it’s supported.
    could you please help clarify? many thanks.

    Like

    1. Good catch. Microsoft is evaluating whether using ARS for P2S and ER transit is supported. Frankly I haven’t come across any situation where this doesn’t work, but as of now, that FAQ you reference to is correct.
      The next question is whether the pattern I have here is supported, since I was only able to make it work using ASNs other than 65515 on the VPN Gateway. The answer to that one is probably a more clear no, even if it works too :-(.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: