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

81–90 of 333 posts

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

#81

Post by AnthonyMouse »

dustywusty wrote: post #7
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.

Can really spot someone who has never had to deal with OFAC with a comment like this. Even if I don't necessarily agree with the concept, or who is actually being blocked, my business is dead in the water if I'm a) sent to prison or b) fined out of existence. Geographic IP information is one of our best tools to defend against those outcomes, and if anything it should be better.

> Even if I don't necessarily agree with the concept, or who is actually being blocked, my business is dead in the water if I'm a) sent to prison or b) fined out of existence.

Is there some specific way we can get the laws like this to be gone? They're obviously useless (witness this very thread of people describing ways for anyone to get around them) and threatening people with destruction for not doing something asinine isn't the sort of thing any decent government should be doing.

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

#82

Post by citizenpaul »

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.

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.

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

#83

Post by debian3 »

yieldcrv wrote: post #14
why-o-why wrote: post #11

I tried to use ProtonVPN when I switched over to ProtonMail a year ago. But so much of the web does not work when you're on a VPN. For example even HackerNews has VPN restrictions. More and more sites know where VPN endpoints originate. How will VPNs prevent this in the future without them just become easy to block?

I wonder if using the wifi at a data center has the same broken browsing experience as using a VPN

Yes and No. The internet sees it as a datacenter ip and some will degrade the experience based on that. Other are more strict and use a service like ipinfo.io (the op) to know exactly which Ip are used by a VPN provider and block access based on that list.

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

#84

Post by justinsaccount »

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…

Not that simple.

If they added latency to all packets then London would still have the lowest latency.

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

#85

Post by kortilla »

sgjohnson wrote: post #47
kalaksi wrote: post #18

Earlier quoted context omitted.

Sounds awful, though. Maybe we should get more widespread usage for IPv6 instead.

Yes. I’ll never forgive IETF for standardizing CGNAT back in 2013. They should have just said “no, deploy IPv6 with a transition technology”. If that had happened, IPv4 would likely already could be regarded as a relic of the past.

The ietf standardization was irrelevant so I would give them some slack. ISPs were using CGNAT already in a widespread fashion. The ietf just said, “if we’re gonna do this shit, at least stay out of the blocks used by private networks”.

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

#86

Post by DANmode »

deegles wrote: post #74
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…

with enough packets you can trilaterate an approximate locatuon. adding random jitter will just delay it a bit.

More than a bit!

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

#87

Post by spiffytech »

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.

I knew they were going to pass the test before I even clicked the article link.

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

#88

Post by kortilla »

HotGarbage wrote: post #19
dustywusty wrote: post #7

Earlier quoted context omitted.

Can really spot someone who has never had to deal with OFAC with a comment like this. Even if I don't necessarily agree with the concept, or who is actually being blocked, my business is dead in the water if I'm a) sent to prison or b) fined out of existence. Geographic IP information is one of our best tools to defend against those outcomes, and if anything it should be better.

If you were serious about limiting who uses your services you'd use an allowlist of ASNs. Even then, what about users using US-based residential proxies?

ASNs aren’t going to cut it. Google “residential proxies”

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

#89

Post by varenc »

debian3 wrote: post #78
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 ping it from UK and it ping >10ms then you know its there. And you are triangulating from multiple countries.

You could vary the additional latency based on the location of the IP you're replying to? Or just hash the requesting IP and use that as a seed to generate that particular IP's random extra latency that always stays the same for that IP. Which feels like enough to make triangulation hard. Though I'm just spitballing.
Post reply on HN