[fChk]

I think the most disappointing for me for the upgrade of VPS 9 Phoenix was the change of the IP that Virmach maintains is a Phoenix IP, but it’s actually a German IP that has been networked to behave as a Phoenix IP, result of which is my ISP in South Africa has to do a double take to work with the IP from before. Latency Ping has shot up from 36 previously to a whopping 147. Speed is also significantly less.

This is what the speed looked like from South Africa to Phoenix with the old Phoenix IP:



And this is what the new IP looks like now from South Africa:

From your input, I would speculate that although your VPS is located at Phoenix, AZ, it's internally tunnelled to Germany where it gets its publicly-facing German IP (think of it as if using a VPN.) That's why Speedtest picks up Frankfurt as the closest host for the test (although the VPS is physically in Phoenix, USA) which explains the unusual latency. And that's why (most probably) they consider the IP in that configuration as "protected".

I would also guess that, in Virmach lexicon, the "unprotected" IPs are the ones that aren't tunneled the way yours does.

---

UPDATED: To account for the Port change issue

I've done one last try with my VPS 9 Phoenix and brought my concerns to the attention of Virmach.  Let's see what they can do.

I'm curious, Did they respond @deanhills?

When I was working with it today, discovered that CentOS 7.0 is not recommended for protected IPs.  Since my IP was a new IP I thought there could be a possibility for it being in that category, so went for CentOS 6.5 instead.  This time round I had no issues getting into the VPS.  But once again was unable to successfully change the port number.  I then abandoned that effort, and went straight into creating a panel, (.....)

Ok!... I may be wrong but I'm afraid that changing port 22 isn't an option in your case and here is the logic of it.

In the eventuality that what I've proposed in the last post, as an explanation for what that "protected IP" thingy stands for @Virmach, is TRUE (and I think it is), then your VPS IP as you see when logged in must be an (internal)  private IP address (which means non-routable on the Internet(/non public.)

This means that your VPS is basically shielded from the Internet Jungle except for the ports that you have explicitly opened (80/443 etc..) Port 22 (for sshd) is your gateway to your VPS and (as such) must have been hard-coded in Virmach port-mapping connectivity between the public-facing interface (in Germany) and your VPS local interface (in Phoenix, AZ.)

In this logic your port issue is also linked to that "protected IP" status you have :-)

Obviously, I'm not aware of Virmach internal networking topology but I presume they must have a great deal of NAT going on for those "protected IP" cases. For as to why they have to do that?.. I'm not sure, but I would presume that it may have something to do with running out of US IPv4 addresses, which imposed the tunnelling of your connectivity to their German datacenter (?!), resulting in the deterioration of the service (ie, the latency increase and the connectivity speed hit.)

A couple of bash commands to test this:
>>> To get your local interface IP:
1-> ifconfig (Centos 6) OR > ip address (Centos 7)
>>> To see how your VPS is connected to the World, use :
2-> traceroute (+ any IP address/use your own IP from SAfrica)

The output of the second command is interesting, especially the first hops' IPs. I would bet that they would be private IPs (2/3 hops) and the first public IP to show up would be German.

As an aside note. I don't think changing sshd's port does make much of a difference once you set the private/public key login and remove the password login for your SSH server. The only thing achieved in this case is shrinking the size of your /var/log/btmp binary file, which logs all bad login attempts.

Anyway, It would be interesting to know if you're the only one on Virmach hosting that has this "protected IP" thing.

PS: The ifconfig tool is provided by net-tools rpm package in Centos 7.

[deanhills]

UPDATED: To account for the Port change issue


I'm curious, Did they respond @deanhills?

Thank you for updating your feedback @fChk, which already was excellent and helped me understand the issue much better.  I have a better grasp, but I'm still confused though.

