I work for IPinfo. We track close to a hundred resproxy providers. So, if OP's router is compromised, the device IPs will likely be flagged.
From what I know, whenever a router is backdoored or a resproxy SDK gains access to a device to use their bandwidth, the access to that pool of devices is often shared among multiple resproxy vendors. Many resproxy vendors do not have their own SDKs for their services.
Also, as far as I know, not many resproxy operators manage their sim farms or hardware pools. It is mostly based on compromised devices or SDK access.
This is called a geofeed. Companies that own or operate IP addresses can customarily share the location of those IP addresses. This is less of "IP-based Geolocation" rather "Geolocation of IP addresses.
I work for IPinfo. We are launching a collaborative project with IXPs and major internet organizations to share raw measurement for routing and peering data for this purpose.
Latency variability is a huge issue. We run both traceroute and ping data, and we observe that there are entire countries that peer with IXP thousands of miles away in a different continent.
We bought a server from the oldest telecom company in the country and recently activated it. Currently, there is a 20 ms latency when traffic is directed towards the second oldest telecom. The packets have to travel outside the country before coming back in. This is a common phenomenon that occurs frequently. So, we usually have multiple servers in major cities since various ASNs have different peering policies.
For us we can map those behaviors and have algorithms and other data sources, make measurement-based geolocation perform well.
We are hoping to support IXPs, internet governance agencies, and major telcoms in identifying these issues and resolving them.
What is your path towards 'resolving' these issues?
I've done some mapping while comparing turn servers my org hosted on cloud vms vs a commercial offering, and it's pretty easy to find very different routing from point A to point B, but sometimes it's pretty clearly that not every transit network has access to every submarine cable, so traffic from say Brazil to South Africa might go from Brazil directly to Africa, or it might go to Florida, then Europe, then Africa. It'd be nice to take a more direct route, but maybe the Brazil -> Africa hop doesn't transit all the way, so BGP prefers the scenic route as it has a shorter AS path.
I didn't have any leverage to motivate routing changes though, so other than saying hmm, that's interesting, there wasn't much to do about it.
From our data side, we focus on network diversity and conduct continuous measurements. Due to the nature of our measurements and our knowledge of the precise locations of all 1330 servers, we understand how network packets travel across the internet. We simplify this information into algorithms and know how to accommodate detours that packets may take. There are specific patterns that we can identify and map, like some African servers route their traffic through LINX or a French IXP. If you are not connecting to private networks or even major telecoms on EU-based IXPs.
To help the system, we are reaching out to IXPs, major telecoms and peering agencies to advise them on how to peer and make critical internet routing decisions. We want to tell them on how to engage in data-focused peering, how their IXP is perceived from a broader internet data perspective, and how their packets from the IXP travel across the internet. We hope this colloboration will bring much needed efficiency in internet routing.
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)
From what I know, whenever a router is backdoored or a resproxy SDK gains access to a device to use their bandwidth, the access to that pool of devices is often shared among multiple resproxy vendors. Many resproxy vendors do not have their own SDKs for their services.
Also, as far as I know, not many resproxy operators manage their sim farms or hardware pools. It is mostly based on compromised devices or SDK access.
reply