Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VPN location claims don't match real traffic exits

ipinfo.io

Post reply on HN
Print view View original

211–220 of 333 posts

Re: VPN location claims don't match real traffic exits

#211

Post by dontlaugh »

pzmarzly wrote: post #79
reimertz wrote: post #13

I know multiple people who worked / working at Mullvad and they take their business, security and privacy _very_ seriously. Not surprised to see them shine here.

Coincidentally, Mullvad, Windscribe and IVPN all worked when I was in China behind GFW, while more popular options did not. Seems like there are VPNs, and then there are VPNs.

It sort of worked for me, but it was very unreliable. I tried Proton and Astrill, both of which worked much better.

Mullvad is pretty good overall though.

Re: VPN location claims don't match real traffic exits

#212

Post by dontlaugh »

Semaphor wrote: post #210
varenc wrote: post #172

Earlier 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.

It is in the UK, but I don’t think it is on the continent.

Re: VPN location claims don't match real traffic exits

#213

Post by t0mas88 »

reimertz wrote: post #13

I know multiple people who worked / working at Mullvad and they take their business, security and privacy _very_ seriously. Not surprised to see them shine here.

When they wrote that 3 providers were honest about all locations I have to admit my first thought was "Mullvad, and who would the other two be?"

With their reputation and trackrecord they really can't do any shady tricks. Imagine if they weren't among the 3 honest providers? That would be HN frontpage news.

Re: VPN location claims don't match real traffic exits

#214

Post by YouAreWRONGtoo »

reincoder wrote: post #173
preinheimer wrote: post #134

I'm a co-founder at WonderProxy, we didn't make their list (we target people doing application testing, not consumer VPNs). We're in 100+ countries, and I'll stand by that claim. It's a huge pain in the neck. In our early years we had a lot of problems with suppliers claiming to be in Mexico or South America who were actually just in Texas. I almost flew to Peru with a rackmount server in my luggage after weeks of pr…

I work for IPinfo. I have raised a ticket internally, but I think we focused on consumer VPNs for this test. For our ProbeNet, we are attempting to reach 150 countries (by ISO 3166's definition). We are at around 530 cities. Server management is not an easy task. We do not ship hardware, but operate using dedicated servers, so this reduces one layer of complexity. To maintain the authenticity of our server locations,…

[dead]

Re: VPN location claims don't match real traffic exits

#215

Post by reincoder »

oncallthrow wrote: post #124
varenc wrote: post #54

Interesting to learn you can identify the real country/area of origin using probe latency. Though could this be simulated? Like what if the VPN IP just added 100ms-300ms of latency to all of its outgoing traffic? Ideally vary the latency based on the requesting IP's location. And also just ignore typical probe requests like ICMP (ping). And ideally all the IPs near the end of the traceroute would do all this too. To…

If you 300ms latency then yes, you defeat this detection mechanism.

We operate servers for the purpose of measuring the internet using a wide variety of methods. We have more than 1,200 of these servers distributed across 530 cities, running not only ping but traceroute and many other types of active measurements.

In addition to active measurement and research, there are many other sources of data we use. Also, we are actively investing in R&D to develop new sources. Adding just 300ms of latency at the end of an IP address would simply appear as noise to us. We have dozens of locations, hints cut through the noise.

We welcome people to try to break the system. Perhaps it is possible to dupe this system.

Re: VPN location claims don't match real traffic exits

#216

Post by LunaSea »

tallytarik wrote: post #113

Most of these providers are in fact open about the fact that these locations are “virtual”, so it’s misleading to say they don’t match where they claim to be. There is however an interesting question about how VPNs should be considered from a geolocation perspective. Should they record where the exit server is located, or the country claimed by the VPN (even if this is a “virtual” location)? In my view there is usefu…

If we can pay them in virtual dollars, no problem

Re: VPN location claims don't match real traffic exits

#217

Post by lxgr »

laz wrote: post #185
reincoder wrote: post #173

Earlier quoted context omitted.

I work for IPinfo. I have raised a ticket internally, but I think we focused on consumer VPNs for this test. For our ProbeNet, we are attempting to reach 150 countries (by ISO 3166's definition). We are at around 530 cities. Server management is not an easy task. We do not ship hardware, but operate using dedicated servers, so this reduces one layer of complexity. To maintain the authenticity of our server locations,…

Google, Apple, and Meta (maybe others?) have the data to build a complete GeoIP dataset. None of them will share because there are only downsides to doing so. When FB was rolling out ipv6 in 2012, well meaning engineers proposed releasing a v6 only GeoIP db (at the time, the public dbs were shit). Not surprisingly, it was shot down.

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.

Re: VPN location claims don't match real traffic exits

#218

Post by YouAreWRONGtoo »

ssl-3 wrote: post #165
vpShane wrote: post #130

Earlier quoted context omitted.

Enough to buy like 512MB of DDR5 RAM maybe

...then I'll just have to learn how to get stuff done with 512MB of RAM. (I'm sure that browsers like lynx still work just like they did in 2001, and that pine can still read mail. Shouldn't be a problem, right?)

links2 is still a work horse in 2025 for occasional debugging.

Re: VPN location claims don't match real traffic exits

#219

Post by lxgr »

left-struck wrote: post #144
ggrantrowberry wrote: post #127

Earlier quoted context omitted.

What is this AppleTV box running TS that you speak of? Sounds awesome.

Doesn’t have to be an apple box either. A raspberry pi is what I’m using. I’m in the exact same situation, living in one country temporarily but citizen of another, and I have an exit point in my home country at my parents place on a raspberry pi. Basically any computer will work.

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 firewalls etc.)

Re: VPN location claims don't match real traffic exits

#220

Post by reincoder »

londons_explore wrote: post #3
HotGarbage wrote: post #2

While exits matter to avoid countries with a nation-wide firewall, the geoip industry is a scourge. If an ISP wants to help their users avoid geoblocking via https://www.rfc-editor.org/rfc/rfc8805.html more power to them.

With CGNAT becoming more widespread, formats like this might need expansion to include location data for ports. Ie. Port 10,000-20,000 are consumers in New york, port numbers 20000-30000 are in Boston, etc.

That is really interesting. I wonder if we have any internal data on this. I will check.

We are trying to work with ISPs everywhere, so if port level geolocation of the IP address is common, we surely need to account for that. I will flag this to the data team. To get the ball rolling, I would love to talk to an ISP operator who operates like this. If you know someone please kindly introduce me to them.

Post reply on HN