Yes, the sponsor did respond. They maintain that the IP is a Phoenix IP - their response is quoted below (I've deleted the link info for security reasons - and added edited content of the link at the bottom of the quoted post).

Those speedtests don't really mean anything as they're using drastically different test points. Please provide different data/use a singular test point. We recommend against speedtest.net for testing, please provide data with other tests so we can take a deeper look. The IP is also associated with Phoenix.

Link info:

WHOIS-RWS
You searched for: 50.x.xx.xx
Network
Net Range 50.x.xx.x - 50.x.xx.xx
CIDR 50.x.xx.x0/xx
Name SHUB-NETBLK-PHX
Handle NET-50.x.xx.x
Parent EONIX (NET-50.x.xx.x)
Net Type Reallocated
Origin AS AS30693
Organization Virtual Machine Solutions LLC (VMSL-8)
Registration Date 2016-01-11
Last Updated 2016-01-11
Comments This IP address space is assigned statically to the registered customer. IP Addresses within this block are not portable. Please contact the reallocated customer for abuse complaints. If attempts to contact the reallocated customer are unsuccessful, please make an escalated complaint for UCE, SPAM and fraudulent activity that is strictly prohibited from this network by contacting the upstream at: [email protected]
RESTful Link https://whois.arin.net/rest/net/NET-50.x.xx.x
See Also Related organization's POC records.
See Also Related delegations.

I disagree with their point about speednet, in that one can compare speeds from the US that would be relative to the test.  I.e. my HostUS VPS speed is excellent - using the same ISP.  I agree that speednet is not the go-to to use, but one can still compare the speed of one VPS with another that would be relative to the test used.

Ok!... I may be wrong but I'm afraid that changing port 22 isn't an option in your case and here is the logic of it.

In the eventuality that what I've proposed in the last post, as an explanation for what that "protected IP" thingy stands for @Virmach, is TRUE (and I think it is), then your VPS IP as you see when logged in must be an (internal)  private IP address (which means non-routable on the Internet(/non public.)

This means that your VPS is basically shielded from the Internet Jungle except for the ports that you have explicitly opened (80/443 etc..) Port 22 (for sshd) is your gateway to your VPS and (as such) must have been hard-coded in Virmach port-mapping connectivity between the public-facing interface (in Germany) and your VPS local interface (in Phoenix, AZ.)

In this logic your port issue is also linked to that "protected IP" status you have :-)

Obviously, I'm not aware of Virmach internal networking topology but I presume they must have a great deal of NAT going on for those "protected IP" cases. For as to why they have to do that?.. I'm not sure, but I would presume that it may have something to do with running out of US IPv4 addresses, which imposed the tunnelling of your connectivity to their German datacenter (?!), resulting in the deterioration of the service (ie, the latency increase and the connectivity speed hit.)

I'm still not certain about this - but that has been my own logical conclusion.  I'll ask @Dynamo but wonder whether if the IP has a "natural" location of Germany whether I could ask them to make my VPS German location?  I've hesitated so far as I thought - and maybe still am thinking - I'm not getting how the IP works.  

A couple of bash commands to test this:
>>> To get your local interface IP:
1-> ifconfig (Centos 6) OR > ip address (Centos 7)
>>> To see how your VPS is connected to the World, use :
2-> traceroute (+ any IP address/use your own IP from SAfrica)

The output of the second command is interesting, especially the first hops' IPs. I would bet that they would be private IPs (2/3 hops) and the first public IP to show up would be German.

I'm totally perplexed @fChk:

I did as you suggested. Total confusion, as the result doesn't start with the VPS IP that was given to me.  In fact my IP doesn't show up at all in the traceroute feedback.  The first IP is from Las Vegas Nevada - and starts with 107.  My allocated VPS German IP number doesn't feature any where in the traceroute feedback.

As an aside note. I don't think changing sshd's port does make much of a difference once you set the private/public key login and remove the password login for your SSH server. The only thing achieved in this case is shrinking the size of your /var/log/btmp binary file, which logs all bad login attempts.

Anyway, It would be interesting to know if you're the only one on Virmach hosting that has this "protected IP" thing.

PS: The ifconfig tool is provided by net-tools rpm package in Centos 7.

