Live data from Hacker News

VPN location claims don't match real traffic exits

ipinfo.io

131–140 of 333 posts

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

#131

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

How do other providers avoid this issue? Do they keep changing IPs or is the traffic that comes out of Mullvad worse in quality somehow?

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

#132
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…

Does this really work? I would think the ping time would not be dominated by speed of light, but by number of hops, and connection quality.

As a hypothetical example, an IP in a New York City data center is likely to have a shorted ping to a London data center, than a rural New York IP address.

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

#133
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…

Does this really work? I would think the ping time would not be dominated by speed of light, but by number of hops, and connection quality. As a hypothetical example, an IP in a New York City data center is likely to have a shorted ping to a London data center, than a rural New York IP address.

The speed of light sets a minimum bound even if you don't account for that, and these are coming up less than the minimum bound.

It also reminds me of this old story: https://web.mit.edu/jemorris/humor/500-miles

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

#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 problems, that plan died when we realized I'd need to figure out how to pay Peruvian income tax on the money I made in country before I could leave.

We've also had customers complaining that a given competitor had a country we'd had trouble sourcing in the Middle East. A little digging on our part and it's less than a ms away from our server in Germany.

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

#135

Earlier quoted context omitted.

At risk of sounding sale pitch'y. Mullvad is the only VPN the longer I use the more I like it. I've tried MANY competitors first and all the other ones so far seem to only get worse over time. I love that I can pay directly with a crypto wallet and have true anonymity.

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

Not all digital currencies work that way.

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

#136

Earlier quoted context omitted.

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

How do other providers avoid this issue? Do they keep changing IPs or is the traffic that comes out of Mullvad worse in quality somehow?

They purchase residential traffic exit from botnets.

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

#137

Earlier quoted context omitted.

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

How do other providers avoid this issue? Do they keep changing IPs or is the traffic that comes out of Mullvad worse in quality somehow?

I'd also like to know.

I'd also like to ask people not to block this way. It creates LOTS of false positives. There's much better ways to handle bots and this tactic seems particularly dumb for Reddit given they want users from places like China or elsewhere where a VPN might be required. Not to mention people using public WiFi. It's not like VPNs are uncommon these days.

If you must ban IPa then do so with a timeout and easing function. So that each hit results in a longer ban time. Bots want to move fast so even a few seconds ban time will make them switch IPs while not impacting most users (who will refresh)

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

#138
Oh wow, I had no idea that “virtual location” is even a thing. Imo it should not, I don’t even see a use case for that, it just seems like straight-up lying about the traffic exit location. Glad to see the provider I occasionally use, Mullvad, passed the test.

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

#139
post #51
post #31

Contrasting take: RTT and a service providing black box knowledge is not equivalent to knowledge of the backbone. To assume traffic is always efficiently routed seems dubious when considering a global scale. The supporting infrastructure of telecom is likely shaped by volume/size of traffic and not shortest paths. I'll confess my evaluation here might be overlooking some details. I'm curious on others' thoughts on th…

They don't have to assume that traffic is efficiently routed, on the contrary if they can have a It just can't be outside England, just one 0.4ms RTT as seen here is enough to be certain that the server is less then 120 km away from London (or wherever their probe was, they don't actually say, just the UK). RTT from a known vantage point gives an absolute maximum distance, and if that maximum distance is too short th…

We've got detailed global ping data here: https://wondernetwork.com/pings

One of our competitors was claiming a server in a middle eastern country we could not find any hosting in. So I figured out what that server's hostname was to do a little digging. It was >1ms away from my server in Germany.

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

#140
I seriously don't quite understand the point of using a VPN that doesn't offer you clean residential IPs somehow (and I don't really know good VPN like that). Most services where I really want to use VPN are well aware of VPN IP blocks and just won't allow any of these famous VPNs (that I am aware of, at least). And services that don't care if it's my real IP or not… well, usually I don't really care about exposing them to my real IP either?

I mean, ok, there are use-cases. But commercial VPNs exist under specific premise, you know, and they just don't offer what they claim to be offering. Unfortunately.

Post reply on HN