Why Azure Point-to-Site VPN Doesn't Change Your Public IP

I connect the Azure VPN client on a Windows laptop, open an address-echo page, and see the same public address my home router handed out. Meanwhile the jump box at 10.20.0.4 answers and a private endpoint name resolves, so the tunnel is not broken. A point-to-site gateway is doing exactly what its default configuration says: carrying the private prefixes and leaving everything else on the local link. Getting an Azure-owned egress address is a change of routing design, not a repair.

What the gateway advertises by default

The gateway pushes routes for the virtual network address space, plus peered networks where gateway transit is allowed and on-premises prefixes learned over a site-to-site connection or BGP. There is no 0.0.0.0/0 in that set. Your operating system keeps its default route on Wi-Fi or Ethernet, so a packet to a public API never enters the tunnel in the first place.

The address a client receives inside the tunnel is a private lease from the point-to-site pool. It identifies the client to resources in the VNet; it is not an address the internet can see, and it will never appear as the source of an outbound request to a SaaS API. An allowlist entry built around that lease cannot work, however long you wait for it to show up in the vendor logs.

Split tunnel and forced tunneling side by side

Only the second row changes the address a remote service sees. Everything else in that table is cost and operational surface you accept when egress has to be inspected or translated inside Azure. If someone asks you to make the public IP change, they are asking for the whole right-hand column, not for a tweak to the client.

There is a middle option worth naming before you rebuild anything. A proxy or gateway VM inside the VNet gives you a controlled source address for the applications that can be pointed at it, without moving the client default route. That keeps normal browsing local and still satisfies a partner that only needs one API call to arrive from Azure. It fails when the requirement is really about all traffic, because anything that ignores the proxy setting still leaves locally.

Make the tunnel carry the default route

On a virtual network gateway, the supported way to steer all client internet traffic into the tunnel is to add custom routes to the point-to-site configuration. Two halves cover the whole IPv4 space, and each is more specific than the local default route, so the client prefers them without deleting anything:

Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1

That line is illustrative rather than copy-paste complete: fetch the gateway object first with Get-AzVirtualNetworkGateway and substitute it for GWOBJ, and confirm the SKU and deployment model accept custom routes before running it. The same prefixes appear in the portal on the point-to-site configuration page, which is the safer place to set them if you are not already scripting the gateway.

Changing those prefixes invalidates the client package. Download the VPN client package again and reinstall it, because the routes travel inside the profile. A client that reconnects with its old profile keeps the old route set, and you can lose an hour debugging a change that never reached it.

In a secured virtual WAN hub the equivalent is a default route in the hub route table associated with the point-to-site gateway, with Azure Firewall in the hub taking the traffic. The firewall translates internet-bound connections to its own public IP addresses, and that translation is where the new egress address comes from. When a firewall has several public IPs, any of them can show up as the source, so an allowlist has to hold all of them.

Both designs above are IPv4. The two /1 prefixes do nothing for IPv6, and point-to-site IPv6 support is narrow enough that you should test the combination before promising parity.

Check the route, then check the exit

After reinstalling the package and reconnecting, confirm the client actually installed the halves. On Windows, Get-NetRoute -DestinationPrefix 0.0.0.0/1 and the same query for 128.0.0.0/1 should name the tunnel interface, and route print shows both next to your original default. On Linux, ip route show must list the two prefixes; if it does not, the profile never carried them.

Then re-check the public address from the client and read the firewall log for the same connection. The source should be the firewall public IP with a translated port. A client that still exits locally while both routes exist means packets reached Azure and left by another path: a user-defined route on the gateway subnet, a firewall that is itself forced-tunneled to on-premises, or a policy that drops the flow before translation.

Re-test one private destination in the same session. A jump host that stops answering after the change is the usual sign that the new prefixes displaced something, either a narrower on-premises route that used to be advertised or name resolution that now goes to a resolver with no forwarder for your private zones.

When to leave the split tunnel alone

If the goal is only to reach a private API, a private endpoint or an internal admin page, the default behaviour is cheaper and quieter. Forced tunneling adds firewall hours and data-processing charges, a longer path, and one more place where every client flow can fail. It also captures far more traffic than the single destination you cared about.

Reach for it when the requirement is stated in terms of egress: a partner must see a fixed Azure address, security wants the connections logged and inspected, or data has to leave through one controlled point. Even then the design gives every user a shared exit, so per-user accountability has to come from identity at the application rather than from the source address.

Before you close the change, confirm four things: the installed client package is the new one, the two /1 routes sit on the tunnel interface, a private destination still answers, and the remote service log shows the firewall address.