I spent quite a few years working in the isp/cdn/dns space. Is “virtual location” an idiomatic term for VPN users? The more general industry would probably say youre looking at Points of Presence (“PoPs”).
The core of the article is one of (mis)representation. The VPN providers are trying to present broad network coverage with a minimum of expenditure, and the clients are concerned with actual geophysical location. Virtual Locations seems to be a term designed to comingle the concepts, and obfuscate actual location and connectivity.
The clustering is because there simply arent that many physical locations with connectivity to various networks (Internet Exchange Points “IXPs”). Those IXPs are themselves often clustered and associated with a few nearby physical facilities (DCs or Colo(cation) for hosting general compute servers.
You mention companies “leasing” address blocks. Thats probably more correct to say theyre “delegated” from NSPs to clients like the vpn companies.
In general Id find whois/rir data to be of very little use. Theres little to no association or restriction for either of those and where the IP addresses are actually announced or used.
It may not matter for your use/methodology but latency for ICMP is unreliable. Many networks will use a lower traffic priority for it, introducing variable loss/jitter/delay. If at all possible actual TCP or UDP is better for evaluating RTT.
One thing you might look at is the vpn provider network adjacencies in different locations. Many/most NSPs handily include some sort of location identifier (like iata code) in their device names. From those adjacent devices you can probably infer city at least. PeeringDB and/or looking glass portals are another way to deduce network topology and connectivity, possibly narrowing it down to specific facilities.
Lastly your ICMP replies are inherently limited in what you see. Its very likely that there are underlying networks (ie MPLS, or GRE tunnels) that you cant see. Itd be very easy to have an interconnect in AMSIX and tunnel it over to belgium or germany. You wouldnt see that in DNS or ICMP replies, but could infer it through latency.
> Is “virtual location” an idiomatic term for VPN users?
It seems so. I just used it because other have. But yes, technically they're PoPs.
Thanks for the clarification about clustering, and saying "delegated" vs "leased". Still, VPNs pay for address delegation, I would guess.
That's a good point about ICMP being unreliable. I'll need to check whether any of the ping services allow TCP or UDP. But yes, ICMP being slow just reduces the chance of finding superluminal signal velocity.
> Many/most NSPs handily include some sort of location identifier (like iata code) in their device names.
I'm not sure what that means. Where would I get that information?
> PeeringDB and/or looking glass portals are another way to deduce network topology and connectivity, possibly narrowing it down to specific facilities.
I'm not familiar with that, either. Although I at least sort of know what looking glass portals are. So hey, something to learn, clearly.
I did find quite a few minrtts under 1 msec. Suggesting that the VPN server and ping probe are very close. Perhaps hosted in the same facility. But I didn't know where to look for relevant information.
> Lastly your ICMP replies are inherently limited in what you see. Its very likely that there are underlying networks (ie MPLS, or GRE tunnels) that you cant see. Itd be very easy to have an interconnect in AMSIX and tunnel it over to belgium or germany. You wouldnt see that in DNS or ICMP replies, but could infer it through latency.
I'm not sure what this means. Wouldn't adding a tunnel just increase latency? Or rather, is there any way that using "underlying networks (ie MPLS, or GRE tunnels)" could obscure the use of PoPs?
Depends on how you look at it. I havent been in the NSP industry for a decade but usually customers would get a /24 or /22 of the NSPs allocation for free as part of the actual network service cost. Once you're bigger than that the customer (eg VPN provider) should be getting allocations/assignments directly. https://www.arin.net/resources/registry/reassignments/#alloc...
> I'll need to check whether any of the ping services allow TCP or UDP. But yes, ICMP being slow just reduces the chance of finding superluminal signal velocity.
For your methodology its probably fine. But you can see intersting artifacts in advanced networks. Like ICMP might be terminated (replied to) early at teh network edge, where actual TCP session setup happens deeper inside, and then layer 7 (http) is tunneled even further. So ping (icmp), traceroute (udp), and wireshark (tcp/http) would show different latencies by a few ms.
>> Many/most NSPs handily include some sort of location identifier (like iata code) in their device names.
> I'm not sure what that means. Where would I get that information?
The ICMP ttl exceeded replies from traceroute (hopefully) include those device or port addresses. And a quick DNS lookup will give you the PTR/A record. From here in australia to eu1.vyprvpn.com I pass through:
> 4 be10-3999.core1.vdc01.syd.aussiebb.net (180.150.2.88) 7.169 ms 5.369 ms 6.191 ms
> 5 be1.bdr1.coresite-sv1.sjc.aussiebb.net (180.150.2.107) 164.582 ms 161.045 ms 153.770 ms
This is a single layer 3 link from Sydney Australia (SYD) to CoreSite SV1 in San Jose (SJC) California.
> 6 ce-0-17-0-0.r01.snjsca04.us.bb.gin.ntt.net (128.242.179.33) 153.749 ms 153.840 ms 157.461 ms
Where its handed off to an NTT backbone device; probably site #4 in San Jose CA (snjsca04), router #1 (r01), interface ce-0-17-0-0.
> 7 sjo-b21-link.telia.net (62.115.12.52) 157.553 ms 164.782 ms 166.938 ms
> 8 nyk-bb2-link.telia.net (62.115.119.228) 892.775 ms *
> 9 ldn-bb3-link.telia.net (62.115.113.21) 528.821 ms 427.296 ms 405.795 ms
> 10 adm-bb3-link.telia.net (62.115.113.210) 311.039 ms
And I don't know telia naming offhand, but this looks like San Jose border router #21 (sjo-b21), across their backbone of New York (and/or Newark?) router 2 (nyk-bb2), London and Amsterdam.
> 11 adm-b2-link.telia.net (62.115.141.39) 308.913 ms
> 12 ic-311014-adm-b2.c.telia.net (80.239.128.234) 307.252 ms 410.241 ms 409.498 ms
And here we see a single Amsterdam border device or site (adm-b2) with what looks like two different interfaces. Im guessing #12 has a circuit identifier or similar, with the acutal end customer on the other side there.
> I did find quite a few minrtts under 1 msec. Suggesting that the VPN server and ping probe are very close. Perhaps hosted in the same facility. But I didn't know where to look for relevant information.
Yes. As a rule of thumb <1ms is same building or location, ~2-3ms is same metro area or a very large network topology in between the two. For more information I'd probably look a the device path (traceroute) or the BGP announcements to see what addresses are announced, and by which networks. You can infer network topology from the AS Path in the BGP announcements. All of that should be available from looking glasses or groups like caida & cymru.
> I'm not sure what this means. Wouldn't adding a tunnel just increase latency? Or rather, is there any way that using "underlying networks (ie MPLS, or GRE tunnels)" could obscure the use of PoPs?
The tunnel itself wouldnt necessarily add meaningful latency or interfere with your methodology. But it would obscure the topology that you'd see at the IP/ICMP (trceroute or BGP) level. So maybe the router is in AMS-IX, but that router could tunnel the packets to another device in Germany. Traceroute or DNS might not show that, but you'd see a latency anomaly there. Related to my geo-political comment if a user cares about law enforcement the physical location of the end device could very much matter.
Thanks again. Lots of good resources and explanations there.
>> VPNs pay for address delegation, I would guess.
> Depends on how you look at it. I havent been in the NSP industry for a decade but usually customers would get a /24 or /22 of the NSPs allocation for free as part of the actual network service cost. Once you're bigger than that the customer (eg VPN provider) should be getting allocations/assignments directly. https://www.arin.net/resources/registry/reassignments/#alloc...
OK, but I was thinking of HideMyAss, for example. Its cluster near Nuland, NL has 109 IPv4 addresses. RIPE tells me that they're all over the world. But latency tells me that they're all near Nuland.
So where did HideMyAss get all those IPv4 addresses? I'm guessing that some firm has obtained delegated IPv4 blocks from NSPs in all those places, and then allocated addresses to HideMyAss. And it has apparently become a huge business sector, especially with IPv4 exhaustion. But also for providing VPN services, spammers, etc with deceptive PoPs.
I looked into that using https://bgp.he.net/ but all that's on another VM that I lack the RAM to run right now. It might even be HideMyAss' NSP for that facility.
> The tunnel itself wouldnt necessarily add meaningful latency or interfere with your methodology. But it would obscure the topology that you'd see at the IP/ICMP (trceroute or BGP) level. So maybe the router is in AMS-IX, but that router could tunnel the packets to another device in Germany. Traceroute or DNS might not show that, but you'd see a latency anomaly there. Related to my geo-political comment if a user cares about law enforcement the physical location of the end device could very much matter.
Right. Latency for a direct tunnel might well be lower than that for Internet transport. And as you say, the tunnel can't hide from latency testing. It's just that traceroute just sees a discontinuity.
> the clients are concerned with actual geophysical location.
Are they, though? This is, of course, completely anecdotal, but the only real reason I will change the 'location' of my VPN endpoint is exactly that. My suspicion is that most of the VPN users concerns about geography match mine and actually boil down to whether or not it will trick a geofence.
There's going to be some ways in which you can conflate those concepts, since obviously 'virtual locations' will be detectable by some means, as evidenced by the fact that mirmir managed it, but I suspect for a lot of consumers good enough is good enough.
I probably should have said “geo-political.” Youve noted the contractual aspect, which bubbles up in regional content restrictions.
I was thinking more along the lines of law enforcement as well. Where civil & criminal law, data retention, LEO access, and due process may vary significantly in different countries.
Huh. I wonder how law enforcement deals with this.
Naively, I'd expect that it's where the VPN service is incorporated that determines that stuff. But on the other hand, they would need to find a server to impound it. So I suppose that PoPs could be used strategically to impede investigations.
I'll prefix this by saying its probably pretty far out on the spectrum of practicality. More paranoia or legal problems than wanting access to region restricted entertainment content.
I dont have adversarial experience with law enforcement, but from what Ive seen it's normally around incorporation, assets, and where the principals are. The government gets access by serving you papers, restricting your assets, or restricting your freedoms.
That side the physical location of the servers will matter for teh same reasons. Two adjacent countries may have different standards of evidence, due process, compelled information, data retention, 'know your customer', etc. Both the country of physical location and the country of incorporation will effectively have access; one directly and one via compulsion.
Usually its a precomputed list at run time. Think of a tree that goes from network address to locale(s). More specific network prefixes (probably) have more specific locales.
Companies like MaxMind collect and repackage this based off of information like RIRs, SWIP, DNS PTRs, or even end user billing/shipping addresses in online transactions. I dont think latency is used too much these days. Check out https://www.maxmind.com/en/geoip2-databases for some examples. I'd say that level of detail is about industry standard and most companies would simply pay maxmind or another vendor for this data.
The core of the article is one of (mis)representation. The VPN providers are trying to present broad network coverage with a minimum of expenditure, and the clients are concerned with actual geophysical location. Virtual Locations seems to be a term designed to comingle the concepts, and obfuscate actual location and connectivity.
The clustering is because there simply arent that many physical locations with connectivity to various networks (Internet Exchange Points “IXPs”). Those IXPs are themselves often clustered and associated with a few nearby physical facilities (DCs or Colo(cation) for hosting general compute servers.
You mention companies “leasing” address blocks. Thats probably more correct to say theyre “delegated” from NSPs to clients like the vpn companies.
In general Id find whois/rir data to be of very little use. Theres little to no association or restriction for either of those and where the IP addresses are actually announced or used.
It may not matter for your use/methodology but latency for ICMP is unreliable. Many networks will use a lower traffic priority for it, introducing variable loss/jitter/delay. If at all possible actual TCP or UDP is better for evaluating RTT.
One thing you might look at is the vpn provider network adjacencies in different locations. Many/most NSPs handily include some sort of location identifier (like iata code) in their device names. From those adjacent devices you can probably infer city at least. PeeringDB and/or looking glass portals are another way to deduce network topology and connectivity, possibly narrowing it down to specific facilities.
Lastly your ICMP replies are inherently limited in what you see. Its very likely that there are underlying networks (ie MPLS, or GRE tunnels) that you cant see. Itd be very easy to have an interconnect in AMSIX and tunnel it over to belgium or germany. You wouldnt see that in DNS or ICMP replies, but could infer it through latency.