[deanhills]

Thank you for your detailed and in-depth research and feedback @"Hidden Refuge".  This is much appreciated.

I'm not sure why the IPs are geolocated to Las Vegas, NV though. They don't offer any service out of this location according to their own site (although a bit of Google research shows they did seem to have a Nevada location in Henderson, NV). If that location no longer exists then maybe the just use their old NV IP address block on different locations as they can route it to any DC/ASN at their RIR. One possible explanation. That of course means they didn't update the geolocation of the IP address(es).

This puzzled me too.  Seeing that my location is supposed to be Phoenix, Arizona.  Your point about they didn't update the geolocation of the IP makes sense to me, given the speed and pressure on them to do the upgrades, and possibly "grab" IPs theirs was a bulk mass production style of grabbing IPs.  

I've got a question here.  Against the backdrop of the whole of the first paragraph of your feedback.  Do you think there is practical sense in asking Virmach if they could change the location of the VPS to Germany?  Would there be an additional cost/complication/effort involved on their side to change this into a German location?

And another thing about the issue that you described "I used a VPN as well with Canada location, and whatismyipaddress then showed two locations for my IP - Frankfurt in Germany and Las Vegas, Nevada.". Sites use IP addresss geolocation databases. Those databases aren't always up to date or correct. So sites and services may use several of them. One might have the correct location and the might not. So depending on which databases handled the geolocation identification... the result can be wrong.

 Now this makes sense to me.  I didn't realize databases were individual.  I had this picture of one database shared by all.

Based on that I can most likely say or rather give a hint that probably speedtest.net has inaccurate IP geolocation information of the IP address block of your VPS. Which turned the speed test into a mess because it autopicked a server in Germany instead of the real location (backed up by the whatismyipaddress mismatch). And in regards of speedtest.net as a proper speed test for servers: no, it's not good for servers. You can test your home connection fine with it but not a server. For proper server testing iperf is still the best and most accurate thing to do. It will really max out the bandwidth you have to its limits.

OK I get it now.  Thanks for explaining this in these details.

To get any sense of the traceroutes we would actually need the full result (you can censor parts of the IP address). If the IP space is really protected (I guess its just a thing about DDoS protection) then you might actually never see your IP address ending up there. It won't respond in the traceroute as a part of its protection and the traceroute will end at some point.

Here is the full result of the traceroute test.  Note that the 107.xxx.235.xxx is a Las Vegas, Nevada (whatismyipaddress) IP.  The IP of origin belonging to my VPS is not listed anywhere in the traceroute result.

1  107.xxx.235.xxx (107.xxx.235.xxx)  0.983 ms  0.941 ms  1.082 ms
2  ae10.cr1-pnap-phx1-cl.phx1.serverhub.com (104.xxx.0.xxx)  34.438 ms  34.469 ms  34.468 ms
3  ae0.bb1-pnap-phx1.phx1.serverhub.com (104.xxx.0.xx)  0.886 ms  0.876 ms  0.855 ms
4  phx-b1-link.telia.net (62.xxx.54.xxx)  1.910 ms  1.932 ms  2.079 ms
5  las-b24-link.telia.net (62.xxx.119.xxx)  9.266 ms  9.288 ms  9.395 ms
6  ntt-ic-326358-las-b24.c.telia.net (213.xxx.103.xxx)  11.708 ms  11.166 ms  11.108 ms
7  ae-2.r23.lsanca07.us.bb.gin.ntt.net (129.xxx.3.xxx)  11.034 ms  11.065 ms  11.132 ms
8  ae-6.r22.asbnva02.us.bb.gin.ntt.net (129.xxx.3.xxx)  65.362 ms  60.515 ms *
9  ae-6.r25.frnkge08.de.bb.gin.ntt.net (129.xxx.4.xx)  146.763 ms  149.419 ms  149.665 ms
10  * * *
11  ae-5.r00.frnkge07.de.bb.gin.ntt.net (129.xxx.4.xxx)  151.764 ms  151.778 ms  149.143 ms
12  ae-2.a01.frnkge07.de.bb.gin.ntt.net (129.xxx.4.xxx)  151.745 ms  149.172 ms  151.732 ms
13  xe-0-0-18-1.a01.frnkge07.de.ce.gin.ntt.net (213.xxx.77.xx)  146.321 ms  148.275 ms  148.288 ms
14  * * *
15  blv2-01-telkomsa-gw.osnet.co.za (196.xx.49.xxx)  293.080 ms  295.543 ms  294.472 ms
16  ipc-aggr-1.south.dsl.telkomsa.net (105.xxx.0.xx)  299.613 ms  299.595 ms  296.979 ms
17  * * *
18  * eltg-ip-bng-2.south.dsl.telkomsa.net (105.xxx.59.x)  306.362 ms  309.914 ms
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Oh. I can see what's going on. It is as @fChk already explained "I would say that the IP is Arizona-based and the first public router it hits is in Las Vegas, NV.". It's a mere 300 miles from Phoenix to Las Vegas. With fibre between the DCs the latency should fall short. Traceroute could help with that, too. Most likely the protected IP space is filtered through a DDoS protection service hosted in Las Vegas, NV. Hence why you don't see your VPS IP address on the VPS itself. The tunnel endpoint is in Las Vegas, NV where the VPS gets its IP but inbetween its using private IP range communication (Intranet).

Well, coming to think about it this situation is absolutely not special. We have this at our company. All our sites are connected with a MPLS fibre network. It is a huge Intranet and at our main site we have a IP breakout that is used to provide Internet to the Intranet. We also have several VPN breakout points at the main site and at the data center in Bavaria for VPN tunnels that we need for applications and servers.

OK - finally I understand how it works.    

Since we now know that my speed test is not from a very accurate source, do you know of a speed test I could use and that would show results in the same format as speedtest.net?