Azure Private IP VPN Over ExpressRoute Without an NVA

The myth is that encrypting traffic over ExpressRoute private peering requires a network virtual appliance. It does not. Azure supports a Site-to-Site VPN Gateway whose tunnel endpoint is a private RFC1918 address carried across the circuit, and the appliance is optional rather than structural. What the appliance myth hides is the part that actually bites: enabling the private endpoint on one object instead of two, and letting a direct peering route quietly win over the encrypted path.

Where the myth came from

The claim has a respectable ancestry. For years the practical recipe for IPsec over private peering was an NVA, because the managed gateway exposed only public endpoints. That changed, and answers written before the change are still quoted in threads where nobody checks the date. The correction is narrow: a private-addressed VPN gateway exists, and it changes the endpoint, not the routing logic around it.

None of this retires the NVA. It retires the assumption that an appliance is the only path to the requirement.

Enable the private endpoint at both levels

Start from a working ExpressRoute private-peering connection linked to the VNet that holds the VPN gateway. The on-premises side must already reach the relevant private addresses across that circuit, because the tunnel will use those addresses as transport. Then the gateway prerequisite: the Microsoft procedure for private-IP VPN requires a gateway built on a Standard public IP resource. Private tunnel addressing does not remove that requirement, which surprises people who assume "private" means "no public IP anywhere".

Now enable the flag in both places. The gateway configuration has its own toggle for private IPs, and the individual Site-to-Site connection has a second one that makes that connection use the private address. Setting one and not the other is the single most common incomplete configuration; the tunnel either fails to establish or establishes to the wrong endpoint.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

Confirm the property names against the CLI version you have installed, because portal labels and CLI properties do not always share wording. An active-active gateway exposes two private tunnel addresses, and the on-premises device needs both peers configured if you want that redundancy to mean anything. BGP is not required simply to bring this private-addressed tunnel up, although it is usually part of how you distribute prefixes.

The second myth: an established tunnel encrypts your traffic

Two paths now reach the application network: the direct private-peering path and the path through the VPN. Both work. Only one applies this IPsec layer. Microsoft documents that when identical prefixes are advertised over ExpressRoute and over the VPN, Azure prefers the direct ExpressRoute path, so a healthy tunnel with healthy counters proves nothing about where application packets went.

The documented steering methods are a covering range on ExpressRoute with a more specific protected range on the VPN, or disjoint prefixes on the two paths. For an illustration, private peering could carry 10.40.0.0/16 while the VPN advertises 10.40.12.0/24. The more specific prefix wins and the rest of the range stays direct.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

Do the same check in the on-premises direction, since your router's preference decides which way outbound traffic leaves. And keep the tunnel's own transport on the ExpressRoute path; a route that pulls the gateway's private endpoint into the tunnel makes the tunnel depend on itself.

Decide what happens when the tunnel drops

A more specific VPN route disappears when the tunnel goes down, while the broader direct route stays. Traffic then flows unencrypted and everything looks healthy, which is the worst failure mode for a requirement that exists to guarantee encryption. If the requirement forbids that fallback, the routing and the access policy have to say so explicitly rather than relying on the tunnel's availability.

Write down which prefixes may stay directly reachable and which must stop when the encrypted path is absent. Then test the permitted case with real traffic and compare the connection counters, because the route table alone will not tell you whether the encryption requirement still holds.

That framing also lets you evaluate an NVA for its actual features, such as multiple tunnels, throughput or vendor inspection, instead of buying one because the endpoint is private.