The VPN didn't leak your old IP: a remembered value did

Seeing your old public address in a service's report after the VPN comes up is not, on its own, evidence of a leak. The live connection can be using the tunnel exit while the application submits a value it learned before the tunnel existed. Those are two different pieces of evidence, and only one of them describes the current packet. The other is a value that survived the reconnect because nothing in the network path owns it.

The two explanations behind one address

The sequence people imagine is a packet leaving the physical interface while the VPN is supposedly active. The sequence that often explains the report is shorter and duller: an application learned an address earlier and still holds it. Laying the events out in order separates the two.

Address learned before the tunnel: P1
Tunnel up: the next request exits at P2
Application reuses its retained P1 in a message body
Receiver logs source P2 and submitted value P1

Nothing in that order requires a live connection from the first address. The remembered value rides inside the message, while the header carries whatever exit the current route chose. A service that logs both fields will show them side by side and look contradictory.

That is a possible explanation, not an accusation aimed at any particular client. Reputation is not evidence: a codebase you can read, a brand you trust or a different exit says nothing about what one program kept or sent.

Application memory outlives the reconnect

Connecting a VPN changes the route a new connection takes. It leaves application state alone, and it cannot retract information a remote service already stored. A program may submit an account identifier, a saved location, a device name or another value it obtained earlier, and encryption protects that payload in transit without removing anything from it. The reconnect is a network event; the retained value is an application event.

The distinction matters because the two live in different places. Application state belongs to the program and survives restarts, while the route belongs to the operating system and is rebuilt on every connect. Clearing one has no effect on the other.

A service can also hold a value you handed it months ago, in which case no local change will remove it. That is retention, and it sits outside the tunnel entirely.

Read the source header, then the payload

Start by pinning down where the address showed up. A server's connection log describes the live source, while a message field, an account profile or a local diagnostic display can describe a value submitted or stored much earlier. Those observations answer different questions.

Compare the times as well. If the old address appears in a field that predates the VPN connection, the payload explanation is stronger. If the server records a direct connection from the old address while the tunnel is up, that is a routing question and needs a different investigation. Sorting the observation types first keeps one address from being stretched into proof of three events.

Keep them apart in your notes: connection source, message field, account display, local diagnostic. One address written in four places is still one address.

Retention is a different stage from transport

The privacy guidance in RFC 6973 treats collection, use, disclosure and retention as distinct stages, and it warns that reused identifiers make correlation easy. A new network path changes the transport stage and nothing else. Records the recipient already holds are untouched by it, and so is any profile that stored the value on the way in. That is why a reconnect can feel like it failed while the transport is behaving correctly.

No packet filter can delete a value from a recipient's records, and reconnecting again will not clear every program's stored history. Those are data-owner problems rather than tunnel problems, and they need a different kind of fix. Ask the service what it keeps and for how long before asking the network to hide it.

What to check before blaming the tunnel

Review the application's documented collection and account controls, and decide which fields it may submit, how long the service keeps them, and whether the account can clear or correct them. Then run the test that separates the explanations: a fresh account or a clean application profile. If the old value disappears, retention or cached state was involved. If it survives a fresh profile, examine the actual request field before concluding that the VPN failed.

If a direct connection really is present, treat it as a network-path finding. Investigate routing, split tunnel and client policy on their own terms, and do not mix that result with a payload value that simply survived the reconnect. The two failures look alike in a screenshot and behave nothing alike in a capture.