Yeah happens to other “vpn” solutions like zero trust solutions like zscalar. Logs says the user in Buffalo, IP is in Toronto. Same for users on the southern border, us location and Mexican ip.
VPN location claims don't match real traffic exits
261–270 of 333 posts
Re: VPN location claims don't match real traffic exits
#262Earlier quoted context omitted.
Lots of people already have Apple TVs and the Tailscale integration is pretty good and can serve as an always online exit node. So no new hardware required. Could even remotely walk a non-techie through the process without too much effort. personally, I've just upgraded my family's wifi to Ubiquiti and can then use Tailscale Wireguard running on the gateway as a proxy! (with their permission)
Is it that common outside the us? I know of exactly one family here in Germany having Apple TV.
They’re not insanely common even in the US, since Roku and Android sticks are cheaper and I don’t live in a wealthy area, but they’re not hard to get or unheard of.
The distinction between AppleTV, the hardware, and Apple TV+, the streaming service, was lost on many. Now that they are “Apple TV 4K” hardware and “Apple TV” service, it’s even harder to convey the correct meaning.
Re: VPN location claims don't match real traffic exits
#263Earlier quoted context omitted.
crypto is a public ledger. If someone wanted to find you, that's pretty easy target.
Depending on crypto, and even on public ledger ones, there are ways to on-ramp cash to a new cold wallet.
For payments, a cold wallet affects only its security, never its transparency. When you pay from it, you expose an IP.
Re: VPN location claims don't match real traffic exits
#264Earlier quoted context omitted.
I work for IPinfo. We also run traceroutes. Actually, we run a ton of active measurements from our ProbeNet. The amount of location data we process is staggering. https://ipinfo.io/probenet Latency is only one dimension of the data we process. We are pinging IP addresses from 1,200+ servers from 530 cities, so if you add synthetic latency, chances are we can detect that. Then the latency-related location hints score…
Do you run traceroutes and pings in both directions? In the case of a ping you might think it shouldn't matter but I can imagine a world where a VPN provider configures a server in London to route traffic via Somalia only when a user establishes a connection to the "Somalia" address of the server. You could only test this if you did a traceroute/ping through the VPN. And I'm not saying this is what's happening but if…
We run traceroutes and latency measurements from many different locations, so we are looking at aggregate behavior rather than any single path. When you combine data from hundreds of ProbeNet PoPs over time, asymmetric routing mostly shows up as noise. When that happens, latency based hints lose weight and we lean more on other signals.
We have seen this in practice. For example, when we deployed servers in Gambia, even traffic between local networks often left the country and came back due to limited peering and little use of the national IXP. Stil, the overall routing patterns were still learnable once you look at enough paths.
For VPNs, we are measuring the location of the endpoint IP itself, not user traffic inside a tunnel. If routing only changes after a tunnel is established, that is a service level behavior, not the network location of the IP.
Anycast and tunneling are things we explicitly detect. They tend to create clear patterns like latency clustering or unstable paths, and when we see those and flag them as anycast IPs by defaulting to their geofeed location.
See the classic: https://ipinfo.io/1.1.1.1
Re: VPN location claims don't match real traffic exits
#265Earlier quoted context omitted.
Android TV works great as well. I have it running on an old Chromecast that cost less than $50 new. While I still prefer running a plain Wireguard VPN if possible (i.e. when there's a publicly reachable UDP port), the really big advantage of Tailscale over other solutions is that it has great NAT traversal, so it's possible to run a routing node behind all kinds of nasty topologies (CG-NAT, double NAT, restrictive fi…
I have run into the firewall problems before. Even seen them that block authentication but -if already connected to the tailnet before joining the WiFi in question - will continue to pass data. OpenVPN would not connect and couldn’t handle the IP address switch. At worst, I turn on phone hotspot, authenticate, then switch back to WiFi. A purely serendipitous discovery on my part, but a very welcome one.
Interesting, maybe they block the orchestration servers of Tailscale, but not the actual data plane (which is almost always P2P, i.e., it usually does not involve Tailscale servers/IPs at all)?
Re: VPN location claims don't match real traffic exits
#266Earlier quoted context omitted.
Google's GeoIP is creepy good. I noticed a while ago that for fixed or technically dynamic but rarely actually changing IPs, their IP geolocation eventually converges on the exact street address, presumably due to Google crowdsourcing geolocation from devices with GPS or Wi-Fi geolocation access, which is in turn crowdsourced from devices with both GPS and Wi-Fi.
Google's GeoIP is rubbish for me. Often it's hundreds of kilometres off, and varies a lot even for a fixed IP.
As always with big corporations, if the experience is OK for 90% of people but absolutely sucks for 10% of people, then that's totally fine!
Re: VPN location claims don't match real traffic exits
#267Earlier quoted context omitted.
Lots of people already have Apple TVs and the Tailscale integration is pretty good and can serve as an always online exit node. So no new hardware required. Could even remotely walk a non-techie through the process without too much effort. personally, I've just upgraded my family's wifi to Ubiquiti and can then use Tailscale Wireguard running on the gateway as a proxy! (with their permission)
Is it that common outside the us? I know of exactly one family here in Germany having Apple TV.
I've never seen one in Poland.
Re: VPN location claims don't match real traffic exits
#268Back in 2022 I published a doc on how the egress IPs work at Cloudflare: https://blog.cloudflare.com/cloudflare-servers-dont-own-ips-... In summary, the location at which an IP egresses Cloudflare network has nothing to do with the geo-ip mapping of that IP. In some cases the decision on where to egress is optimised for "location closest to the user", but this is also not always true. And then there is the Internet.…
So, there is a dashboard internally for that. When we do ProbeNet PoP assessment, we have a high-level overview of the frequent and favored connections. We have a ton of servers in Africa, and there is a strong routing bias towards France, Germany, and the UK instead of neighboring connections.
Everyone in our engineering and leadership is very close with various CDN companies. We do echo this idea to them. It is not IP geolocation; we actually have a ton of routing data they can use.
Re: VPN location claims don't match real traffic exits
#269Re: VPN location claims don't match real traffic exits
#270Earlier quoted context omitted.
We (IPinfo) attended the IETF 3-day workshop on IP geolocation. Our presentation was about geofeed that can be viewed here: https://youtu.be/l8PR7VCmA3Q?si=dG-00UqljTopBquF&t=372 . It was a great session and we received a lot of questions. We attend different NOG conferences regularly. ISPs are incentivized to help us by providing good data. Although we are agnostic about adversarial geofeeds, ISPs themselves need to…
> ISPs are incentivized to help us by providing good data. That's the entire problem in a nutshell. Good quality of service should not depend on every site I visit knowing my geographic location at the ZIP code or even street level (I've actually seen the latter occasionally). I can somewhat understand the need for country-wide geoip blocking due to per-country distribution rights for media and whatnot, but when my b…
That is an excellent point!
That is why we have the IP to country level data available for free. As you have recognized the fact that country level data is good for security, we are willing to take a massive hit on potential revenue to allow everyone to use our country level data for free, even for commercial purposes. We literally built separate dedicated infrastructure that provides unlimited queries for our IP to Country data. We want to ensure that everyone has access to reliable data.
For us, based on active measurements, what we do is distribute IP addresses to more densely populated areas. The issue is that we are good at zip code level accuracy, but it is impossible for us to get street addresses correct for residential internet connections. Even if we get geographic coordinates fairly close to you, it is largely coincidental. Our accuracy radius goes as low as 5 KM.
However, consider hotels, conference centers, airports, train stations, etc., where large numbers of people gather and where there are a few public WiFi hotspots that usually remain in the same location. We can identify the exact building from those WiFi hotspot IP addresses.
We have approximately 1,200 servers in operation. Simply by knowing which data centers house our servers, we can reliably identify neighboring hosting IP addresses to the exact data center.