Network Signals That Reveal
Remote-Worker Location

Every TCP or QUIC connection carries a source IP visible to the destination. Corporate SaaS platforms log that IP against every session, and identity providers convert it to a city, region, and country by lookup against a commercial IP-geolocation database.

Databases like MaxMind's GeoIP2 achieve country-level accuracy above 99% on residential IPs and roughly 80% at the city level [1]. That's precise enough that a Lisbon-Portugal reading versus a Tampa-Florida reading is essentially never ambiguous.

This is the signal every risk engine starts with. Microsoft's Impossible Travel detection in Entra ID compares the geolocation of each sign-in against recent history and flags the sign-in as risky when the elapsed time is insufficient for the physical distance [2].

DNS lookups can be shipped independently of the primary traffic tunnel. Browsers on default settings often send DNS to public resolvers directly (Firefox to Cloudflare's 1.1.1.1, Chrome to Google's 8.8.8.8) regardless of VPN state. When the OS sends DNS through the ISP's local resolver instead, the resolver's own IP has a country reading of its own.

Advanced detection engines log the resolver country separately from the source-IP country. If the source IP reads "Tampa, Florida" and the resolver reads "Lisbon, Portugal," the disagreement itself is the signal. Cloudflare's own documentation on DNS-based leak vectors and cross-resolver instrumentation describes this correlation as one of the most reliable tells for a mismatched network path [3].

WebRTC is a browser standard for real-time audio, video, and data. To negotiate peer connections, it uses a protocol called STUN that queries the operating system directly for the machine's real network interfaces and reports them back to a JavaScript environment. That JavaScript can read the results via the onicecandidate event without any special permission from the user.

The consequence is that a website loaded in a browser can read the machine's actual public IP even when the browser is otherwise routing HTTP through a VPN or proxy. Research summarised by Surfshark in 2025 estimates that roughly 23% of consumer VPN sessions leak the underlying real IP through this channel [4]. Independent academic work from 2017 formalized the mechanic and documented that most browsers, at default settings, leak both LAN and public IPs to any page that asks [5].

This is one of the biggest gotchas for consumer VPN users specifically. It's less relevant for router-level home-IP relays, because the "real" IP that WebRTC reports back is already the home IP, which is what the worker wanted the destination to see.

Datacenter IPs, hosting-provider IPs, and known commercial-VPN exit nodes are collected in commercial threat-intelligence feeds and consumed by the risk engines of every major SaaS product. Cloudflare, Akamai, and identity-provider platforms all consume feeds like Spur, IPQS, and MaxMind's Anonymous IP database. A session that egresses from an IP tagged as "anonymous VPN" or "hosting" gets a materially higher risk score than the same session from a residential IP [6].

This is why "I'll just use ExpressVPN" so often falls over. Even when the IP does read as "United States" per the geolocation database, the same IP is separately flagged as a commercial-VPN egress, and the SaaS product uses that flag to bump up the challenge level. Slack's login often escalates to email verification against known VPN exits. Banking apps and streaming services frequently refuse the connection outright.

Residential IPs assigned by consumer ISPs (Comcast, Spectrum, AT&T, Verizon) are, by their allocation classification, not on these lists.

HTTP requests carry an Accept-Language header derived from the OS language settings. Browsers report a timezone via the JavaScript Intl.DateTimeFormat().resolvedOptions().timeZone API. Slack, Google Calendar, and Microsoft Outlook all sync a per-user timezone field that updates from the OS clock. Each of these is a shorthand for where the machine "thinks" it is.

None of them is derived from the network. All of them are visible to any web application. When they disagree with the network-layer geolocation (source IP says Tampa, browser timezone says Europe/Lisbon), the correlation is trivial and the flag is loud.

For deeper coverage of this specific layer see how your work apps reveal your timezone.

Round-trip time between a client and a server is a physical measurement. It's constrained by the speed of light and by intermediate infrastructure. A client claiming to be in Tampa but consistently showing an 80-millisecond baseline round trip to a US-East datacenter (versus the ~20 milliseconds a real Tampa client would show) is inconsistent with its claimed location.

Latency-based location inference is well-studied academically. Recent surveys of geolocation techniques document RTT-based systems that resolve to the country level from a small number of measurement vantage points [7]. In practice, corporate risk engines rarely rely on latency alone. But when a session is already flagged by another signal, latency shows up as corroboration in the incident write-up.

For home-IP relays specifically, the tunnel adds one hop, so latency to any destination is the latency from the traveller's location to the home router plus the latency from home to the destination. A traveller in Lisbon relaying through a Tampa home will show Lisbon-to-Tampa latency added to Tampa-to-anywhere latency. That's a real observable, though few enterprise risk engines are tuned to it.