It makes a HUGE difference for me with the previous Phoenix IP.  Like login attempts went from thousands to zero.  

But here's a strange thing for you.  With my last access with Putty SSH with my new "German" IP, there were no failed login attempts.  That now has me baffled too. Maybe I don't need to change the Port number any longer.  And you're right - what I understand now is that the "German" VPS IP that was given to me is not visible at all.  

To summarize however. Now that I'm learning to work with how it is (vs with how it used to be), the speed feels completely OK for me. My uptime has been consistent sofar. My Website is still up since I loaded it two weeks ago. Access to my VPS is also fast. So I really have nothing to complain about other than trying to have a better understanding of how the new IP works.

[fChk]

@deanhills

From the specifics included in the Virmach quote, the IP does indeed belong to an Arizona-based IP range; ie it's a US IP (thus my reasoning was wrong about it being German.)

By default, Speedtest tries to chose the most suitable host (host with the lowest latency -ie. the nearest- from its list) before running its test. That's what made think the IP was German, given that the host in your test was in Frankfurt. What happens to the latency when you run that test against a host in the US south (TX, AZ NV..) ? Did you try that?

Reading the rest of your response, I would say that the IP is Arizona-based and the first public router it hits is in Las Vegas, NV.

... But I still maintain that port 22 is hard-coded somewhere in their "protected networking" setup which prevents you from changing it.

Sorry if I've added to your confusion :-)

[deanhills]

@deanhills

From the specifics included in the Virmach quote, the IP does indeed belong to an Arizona-based IP range; ie it's a US IP (thus my reasoning was wrong about it being German.)

By default, Speedtest tries to chose the most suitable host (host with the lowest latency -ie. the nearest- from its list) before running its test. That's what made think the IP was German, given that the host in your test was in Frankfurt. What happens to the latency when you run that test against a host in the US south (TX, AZ NV..) ? Did you try that?

Reading the rest of your response, I would say that the IP is Arizona-based and the first public router it hits is in Las Vegas, NV.

... But I still maintain that port 22 is hard-coded somewhere in their "protected networking" setup which prevents you from changing it.

Sorry if I've added to your confusion :-)

No apology needed @fChk. My challenge is/was that the traceroute test from the VPS to my ISP didn't show my new ("German") IP as the first IP.  The first IP shown is a 107 IP from Las Vegas, Nevada.  The IP I've been given, that the Speedtest shows as German, is not mentioned at all in the traceroute result.  The traceroute path sees the VPS as having the 107 IP that comes from Las Vegas.

Now only explanation that can make sense for me is that my new IP is protected and when it is protected it is hidden.  So it wasn't shown in the traceroute.  The traceroute results skipped to the next IP 107 Las Vegas Nevada and hid the first IP - which is my new IP.  That's why I can't see it.

I found a different IP test as well that pretty much corroborated what you said - i.e. location is US:

https://www.ip2location.com/50.xx.xx.xx

Translates IP address (IPv4 or IPv6) to country, region or state, city, latitude and longitude, ZIP/Postal code, time zone, Internet Service Provider (ISP) or company name, domain name, net speed, area code, weather station code, weather station name, mobile country code (MCC), mobile network code (MNC) and carrier brand, elevation, and usage type.

And the result of that test for my new VPS IP is:

