Live data from Hacker News

VPN location claims don't match real traffic exits

ipinfo.io

311–320 of 333 posts

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

#311
post #118

Earlier quoted context omitted.

Something like that happened to me, my 10+ year account and everything I've ever written just vanishing one morning. Even posts to a subreddit I moderate were repeatedly removed after every approval. No idea why, (the "wrong" public Wi-fi?) but my appeal was granted and nothing was fixed . Now I can't contact anyone, and the appeals page falsely claims that my account is in good standing and refuses to operate. When…

> So at this point, I only lurk occasionally, because I'm not going to go through that social hell again I feel ya. Sad thing is, there really isn't anywhere else to go for niche interests, or really much any particular information. AI fallout has finally killed the struggling web and online community. I think, there isn't much left besides cutting losses, resetting your dopamine receptors and finding community in th…

Pretty sure this was one of the Deus Ex endings. :p

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

#312
post #281

Earlier quoted context omitted.

We are always happy to work with large technology enterprises and streaming platforms, not necessarily to sell, but to share insights, data, and practical advice. We observe the entire internet through active measurements, and we are open to co-publishing research when it benefits the broader ecosystem. Google/GCP is top of mind for me due to a recent engineering ticket. Some of our own infrastructure is hosted on GC…

Do Cloudflare's floating egress IPs probe in a way where you can easily geolocate them? https://blog.cloudflare.com/cloudflare-servers-dont-own-ips-...

If it is an anycast IP address, we have hints of all locations. However, because we have to produce a standard IP geolocation product, we can only select one address. So, we choose the address we find from a reliable geofeed and designate the IP address as "anycast" in the API response.

Internally, we have an anycast database. I believe we can also provide all the location hints we see for each anycast IP. It is generally niche data though.

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

#313
post #310

Earlier quoted context omitted.

> how you can spoof IPInfo's location probes... Interesting. I would love to know how this is possible. Like with Geofeed or something else?

I don't think it is fair to IPInfo to give the specifics publicly, because once you have the "ah ha" moment you realize it is an entire class of difficult to address problems with how they use their sensor network. That knowledge only helps the bad guys.

We are actively trying to improve our system and build it as figuratively 'antifragile'. We can not afford to get comfortable and we need to constantly find faults in it. If you know anything, you can contact our founder or me directly.

The problem is that everyone knows we are the most accurate data provider and our growth is exponential. To my knowledge, most cybersecurity teams use our data to some degree. We cannot risk having any secrets out there that could disrupt the accuracy of the system. We are aware of several cases where accuracy may be affected, with the most notable being adversarial geofeed submissions.

If the issue is an adversarial geofeed submission, it is a well-known problem. When active measurement fails, we have to fallback to some location hint. There are layers of location hints we have to fall through to ultimately landing on echoing geofeed location hint.

But aside from that... I'm not sure what could possibly impact us. A substantial systemic malicious change in data accuracy seems highly unlikely and quite impossible.

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

#314
post #310

Earlier quoted context omitted.

> how you can spoof IPInfo's location probes... Interesting. I would love to know how this is possible. Like with Geofeed or something else?

I don't think it is fair to IPInfo to give the specifics publicly, because once you have the "ah ha" moment you realize it is an entire class of difficult to address problems with how they use their sensor network. That knowledge only helps the bad guys.

Why do we assume that only "bad guys" would want to bypass internet censorship?

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

#315

Earlier quoted context omitted.

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!

I can tell you how we approach enterprise partnerships: absolute accountability. If something is wrong with the data, it is not our customers' fault for trusting us, it is our fault. End users talk to us directly. And because the data is so good these days, we just have to present evidence, that's it. We with multi-billion-dollar corporations, and for every product integration we maintain an active, visible presence…

90% of end users, not 90% of your customers. If your product blocks 10% of end users because it provides wrong geolocation data to your customer, sucks to be them!

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

#316

Earlier quoted context omitted.

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.

I'm a bit curious about how that works. I love Mullvad but routinely I find sites like Reddit completely block it. Even yesterday someone posted a Debian wiki link[0] and I was blocked. It's not all of them but Reddit is a big killer. So I thought China would block all of them (aren't they known?) Fwiw I'm not switching from mullvad [0] https://news.ycombinator.com/item?id=46252366

Reddit blocks basically everything - since the 2023 API meltdown it's gone full 1984 censorship and opinion manipulation mode. There are two target audiences for Reddit: propagandists (who are given moderator status, even in subreddits they didn't create) and targets of propaganda (only if Reddit can verify their physical location). You're not in the first group and you don't want to be in the second.

The Tor service does not work. It's been unmaintained for years.

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

#317

Earlier quoted context omitted.

crypto is a public ledger. If someone wanted to find you, that's pretty easy target.

I went in on Monero (which Mullvad accepts for now...)the only early crypto that had a viable usage plan from the beginning. That was of course before I realized that crypto would of course just be turned into a massive scam wheelhouse and any coin with real utility value to challenge fiat currency would of course be regulated against. (not salt its still worth a lot) I am aware most crypto is not anon without extra…

AFAIK transacting with Monero in the EU is now illegal, and the law is pretty explicit that this is because it's untraceable.

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

#318

Earlier quoted context omitted.

> how you can spoof IPInfo's location probes... Interesting. I would love to know how this is possible. Like with Geofeed or something else?

If you're doing latency-based probing, location spoofing is presumably possible to an extent by adding artificial delays and possibly spoofing ICMP "TTL expired" packets like https://github.com/blechschmidt/fakeroute

I am not sure whether this kind of IP spoofing will impact our accuracy because we will likely identify the noise and behavioral anomaly and discard the location hint derived from traceroute.

We have tons of historical traceroute data patterns, and generic traceroute behaviors are likely modeled out internally. So, if you can spoof the traceroute to your IP address, our traceroute-based location hint scoring weight for that IP address will decrease, and we will rely on the other location hints.

You have to be extremely deliberate to misguide us. But I would love to see this in action, though.

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

#319

Earlier quoted context omitted.

I can tell you how we approach enterprise partnerships: absolute accountability. If something is wrong with the data, it is not our customers' fault for trusting us, it is our fault. End users talk to us directly. And because the data is so good these days, we just have to present evidence, that's it. We with multi-billion-dollar corporations, and for every product integration we maintain an active, visible presence…

90% of end users, not 90% of your customers. If your product blocks 10% of end users because it provides wrong geolocation data to your customer, sucks to be them!

That is a great point! For us, it is 100% of end users not limited to our customers. If you are impacted by our data in any way, it is on us. We are accountable for that.

https://community.ipinfo.io/t/wrong-geolocation-based-on-ip-...

Our free database is licensed under "CC-BA-SA" (freely distributable but requires attribution) because of accountability. If you use our data as an enterprise or a free open-source project, if there is any issue, you can come to us and talk with us.

It is not even end-users. We maintain open communication policies in general. Even if a streaming service does not use our data, if they come to us, we try our best to help them based on our industry knowledge.

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

#320
post #265

Earlier quoted context omitted.

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)?

I'm sure they do, but the question is, why did OpenVPN fail? It's pure P2P. I've got a dynamic DNS through afraid.org, and that resolves on that network, so it's not just DNS-level blocking. I effectively have a static IP anyway; there's no CGNAT going on, so I've discovered that I misconfigured my DDNS once or twice only when afraid.org emailed to tell me that I hadn't updated in X months.

Were you using the semi-well-known port (1194)? Otherwise, maybe it's just more fingerprint-able, or whatever DPI the firewall uses hasn't caught up to Wireguard yet?
Post reply on HN