What a Work VPN Gateway Can See About Where You Are

The address a website sees after you connect to a work VPN is not the address the work gateway saw when you connected. The gateway accepts an incoming tunnel from whatever network your laptop is on, and that source is visible to it before any tunnelled traffic exists. A browser reporting a corporate exit afterwards does not erase the earlier observation, because the two are observations of different things. Understanding which is which settles most of the argument about what an employer can and cannot infer.

Two addresses, two different observations

The mechanism is a socket, not a policy. When your client opens the tunnel it sends packets from a local address to the gateway's public address, and the gateway's kernel records the source of that flow. That source is the network endpoint your provider assigned to the connection at that moment.

Behind a home router the source is the router's public address after NAT. On a mobile network it may be a carrier-grade NAT address shared with many other subscribers at the same time, which is why two unrelated people can appear to come from the same place. On a corporate guest network it is that network's egress. In every case the gateway learns an address, a port and a timestamp, and the address belongs to a network operator rather than to a person.

What the gateway actually records

What gets written down afterwards is a separate question from what is technically visible. The gateway may log the connection, the authentication identity and the assigned tunnel address, or it may log almost nothing beyond session state. Retention, export to a SIEM and correlation with an account are deployment decisions, and none of them follows from the fact that the source was observable.

Treat visibility and retention as two axes. A service can see everything and keep nothing, or see little and forward all of it.

The practical consequence is that you cannot reason about your employer's records from the client you installed. Ask what the service is configured to collect and for how long, and expect the answer to be a policy document rather than a technical guarantee. It is also worth separating the VPN gateway from everything else on a managed device, because endpoint software has its own capabilities and its own records. A personal VPN changes a route; it does not change what software already running on the machine can observe.

What an IP database can and cannot say

An IP-geolocation database takes that address and returns fields: country, region, city, postal code, latitude and longitude, plus an accuracy radius where the vendor provides one. Those fields are estimates derived from registration data, network topology and measured latency, and they degrade differently at each level. A country answer can be solid while the city answer is a guess.

MaxMind's own accuracy guidance is explicit about the distinction that matters here: locating a VPN server is not locating its users, and the data cannot identify a household, an individual or a street address. Read the accuracy radius and the confidence fields where the product exposes them, and treat missing data as missing rather than as a default. A map pin is a rendering choice, not a measurement. Registration records and reverse DNS are yet another kind of evidence: whois 203.0.113.5 tells you which operator holds the allocation and dig +short -x 203.0.113.5 tells you what the operator named it, and neither is a statement about where a person was standing.

Records that are not interchangeable

This cuts both ways, which is why it is a poor basis for a categorical decision. An estimate that matches the approved region does not prove presence. A mismatch does not, on its own, prove deception.

A remote-work review that relies on one lookup is answering a different question than the one being asked. What it needs is context: which locations the arrangement permits, what the person reported, and whether other evidence agrees. That is a management process with technical inputs, not a technical verdict.

The other records an organisation may hold are not interchangeable with a source address. A time-zone setting is a device preference anyone can change; an account event records that a session happened, not where; a device location reading from endpoint software is a different sensor with different permissions and different error modes. Assuming every employer collects all of them is as wrong as assuming none are collected. The useful discipline is to name the record, its owner and its error mode before treating it as evidence of anything.

What follows for a work arrangement

For your own arrangements, the question to ask is what the organisation collects and which working locations it permits. Those are two answers from two different parts of the business.

A source-IP display cannot settle permission to work from a place, and changing a route is not a substitute for agreeing the arrangement. If the policy is unclear, the productive move is to ask rather than to optimise the network path. Technical workarounds tend to produce exactly the record that looks like concealment.

The defensible technical statement is narrow, and it is worth keeping narrow: the gateway observes the network origin of the incoming connection, a geolocation database may estimate a location for that origin, and any claim about a person's physical position needs evidence beyond either. The MaxMind accuracy guidance is the reference for what those estimates support. Everything past that point is a policy question wearing a technical costume.