Country United States of America [US]
Region Nevada
City Las Vegas
Coordinates of City 36.174970, -115.137220 (36°10'30"N   115°8'14"W)
ISP Virtual Machine Solutions LLC
Local Time 31 Dec, 2019 06:59 AM (UTC -08:00)
Domain virmach.com
Net Speed (COMP) Company/T1
IDD & Area Code (1) 702
ZIP Code 89044
Weather Station Las Vegas (USNV0049)
Mobile Carrier -
Mobile Country Code - MCC -
Mobile Network Code - MNC -
Elevation 607m
Usage Type (DCH) Data Center/Web Hosting/Transit
Anonymous Proxy No
Proxy Type (DCH) Hosting Provider, Data Center or CDN Range
Proxy ASN 62904 Eonix Corporation
Proxy Last Seen 30 Days
Olson Time Zone America/Los_Angeles

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.

It's still confusing, as the new IP I have been given looks like a typical German Frankfurt IP.  I  visited Virmach's Looking Glass giving test IPs for all of its locations and the German location looking glass IP almost matches my IP exactly:
https://billing.virmach.com/knowledgebas...tions.html

So maybe your original conclusion that the US is running out of IPs may be true as well. I still don't have a really good understanding of how it works, but it's at least better than right at the beginning.

[Mashiro]

IP address(es) geolocation data cannot be trusted if you wish to find out the location of a server. Virmach (Virtual Machine Solutions LLC) seems to own the IP address block from which your VPS has received its IP address. They can basically change the geolocation data for the whole block at the IP RIR (probably ARIN). The IP geolocation could as well just point to anywhere else in the US or the world. Virmach is registered in Los Angeles, CA... 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).

Another possible reason why the IP address(es) are all geolocated to Las Vegas, NV might be a business reason. Like you may know companies that are registered somewhere else but do their business out of a different location (taxes, and so on). Mostly their IP address blocks get geolocated for that reason because they're company assets and cost money, too. That's possible and only works with IP address(es) that they fully own. Although they might be able to ask a provider to change the geolocation for rented IP space but in that case the ASN of the IP address(es) would be still the original one of the data center/provider. Basically like you as a normal customer can change the rDNS they can do a little more as customers of the data center with a RTO or colocation contract (or other form of contracts).

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. I don't remember if I already told this little story. Basically a few years ago Google would say that I'd be from several different countries when I normally browsed it without any VPN. It would say I'm from Germany (correct) but another day or time it would say I'm from somewhere in Asia or suddenly in South America. The fun part was that the IP addresses I had were all from the same IP address block (so not even different IP blocks). Later on I learned that Google uses or used quite a number of geolocation services and they most likely either build their own databases used on datasets of other databases or were training their database for better results. Nowadays it seems to be better but when I use my VPN service I do see some wrong locations sometimes or it even says "Unknown location". TL;DR: you cannot trust this information really either.

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.


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.

And the IP space being protected... 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.

