Why point-to-site needs a route-based Azure VPN gateway

A policy-based gateway builds an IPsec tunnel selected by traffic selectors, and it has no interface to hand client routes to. Point-to-site is a routing feature: the gateway owns a client address pool and installs routes to those clients in the virtual network. That mismatch is why the portal shows no option to add it. Nothing on the existing gateway can be toggled to produce the interface, so the change is a replacement rather than a configuration edit.

The order matters more than the individual steps. Get the sequence wrong and the site-to-site outage runs past the maintenance window.

What a policy-based gateway actually does

A policy-based gateway matches packets against the traffic selectors configured on the connection and sends the matches into one tunnel. There is no tunnel interface with an address, and no per-client route appears anywhere in the virtual network. The route table simply gains the on-premises prefixes pointing at the gateway. That model is sufficient for a site-to-site connection between two fixed address spaces.

A route-based gateway works the other way round: it presents a tunnel interface, and routes decide what enters it. Point-to-site, and any design whose set of peers changes, depends on that interface existing.

Why the client pool needs that interface

When a laptop connects, the gateway assigns it an address from the point-to-site pool. The virtual network then needs a route saying that this address is reachable through the gateway. Without a tunnel interface there is nothing to attach that route to.

The pool comes from a range you nominate, and the gateway allocates from it. If that range overlaps the on-premises network or a peered virtual network, the conflict shows up only after a client connects, which is a poor moment to discover it. Reserve the pool before the migration starts.

Type is not a per-connection setting either. One gateway has one type, and every connection it holds behaves accordingly, so a mixed design needs a second gateway rather than a second connection.

The type is fixed at creation

Microsoft states that a virtual network gateway cannot be changed between policy-based and route-based after deployment. There is no conversion command and no portal toggle. Creating a second gateway in the same subnet is not a workaround either, because Azure allows one gateway per virtual network. The migration is therefore remove, rebuild, reconnect.

That also folds the SKU decision into the same build. Moving to a larger SKU later is another gateway replacement with another outage.

One gateway, one GatewaySubnet

The gateway lives in a subnet named GatewaySubnet, and only one gateway occupies it. Sizing that subnet belongs to the preparation, because a larger SKU needs more addresses and a subnet cannot be shrunk afterwards. Record the current site-to-site settings, shared key, local network gateway and effective routes before touching anything. Then treat the window as an outage, because the site-to-site tunnel stays down until the new connection is configured.

A rebuild order that keeps the outage bounded: create the route-based gateway, recreate the site-to-site connection to the same local network gateway, confirm the tunnel and one host-to-host request, and only then add point-to-site and generate a fresh client package.

What the replacement does not fix

A second limitation belongs to the peer rather than to Azure. A policy-based on-premises device can reach only the virtual network it connects to, and cannot transit to other on-premises networks or other virtual networks through the same gateway. Replacing the Azure side does not change what the peer is able to select.

If the requirement is really transit between sites, the answer is a route-based peer device or a topology where each destination terminates separately. Settle that before promising a date, because the gateway replacement alone will not deliver it.

Order of operations and checks

Verify each capability on its own. First the site-to-site tunnel status and one host-to-host request, then a point-to-site connection and one private resource, then any transit path the design claims. A green gateway status proves the security association came up and nothing more. Keep the checks in that order so a failure points at the stage that introduced it.

Regenerate client packages after any topology change, and keep the pool clear of every on-premises and peered range. The constraints and SKU differences are collected in the Azure VPN Gateway settings reference.