VPN Connected but the IP Address Has Not Changed: Why

You connect, the client says connected, and the address test still shows the same number you had before. Nothing is wrong with the indicator; something between the profile and the application kept that request outside the tunnel. Decide which of three things you are looking at before you touch any configuration: a test that never measured the public address, a tunnel that only covers part of the traffic, or a second path that wins the routing decision. Each has one check that takes under a minute.

Confirm what the test actually measured

The address shown in the Wi-Fi or Ethernet dialog is the interface address on your own segment, not the address a website sees, so it can stay identical while the tunnel works perfectly. Location is a separate signal again: a saved account region or a permitted geolocation reading does not move when you change exit, and neither does a login that already recognises you.

Use a public-address echo and ask each family separately, because a dual-stack test result hides the interesting case:

curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me

Run both before and after connecting. If the IPv4 answer changes to the exit address and the IPv6 answer does not, you do not have a broken tunnel; you have one family travelling outside it. If both answers stay the same, the request never reached the tunnel at all and the rest of this applies.

The profile may only cover part of the traffic

A split-tunnel profile is the common answer, and it is not a fault. OpenVPN sends everything through the tunnel only when redirect-gateway is in the pushed options; without it the client receives a handful of specific routes and your default route stays on the physical link. On Windows the same switch appears as "Use default gateway on remote network" in the adapter's IPv4 properties, and clearing it is a deliberate choice that survives every reconnect.

Per-application scope is the second layer. Android's per-app VPN setting decides which apps are included, so the VPN key in the status bar does not prove that the browser is inside it. A browser extension that proxies its own traffic creates the mirror image: the browser shows the exit address while a mail client or game on the same machine still shows yours. Compare the same request in two applications. If one changes and the other does not, you are looking at scope, not at a failing tunnel.

One address family can still go direct

Most VPN profiles were written for IPv4, and many still are. On a dual-stack network the tunnel takes 10.8.0.x for IPv4 while the physical link keeps a global IPv6 address and a default route, so an IPv6-capable site is reached directly and the address it reports is your provider's. That is a leak with a working IPv4 tunnel, and it is invisible to a test that only speaks IPv4.

ip -4 route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Read the interface in each answer. If the IPv6 lookup names your Ethernet or Wi-Fi device while the IPv4 lookup names the tunnel, the policy for that family is missing rather than broken. Turning IPv6 off device-wide makes the symptom disappear and hides the decision; prefer fixing the profile's coverage or disabling the family on that one connection, and record which of the two you chose.

A second path can win the lookup

A competing proxy, a second VPN client, a virtual adapter from a container or remote-desktop tool, or an extra route for the exact prefix you are testing can all take precedence. A specific route always beats a default route, so a leftover /24 for the site you are measuring, pointing at your LAN gateway, keeps sending that traffic outside the tunnel no matter how healthy the tunnel is.

Take an inventory before you change anything, using read-only commands:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
nmcli connection show --active

Look for more than one default route with a plausible metric, and for a specific route covering the destination. In a browser, also check whether a proxy extension or the system proxy setting owns the connection; an extension can name its own upstream and leave the operating system's exit untouched, which produces a different address in the browser than in a terminal on the same machine.

Re-measure with a fresh request

Reconnect, then repeat the measurement from the same application you tested the first time, because a cached page or a reused connection reports the old state. Watch the client's log or event view during the connect: an error applying routes after authentication is stronger evidence than any indicator, and it usually names the route or the adapter that failed.

Keep two outcomes apart. If the address changes but one site still refuses you, the tunnel works and the site is rejecting a datacentre address; that is a different problem with a different answer. If the address never changes, work the four questions in order: which address did the test print, which family was it, which application made the request, and which route did that request follow. The Microsoft documentation on VPN routing decisions explains how a Windows client chooses between the tunnel and the physical adapter when both have a route.