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.
Some of our (IPinfo) services are hosted on GCP, and because our service is widely used (with 2 trillion requests processed in 2024) people sometimes say they cannot access our service. It is usually due to how Google's device-based IP geolocation is used. The user's IP address is often mistakenly identified as being located in a country where Google does not offer service.
I have seen a Europe-based cloud hosting provider's IP ranges located in countries where Google does not provide service. This is because these IP ranges are used as exit nodes by VPN users in that country.
Device-based IP geolocation is strange. We prefer IP geolocation based on the last node's IP geolocation. We hope to collaborate with Google, Azure, and other big tech on this if they reach out to us.
The device-based IP geolocation, because the algo is so sensitive and the result can be altered with few devices behind the IP (at least for Google), can be used theoretically steering / trick big techs to believe that the IP is at location it is not, just like VPN providers in your article by publishing "bogon" geofeed etc. This defies their purpose of doing this in the first place: geolocking and regulatory requirements.
The "tech" is already there: browser extensions [1] that overwrite the JS GeoLocation API to show "fake" locations to the website (designed for privacy purpose). also dongles are available on gray market that can be attached to iPhone / Android devices to alter the geolocation API result by pretending it is some kind of higher precision GPS device but instead providing bogon data to the OS. Let alone after jailbreaking / rooting your device, you can provide whatever geolocation to the apps.
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.
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.
We (I work for IPinfo) talk about latency because it is a thread that you can start from when exploring our full depth of data.
We are the internet data company and our ProbeNet only represents a fraction of our investment. Through our ProbeNet, we run ping, traceoute, and other active measurements. Even with traceroute we understand global network topology. There are dozens and dozens of hints of data.
We are tapping into every aspect on the internet data possible. We are modeling every piece of data that is out there, and through research, we are coming up with new sources of data. IP geolocation is only product for us. Our business is mapping internet network topology.
We are hoping to work with national telecoms, ISPs, IXPs, and RIRs to partner with them, guiding and advising them about data-driven internet infrastructure mapping.
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 will go down, and we will prioritize our dozens of other location hints we have.
But we do welcome to see if anyone can fool us in that way. We would love to investigate that!
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 you just ping the IP from your infra, couldn't stuff like anycast potentially mess you up?
In the case of traceroutes, you only see the route your traffic takes to the VPN, you don't see the route it takes to get back to you, which I think is really important.
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.
If the VPN IP and the last ~4 hops in the traceroute just ignored ICMP pings, or just all
inbound traffic, it sounds like that'd make your detection harder?
I've found that this isn't even that uncommon. One of the example VPN IP's on the article had the last 3 hops in traceroute ignoring ICMP. (though TCP traceroute worked). The VPN IP itself didn't, but it easily could!
(feel free to ignore lest we not give bad actors ideas)
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 work with us to ensure good quality of service to their users.
We already do quite a lot of outreach, in fact, most network engineers in the ISP industry across the world are familiar with us. But if any ISP operator has any feedback for us, we are only an email (or even a social media comment) away.
> 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 bank does it, it just screams security theater to me.
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.
> As you have recognized the fact that country level data is good for security [...]
That's the opposite of what I said. I think blocking entire countries is largely security theater. Bad actors will just use botnets or other residential proxies wherever needed, while legitimate users traveling abroad get locked out.
I can see it make sense for login-free distribution of media with limited regional rights (e.g., some public broadcasters offer their streams for free but are only allowed to do so domestically), or to provide a best guess for region-specific services (weather forecasts, shipping rate estimates etc.), although I'd also love to see that handled via the user agent instead, e.g. via granting coarse location access, to prevent false positives.
I also wouldn't mind it as much as one of many input signals into some risk calculation, e.g. for throttling password (but not passkey) attempts, to be overridden by login status, but outright bans are incredibly annoying, and unfortunately that's what I see many companies doing with GeoIP data.
Almost as annoying: Companies insisting on serving me a different language just because I traveled abroad, even though my "Accept-Language" header is right there.
That was actually a great article. For us, that is like a crowdsourced bug hunting program. We actually got duped ourselves, and we appreciate the author.
We added additional features for location hint modeling and selection for IPv6 networks. There are a handful of open engineering tickets to understand more about the entire internet infrastructure of the country. Of course, hosting a probe server out there would be helpful.
I work for IPinfo. We provide IP geolocation and VPN detection services. We identify which IP addresses are associated with a VPN and the actual location of the IP address.
We have not collaborated with any VPN companies for the report and have not even requested permission or pre-draft approvals. We had the data of what we were seeing and published a report based on that. We have published a ton of resources around the nature of VPN location in the past. Our focus is on data accuracy and transparency.
After the article was published, we received feedback from only a single VPN provider - Windscribe (https://x.com/ipinfo/status/1998440767170212025). I do not think anyone from Mullvad, iVPN, or any other VPN company has reached out to our team or our founder yet.
We are happy to take feedback and comments and are even open to a follow-up!
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.
reply