[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?

[Mashiro]

@deanhills

Another (new) note about the IP address(es) geolocation. Based on my previous post and what @fChk also mentioned I think that the IP address is geolocated correctly (actually) because the tunnel endpoint of this protected IP address space (your VPS IP) is at the Las Vegas, Nevada location / data center. You see this being even confirmed by the fact that the first hop from the traceroute is another IP address out of Las Vegas, Nevada. You also see that for some reason the traffic goes back to Phoenix, Arizona and from there on it goes its normal route.

Code: (Select All)

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

(It wasn't necessary to censor any other IP address than the first hop and the last hop. Everything in between are core routers and exchanges at data centers.)

1st hop is most likely the core router or similar in Las Vegas going to 2nd hop in Phoenix at Serverhub (data center) where it is passing another Serverhub Phoenix router (hop 3) and then going to a local Phoenix bandwidth exchange hosted by Telia.net (hop 4). From there on it continues further through the US and etc over Germany (hop 9 through 13) before it seems to reach South Africa and continues there (hop 15).

So in light of their tunnel to protect the VPSs from attacks it rather seems to be correct that the IP space is geolocated to Las Vegas, Nevada as all their tunnels seem to end there and from there they get their Internet connection. Hence why Virmach keeps and will keep insisting and saying not to worry about the location. So why sites detect different locations still stays mostly like I said before: due to geolocation databases being inaccurate and / or multiple databases being used at different times and checks.


Another note about the traceroute as you mentioned it. The initator IP of the traceroute (your VPS) will never appear in the traceroute path. A traceroute always starts with the first hop that your machine reaches when it communicates with a network. That is usually the first router or a firewall. That is the 107.* IP address in Las Vegas, Nevada. So you will never see the IP address of the machine from where you started a traceroute or ping from unless you capture the network packets and analyze them (with Wireshark for example).


About the speed tests. You could use speedtest.net still if you really wanted but don't let it auto pick the location but rather pick a location in Arizona or around it manually. Additional speed tests you can do easily with for example the benchmark scripts. The speed tests there do basically the same as speedtest.net by downloading a big file and measuring the speed (no upload speed here though). As I explained before maybe a much more proper test would be a iperf test to a iperf server near to the VPS location.

There are a few public iperf3 servers available:
- https://iperf.cc/ (Multiple locations)
- https://speedtest.serverius.net/ (Netherlands)
- https://iperf.fr/iperf-servers.php (France)
- http://iperf.volia.net/ (Ukraine)

For example at https://speedtest.serverius.net/ you have instructions to perform a download and upload speed test using iperf3 to the Serverius iperf server. This server is hosted in the Netherlands though.

You could use the Fremont, CA server from https://iperf.cc/ for a test because that seems to be the closest server to your VPS location.

Download:

Code: (Select All)

iperf3 -c iperf.scottlinux.com -p 5002 -P 10 -4 -R

Upload:

Code: (Select All)

iperf3 -c iperf.scottlinux.com -p 5002 -P 10 -4

^ You have to install iperf3 on your VPS first before you can run these commands.

Alternatively you can of course even host your own iperf server and test your VPS against it for example.

[ikk157]

CentOS 7 didn't work.  And during my last successful try with my VPS I learned it was because the new IP they gave me with the upgrade had to have been a protected IP.  The Admin Panel discourages download of CentOS 7 for protected IPs.  The moment I started with CentOS 6.5 earlier in the week, I was able to work with my VPS again.  But yes, I totally agree with you.  Some of the issues I was having could be as a result of CentOS 6.5 being dated.  I'm just too happy however that I'm up and running with my VPS again.  I'm hoping that once the upgrades have been consolidated that the Virmach Tech staff will be able to get their OS sorted out and that we'll have an option for CentOS 8 as well.  I'm sure they must be well aware of the shortcomings - particularly with Ubuntu.

I'm also very tempted to change OS to Debian.  But for now I've got limited time, particularly Internet availability so am doing the best I can with what I have available to me, instead of trying to work with what I don't have.  If that makes sense to you at all.  

This got me wondering, have you contacted Virmach directly regarding all the issues that you’ve been experiencing? Same goes with the OS availability. I would love to get a proper answer from them regarding both these aspects. It’ll definitely be much better than us just constantly assuming things haha. And for all we know, they might not even be aware of the issues.

[deanhills]

This got me wondering, have you contacted Virmach directly regarding all the issues that you’ve been experiencing? Same goes with the OS availability. I would love to get a proper answer from them regarding both these aspects. It’ll definitely be much better than us just constantly assuming things haha. And for all we know, they might not even be aware of the issues.

No progress for now. I may ask @Dynamo, who has a special relationship with Virmach, when he has time, to check up with Virmach.

I checked out VPS 9 Dallas and CentOS 7.0 doesn't work with the VPS 9 Dallas either. Possibly the Dallas IP is also a protected IP then. CentOS 6.5 does work. So by default since Ubuntu won't work on it, and we still have issues with SSH when it is updated, it's not an ideal VPS for a Games Server at the moment.

[deanhills]

@deanhills

Another (new) note about the IP address(es) geolocation. Based on my previous post and what @fChk also mentioned I think that the IP address is geolocated correctly (actually) because the tunnel endpoint of this protected IP address space (your VPS IP) is at the Las Vegas, Nevada location / data center. You see this being even confirmed by the fact that the first hop from the traceroute is another IP address out of Las Vegas, Nevada. You also see that for some reason the traffic goes back to Phoenix, Arizona and from there on it goes its normal route.

Thanks @"Hidden Refuge".  I understood this from your explanation yesterday, but even better now.

(It wasn't necessary to censor any other IP address than the first hop and the last hop. Everything in between are core routers and exchanges at data centers.)

 Thanks for that valuable tip.  I'm always unsure what to censor, now have a better understanding.

1st hop is most likely the core router or similar in Las Vegas going to 2nd hop in Phoenix at Serverhub (data center) where it is passing another Serverhub Phoenix router (hop 3) and then going to a local Phoenix bandwidth exchange hosted by Telia.net (hop 4). From there on it continues further through the US and etc over Germany (hop 9 through 13) before it seems to reach South Africa and continues there (hop 15).

So in light of their tunnel to protect the VPSs from attacks it rather seems to be correct that the IP space is geolocated to Las Vegas, Nevada as all their tunnels seem to end there and from there they get their Internet connection. Hence why Virmach keeps and will keep insisting and saying not to worry about the location. So why sites detect different locations still stays mostly like I said before: due to geolocation databases being inaccurate and / or multiple databases being used at different times and checks.

Thanks HR, I understand this now.  Also, that although the new IP given to me resembles the German IP numbering, if one checks Virmach has registered it correctly as from the US.  

Another note about the traceroute as you mentioned it. The initator IP of the traceroute (your VPS) will never appear in the traceroute path. A traceroute always starts with the first hop that your machine reaches when it communicates with a network. That is usually the first router or a firewall. That is the 107.* IP address in Las Vegas, Nevada. So you will never see the IP address of the machine from where you started a traceroute or ping from unless you capture the network packets and analyze them (with Wireshark for example).

 That's interesting, as yesterday when I experimented with VPS 9 Dallas just for comparison, the traceroute started with the IP for the VPS - Dallas IP - or it had the appearance of it.  I.e. the IP for Dallas is 23.**.75.34 and the first IP in the Dallas traceroute then was exactly the same except for the .34 was .33.  

BTW.  Dallas has the exact same issues as VPS 9 Phoenix.  CentOS 6.5 works OK.  CentOS 7.0 has issues.  I don't know whether you would like to have a look at VPS 9 Dallas.  It's not occupied presently.  Let me know if you are game to test it, goal of which would be to compose a ticket to Virmach but giving them technical details that will help them to help fix the problem.

Priority issues would be problems with OS - not having Ubuntu available, and not having an up to date CentOS.  Possibly you could be more analytical with proper IT speak that the technicians at Virmach would be able to understand.  If and when you have time available.

About the speed tests. You could use speedtest.net still if you really wanted but don't let it auto pick the location but rather pick a location in Arizona or around it manually. Additional speed tests you can do easily with for example the benchmark scripts. The speed tests there do basically the same as speedtest.net by downloading a big file and measuring the speed (no upload speed here though). As I explained before maybe a much more proper test would be a iperf test to a iperf server near to the VPS location.

There are a few public iperf3 servers available:
- https://iperf.cc/ (Multiple locations)
- https://speedtest.serverius.net/ (Netherlands)
- https://iperf.fr/iperf-servers.php (France)
- http://iperf.volia.net/ (Ukraine)

For example at https://speedtest.serverius.net/ you have instructions to perform a download and upload speed test using iperf3 to the Serverius iperf server. This server is hosted in the Netherlands though.

You could use the Fremont, CA server from https://iperf.cc/ for a test because that seems to be the closest server to your VPS location.

Download:

Code: (Select All)

iperf3 -c iperf.scottlinux.com -p 5002 -P 10 -4 -R

Upload:

Code: (Select All)

iperf3 -c iperf.scottlinux.com -p 5002 -P 10 -4

^ You have to install iperf3 on your VPS first before you can run these commands.

Alternatively you can of course even host your own iperf server and test your VPS against it for example.

Thank you very much for this suggestion.  I did something yesterday along these lines for both VPS 9 Dallas and Phoenix to compare the two.  The speedtest.net showed great results for Dallas compared with Phoenix, but then when I did a Benchmark summary of both, I'd say they're more or less the same speed - relative to their geolocation.