Jump to content
Not connected, Your IP: 3.230.144.31

go558a83nk

Members2
  • Content Count

    1916
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    27

Reputation Activity

  1. Like
    go558a83nk reacted to Staff in [COMPLETED] Emergency maintenance in Dallas, Texas (US)   ...
    Hello!

    We inform you that an emergency maintenance due to urgent hardware replacement will be ongoing on 2021-09-18 between 19 and 23 CEST on the Dallas datacenter. The maintenance will impact all of our VPN servers in Dallas: expected downtime is approximately 30 minutes.

    Kind regards
    AirVPN Staff
     
  2. Thanks
    go558a83nk reacted to Stalinium in M247 misrepresenting true location of Barcelona Phoenix and Berlin Air Servers   ...
    The server is not in Berlin. M247, AS9009 does not have peering in Berlin.
    I checked with a looking glass run by a very nice person and it has multiple servers from different networks in Frankfurt and one server in Berlin. Apart from outsiders that have 14ms ping from allegedly FRA to FRA, most pings are ~1ms and confirm what traceroutes here show. The only lg Berlin server to Air's Cujam has got 8ms ping. That lg Berlin server is hosted on a network that's has peering at BCIX and ECIX-BER. Even if the Cujam server were 'physically in Berlin' then it doesn't matter because what matters to users is latency, alias geographic location.
    Back to what M247 say themselves, all four German DCs are in Frankfurt: Ancotel (Equinix), Interxion FRA4, Telehouse Frankfurt, Global Switch Frankfurt
    https://m247.com/services/host/dedicated-servers/ https://m247.com/services/cloud-hosting/ https://m247.com/services/host/colocation/
    The only location in Germany on this map is Frankfurt.

    I cannot thoroughly check Spain, but again AS9009 is at DE-CIX Madrid and doesn't appear to be present at DE-CIX Barcelona, two Madrid servers' pings are 0.3ms and 2ms to "Barcelona" Eridanus.

    Whatever the reasons, the current descriptions are not representing the reality.

    PS: Actually the entire prefix/subnet is reported as Berlin by M247. Hence the geolocation databases say it is "in Berlin", that's the definition of a "virtual location" right? Still I see how it could be useful in certain cases even though the server is not physically there. Until this is clearly indicated, it will be a shortcoming especially in terms of sincerity and transparency.
  3. Thanks
    go558a83nk reacted to Staff in Server replacement (UK)   ...
    Hello!

    Our first 10 Gbit/s lines dedicated only to our servers were used for the first time in Dallas, Texas, several years ago. One line is for the VPN servers and another one for the Tor nodes by Quintex. Then we had four (now six) 10 Gbit/s lines in the Netherlands. Each line was and is shared by 10 or 11 of our servers.

    Then Xuange came, in Switzerland, that was the first one with an exclusive 10 Gbit/s line. Ain then followed and has been the last one at the moment.

    As @OpenSourcerer says, prices in some locations (such as Tokyo) are too high for 10 Gbit/s and at least 600 TB traffic per month for a single server (2 Gbit/s 24/7 means you generate 600 TB in a month). Moreover, in order to beat the usual 1 Gbit/s full duplex, more powerful hardware is needed and a different software approach too.

    Even so, on Xuange and Ain we could not manage to squeeze more than 3-4 Gbit/s (in total, up+down) when more than 150 clients are connected, and even the most powerful CPUs available on the market, running one OpenVPN instance per virtual core, suffer. The whole system get choked if we go up to 300 clients, which would be the minimum amount required to run those servers without losing money. Wireguard might help but it's uncertain and anyway many core customers of ours don't accept it for the notorious privacy problems, other customers can't use it for UDP blocks/shaping and so on, so we can't and we won't drop OpenVPN in any case.

    EDIT: it's not only a pure AES/CHACHA20 processing power issue, but also a conntrack and packert mangling huge queue related issue, which gets intertwined with pure encryption/decryption processing power problems. - pj

    For us, the cost per user to be provided with high bandwidth is remarkably higher with dedicated 10 Gbit/s single server lines, because we experimentally see that we can not put on such a server 10 times the users a 1 Gbit/s server can handle (unless we wanted to lower the quality of service, which is not on the table). Therefore, if we want to keep the same prices and at the same time we don't want to oversell, offering an infrastructure all based on a 10 Gbit/s line per server for 2.75 EUR/month (the current price for 3 years subscriptions) is not realistic.

    Remember that year after year prices of AirPVN went down or remained unchanged, and today AirVPN is probably the less expensive VPN around (ruled out the free ones, as they profile you or do worse things too).

    Maybe in the future, or maybe with a different pricing, migration to all "10 Gbit/s servers" could be pursued.

    We're not "over-cautious" but realistic: in the last 5-6 years, while other VPN services accumulated important debts surpassing tens and tens of USD millions (think about PIA mother company, which went down for more than 30 millions in just 3 or 4 years; and other big ones, which are forced to oversell and continuously pay for favorable bogus reviews hiding overselling in order to survive) AIrVPN never ever had debts.

    Who would be interested in paying more (probably x3 or even x4) to have access to 10 Gbit/s dedicated lines (one line per server) on a wide variety of AirVPN locations with the usual AirVPN quality? We might start a survey to know.

    Kind regards


     
  4. Thanks
    go558a83nk got a reaction from farquaad in Entry ip   ...
    1 is the default
    2 is the same server setup as 1 but a different entry IP in case the default IP is blocked by your ISP
    3 is tls-crypt
    4 is the same server setup as 3 but a different entry IP in case the 3 IP is blocked by your ISP
  5. Thanks
    go558a83nk reacted to User of AirVPN in M247 misrepresenting true location of Barcelona Phoenix and Berlin Air Servers   ...
    Hello,
    Recently I have noticed that it looks like the Phoenix AirVPN servers (Bootes, Chalawan, Indus, Phoenix, Virgo) , Berlin AirVPN Server (Cujam) , and Barcelona AirVPN server (Eridanus) are not actually located where M247 claims they are located, and it appears M247 is misrepresenting the locations of these servers


    If you go to the status page of any "Phoenix" server for example
    https://airvpn.org/servers/Bootes/

    you will see the latencies to other cities where AirVPN has servers, and it shows 0ms to Los Angeles, that wouldn't be physically possible if the Phoenix servers were truly located in Phoenix.
    This points to the Phoenix servers truly being hosted in Los Angeles

    Additionally, on a personal VPS server of mine which is located in Los Angeles, I get less than 1ms latency between my VPS in Los Angeles to the AirVPN "Phoenix" servers, which, again, points to the Phoenix servers truly being in Los Angeles, because this 1ms latency would not be physically possible between Los Angeles and Phoenix


    And if you go to the status page of the "Berlin" server
    https://airvpn.org/servers/Cujam/
    It shows 0ms latency to Frankfurt, also not physically possible
    This points to the Berlin servers really being in Frankfurt

    And if you go to the status page of the "Barcelona" server
    https://airvpn.org/servers/Eridanus/
    It shows 0ms latency to Madrid, again, not physically possible!
    This points to the Barcelona servers truly being hosted in Madrid


    M247 may say that if you do a WHOIS lookup on their Phoenix IP block, the description is "M247 Phoenix" but honestly this is not proof at all, as the network admins can set whatever netname and description they want when they're creating the inetnum object in their RIR's database.


    For additional proof other than the "Berlin" , "Barcelona", and "Phoenix" that Air has from M247,



    Here is M247's full list of locations according to their website

    You can see that neither Berlin, Phoenix, or Barcelona is on this list.


    https://m247.com/services/host/dedicated-servers/

    From the website, their locations:

    Europe:
    Amsterdam, NL
    Belgrade, RS
    Brussels, BE
    Bucharest, RO
    Budapest, HU
    Copenhagen, DK
    Dublin, IE
    Frankfurt, DE
    London, UK
    Manchester, UK
    Madrid, ES
    Milan, IT
    Oslo, NO
    Paris, FR
    Prague, CZ
    Sofia, BG
    Stockholm, SE
    Warsaw, PL
    Vienna, AT
    Zurich, CH

    North America:
    Dallas, TX, USA
    Los Angeles, CA, USA
    Miami, FL, USA
    New York Metro Area, USA (Secaucus, NJ)
    Montreal, QC, CA

    Asia and Middle East:
    Dubai, UAE
    Hong Kong, HK
    Singapore, SG
    Tokyo, JP

    Oceania:
    Sydney, AU



    Based on this information it is clear to see that M247 is misrepresenting the locations of AirVPN's Phoenix, Berlin, and Barcelona servers,


    From being a customer of Air for as long as I have, I can tell that the Air staff are honest and they have provided and continue to provide a great and true service, this is extremely evident for example by looking at how AirVPN left France because of the concerning legal framework there, and why AirVPN does not operate in Poland or Italy for similar reasons, even though other VPNs gladly operate services in those countries. It's clear as day to see that AirVPN is not deceptive or untruthful at all, so I am absolutely not accusing Air at all of participating in this misrepresentation, it just seems to me like Air was duped by M247 into buying these servers that are reported to be in a different location than the one they are truly in.


    So given that the 5 Phoenix AirVPN servers , the 1 Berlin server, and 1 Barcelona server are falsely geolocated, it would be good idea for Staff to replace those servers with ones that are actually in the reported locations, or just change the reported location of those servers in Eddie to reflect the true locations.

     
     
  6. Confused
    go558a83nk reacted to Staff in Server replacement (UK)   ...
    Hello!

    We inform you that all of our VPN servers in Maidenhead will cease operations on 03 September 2021. They will be replaced by servers in London featuring more modern hardware. Unfortunately, both technical and non-technical reasons force us to leave the current dc in Maidenhead.

    Servers in London are anyway located just 40 Km from Maidenhead and they will be announced and available in the next days.

    The new machines will keep the same names in order to support the old FQDN used by OpenVPN client profiles. Since the datacenter seems to have put offline already a server before the natural expiration date, we could put the new servers online before the mentioned 03 September date. When new servers are turned on, older ones with the same name will be disconnected from the infrastructure. This thread will be updated, if necessary, accordingly.

    The replacement servers are five, while the replaced ones are six. That's because we might be adding in the future another datacenter in UK in a different location.

    Kind regards
    AirVPN Staff
  7. Like
    go558a83nk got a reaction from Air4141841 in PIA's dedicated IP feature   ...
    no way.  then they couldn't truthfully say to law they don't know who did what from a server IP because they know it belongs to you.
  8. Like
    go558a83nk reacted to Stalinium in Happy AirVPN power user   ...
    I don't know what to write about... Everything's fine and I love AirVPN. Sounds cheesy but it is what it is. I've been using AirVPN for half a year.

    Many servers to choose from, very transparent from the user's point of view - something I value. Transparency about server status and an API (admittedly I haven't used it much). From reading the forums I grasped that AirVPN has very strict (legal) criteria for choosing server locations (countries), an approach that is unique across all providers I've seen so far. Yea placing servers in China wouldn't be the best idea or many other more "democratic" as a matter of fact which were ruled out.
    The config generator is awesome if you're not using their open source client Eddie (bonus points again!) - plenty of flexibility. Configs? Afaik there're some providers out there who still have user/password prompt on each connection, laughable. AirVPN not only properly makes use of certificates (that's how the server knows you are you without asking for credentials) and on top of that allows you to properly distribute different access keys across your devices (in case of theft etc). Lost a device? Revoke access to that single one and done!

    Port-forwarding support ALONG WITH Dynamic DNS is unparalleled. Sure an advanced user probably could create an ad-hoc DDNS solution for themself, but offering it along the VPN is ingenius.
    The servers are very stable, the stats currently show a user has been connected since January. I've read comments where other VPNs often force reconnects etc, that just sounds wild to me. Before AirVPN I've been on a private VPN server with 24/7 uptime and that's the quality of service I got used to and wouldn't want to downgrade from (looking at those other VPN providers)

    The AirVPN forums are a great source of information. The staff cannot be commended enough for responding to concerns and generally being here for discussion. @OpenSourcerer is a damn community hero, this place is unimaginable without him! I myself have contributed in one form or another and will continue to. As a side note to forums: AirVPN appears to have customized the forum software for privacy. I can't assess how far it goes (hopefully "enough"), and it's a far better choice than those completely relying on Reddit - undoubtedly a useful puppet of/for the certain government.

    The only problem I've had was with initial payment. I bought the 1 month plan and found no clear indications it was still active (because it is a PayPal recurring payment), so before the month expired I bought the 1 year plan. I was quite surprised to see a few days later my access days to have been extended by +31d - the automatic Paypal payment kicked in and I paid a single month extra. Though I like the service so much I decided not to bother with a refund (consider it a donation hehe). You need to login in Paypal to cancel those, I wish this was made clear/er. What's unclear to me was whether/how much info is retained on payment after all the transactions... but to grossly paraphrase an official response: use crypto. Just make sure your mug shot (photo) isn't connected to the coin wallet

    Roses are red,
    AirVPN's great.
  9. Like
    go558a83nk reacted to daleus in Using AirVPN on OPNsense   ...
    Hi,

    1. Open the .ovpn file in notepad or something and copy everything from resolv-retry infinite down to the bottom.

    Go to vpn -> openvpn -> clients and select your openvpn instance
    Set it to SSL/TLS/UDP4 (I haven't tested with anything except UDP4)
    Insert a hostname / port
    Go to Advanced Box & Paste, click save and connection should come up under vpn->openvpn->connection status
  10. Like
    go558a83nk reacted to Staff in Sony won lawsuit against Cox Cable ISP for copyright infringement -- HEADLINE: "Americans could be cut off from the internet over copyright claims"   ...
    @monstrocity

    Hello!

    The errors and embezzlement caused by bogus copyright notices are notorious since 2008 at least. That's a decisive reason to understand how the graduated response must include the constitutional right to a due process, and that each copyright infringement claim must be validated or rejected by a court, if the alleged infringer wants to exercise her fundamental right to a due process with presumption of innocence.

    How bogus notices can be sent, and how a malicious user knowing your IP address can trivially cause an arbitrary amount of copyright notices to be sent to you, was well explained many years ago in the scientific paper "Why my printer received a DMCA takedown notice".
    http://dmca.cs.washington.edu/uwcse_dmca_tr.pdf

    The fact that, in spite of all the above, various companies still dream of automated graduated response and deletion of the right to a due process and the right to legal defense shows, in our opinion, the mental imbalance of certain persons and the hidden agenda to keep making money with bogus activities: business for companies which offer their services to monitor p2p swarms and automatically generate notices was quite big years ago. And it's also sad to see, when citizens defend the copyright mafia graduated response concept, how easily many citizens are inclined to renounce to fundamental, human rights.

    @ProphetPX

    The news you reported seem to be confirmed independently by TorrentFreak, which published a day earlier:
    https://torrentfreak.com/comcast-suspends-internet-connection-for-downloading-torrents-210630/

    Kind regards
     
  11. Like
    go558a83nk reacted to Staff in Sony won lawsuit against Cox Cable ISP for copyright infringement -- HEADLINE: "Americans could be cut off from the internet over copyright claims"   ...
    @OpenSourcerer

    Just to clarify that this is not "fake news":
    https://www.eff.org/deeplinks/2021/06/if-not-overturned-bad-copyright-decision-will-lead-many-americans-lose-internet
     
    A moderator can not threaten an ex ante, pre determined censorship based on the source of the information, be it a web site or anything else. Before you enforce your censorship power we gave you, you must cross-check and verify. If you are not able to do so beyond a reasonable doubt, or you have not the time or will to do so, do not censor.

    Kind regards
     
  12. Thanks
    go558a83nk reacted to westrock2000 in Used for a 2.5 years for file sharing...incredible uptime!   ...
    I  sampled about 6 different VPN's when I started a Soulseek server. I needed a VPN that supported Port Forwarding. I went with AirVPN because of it's reliability, and have not regretted it yet. Very very rarely has Eddie had issues connecting....maybe 2 time a year it gets hung up and I have to restart it. But otherwise it stays connected and people download from me 24/7.
  13. Like
  14. Like
    go558a83nk reacted to courteousorbit in Pfsense ,NEED private key for stunnel.crt, encryption wont work without please   ...
    so i cant add a ca file as everyone may know in pfsenses stunnel package manager under services without a certificate, meaning i need you guys to add a private key to the stunnel.crt file per config generator so i can create a proper certificate for my ca , need this to get stunnel proper encrypted thanks
  15. Like
    go558a83nk reacted to sundi in People should know more about AirVPN   ...
    Hi,

    [no!]
    Other than me there was only one other user who commented on using AirVPN.
    I want more people to know about our AirVPN and its awesome service.

    Should we/staff do something to make AirVPN more popular?
    Should staff contact the famous youtubers for testing out AirVPN to make it more popular?
  16. Thanks
    go558a83nk got a reaction from superuser1970 in More speed for more money suggestion   ...
    You're not artificially being throttled by Air.  That's just the way things are with openvpn with limitations by CPU, network, internet, etc.  A client on the usual 1gbit/s server will see only about 500mbit/s download max because the server throughput limit is 1gbit/s inbound and outbound combined. 

    Air does have at least 1 server that's 10gbit/s.  Try it to see if it's any better for you.
  17. Like
    go558a83nk got a reaction from dIecbasC in When you don't read instructions...   ...
    The guide is for a tls-crypt setup where those settings are what work.  What you're missing is that you need to connect to an entry IP 3 or 4.  The guide actually says " please double check you select an appropriate ‘tls-crypt, tls1.2’ end point. This is a common source of problems."
  18. Like
    go558a83nk got a reaction from dIecbasC in When you don't read instructions...   ...
    No, the problem is with you unable to follow directions.

    In the tutorial, the first directive in the "generate AirVPN certificates" section is to enable advanced mode.  Have you turned on advanced mode in the config generator?
  19. Like
    go558a83nk reacted to Staff in New country: New Zealand - New 1 Gbit/s server available   ...
    Hello!

    We're very glad to inform you that a new 1 Gbit/s server located in Auckland (NZ) is available: Fawaris. We're also very pleased to be back in Oceania.

    The AirVPN client will show automatically the new server. If you use any other OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator").

    The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP.

    Just like every other Air server, Fawaris supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3 and tls-crypt.

    Full IPv6 support is included as well.

    As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.

    You can check the server status as usual in our real time servers monitor:
    https://airvpn.org/servers/Fawaris

    Do not hesitate to contact us for any information or issue.

    Kind regards and datalove
    AirVPN Team
  20. Thanks
    go558a83nk got a reaction from bama in pfsense / SSL Tunnel specific guide?   ...
    you don't need to import any cert for stunnel to work.

    1) install stunnel package from package manager
    2) Create the stunnel tunnel here in services>stunnel.  /pkg.php?xml=stunnel.xml
    Select client mode use 127.0.0.1 as listening IP listen on port doesn't matter but you'll just use whatever you put here in the openvpn client setup certificate is default redirect IP is found in the .ssl file that you can download for stunnel in the config generator redirect port is also found in that ssl file (in the name of the file too) save the stunnel tunnel your status_logs.php should show stunnel activity to let you know it's running 3) Create or edit an openvpn config for AirVPN keeping everything the same as usual but changing the following protocol is TCP only interface is any server address is 127.0.0.1 server port is what you setup as listening port for the stunnel tunnel in the custom options box input route <server IP address> 255.255.255.255 net_gateway;   where <server IP address> is the same as in point 5 above Now in my experience it'll connect then disconnect, perhaps a few times before finally staying connected.  Just be patient.
  21. Like
    go558a83nk got a reaction from Duckie in Route Plex Remote Outside VPN   ...
    For plex remote access you either need to forward the port through the VPN or you need to setup, in eddie, plex.tv to go outside the VPN tunnel.
  22. Like
    go558a83nk reacted to Staff in Upgrade: Ain becomes a 10 Gbit/s server (SE)   ...
    Hello!

    We're very glad to inform you that a server located in Stockholm (SE) has been upgraded: Ain. Server is now connected to a 10 Gbit/s line and port, while the motherboard has been replaced with a more powerful CPU. IP addresses remain the same. You don't need to re-generate configuration files, even if you don't run our software.

    As usual the server includes load balancing between daemons to squeeze as much bandwidth as possible from the 10 Gbit/s line.

    The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP.

    Just like every other Air server, Ain supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3 and tls-crypt.

    Full IPv6 support is included as well.

    As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.

    You can check the server status as usual in our real time servers monitor:
    https://airvpn.org/servers/Ain

    Do not hesitate to contact us for any information or issue.

    Kind regards and datalove
    AirVPN Team
  23. Like
    go558a83nk reacted to Staff in New 10 Gbit/s server available (CH)   ...
    Hello!

    We're very glad to inform you that a new 10 Gbit/s server located in Zurich (CH) is available: Xuange. It's the first server we propose with a dedicated 10 Gbit/s line and port. As we have now circumvented several computing limits through load balancing and improved optimization, it's time to gradually test larger bandwidth.

    The AirVPN client will show automatically the new server. If you use any other OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator").

    The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP.

    Just like every other Air server, Xuange supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3 and tls-crypt.

    Full IPv6 support is included as well.

    As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.

    You can check the server status as usual in our real time servers monitor:
    https://airvpn.org/servers/Xuange

    Do not hesitate to contact us for any information or issue.

    Kind regards and datalove
    AirVPN Team
  24. Thanks
    go558a83nk reacted to Ariskotos in My POV as a newbie here   ...
    As a long time GNU/Linux enthusiast & evangelist I am very privacy & net neutrality concerned, and care a lot about the software I run.
    Eddie is the very first VPN client I happily run on my Manjaro box.
    Though I still enjoy personally adding & managing VPN configurations thru the Network Connection Manager, I now see why a VPN client might be interesting: Eddie simply works out of the box and does not make a GNU/Linux user feel a 2nd class citizen (eg, network lock feature included by default), & provides detailed info on latency & load.

    What about transparency? Simply astonishing.
    In this world where money is the only religion, transparency is often an abused concept of the past. Not here. When geographic location is not mandatory, I love operating from the currently fastest server available and not overload the others..

    The number of locations seems to be low and the servers number a bit odd, but it works well. A well balanced infrastructure indeed with access points in strategic places all over the world. I love the servers names! As time passes, they become close friends.

    What about sponsorship? The fact that the company cares about some of the most important open source projects & organizations is definitely a plus.

    Not to mention that the community simply looks great.
    Thank you!
  25. Thanks
    go558a83nk reacted to GrandeGiovanni in Is M247 falsifying server locations?   ...
    I have a reason to believe that M247 is falsifying a few of its server locations which it sells to VPN companies such as AirVPN. 
    Disclaimer: I am not accusing AirVPN of participating in this falsification, I believe that AirVPN staff has the integrity and honesty to only purchase servers in locations they know are correct as advertised. My hypothesis is that AirVPN was merely duped into buying thse falsified locations because M247 claimed that they were real locations and AirVPN did not have any reason to suspect anything to the contrary.

    I noticed recently that the M247 "Phoenix" location seems to really be located in Los Angeles, M247 "Barcelona" location seems to really be in Madrid, and the M247 "Berlin" location seems to really be in Frankfurt.

    Traceroute shows identical routes between each of these false locations and the real location they are in, not to mention that neither Phoenix, Barcelona, or Berlin appear on M247's list of locations on their website 

    Disclaimer 2: All of the data below is shown as it was generated, with the only thing being edited is the redaction of my ISP's traceroute hops for protection of my privacy.

    Exhibit A: "Phoenix" is really Los Angeles. 
    Traceroute and ping to Indus , allegedly in M247 Phoenix
    Traceroute to Indus server
    traceroute to indus.airservers.org (193.37.254.26), 30 hops max, 38 byte packets [Redacted my ISP's traceroute hops] 8 * * * 9 ae-5.r01.lsanca20.us.bb.gin.ntt.net (129.250.6.49) 73.593 ms 68.449 ms 69.689 ms 10 ce-0-1-0-0.r01.lsanca20.us.ce.gin.ntt.net (128.241.6.1) 66.818 ms 71.847 ms 72.087 ms 11 * irb-0.agg1.lax1.us.m247.com (77.243.185.149) 89.481 ms et-0-0-49-0.agg1.lax1.us.m247.com (77.243.185.145) 79.797 ms 12 vlan2921.as09.lax1.us.m247.com (193.9.115.167) 123.200 ms 71.520 ms vlan2909.as09.lax1.us.m247.com (193.9.115.169) 74.228 ms 13 * * * 14 * * * Traceroute from Indus to Google traceroute to google.com (172.217.5.110), 30 hops max, 60 byte packets 1 10.32.6.1 (10.32.6.1) 69.597 ms 69.603 ms 69.595 ms 2 vlan177.as09.lax1.us.m247.com (193.37.254.1) 69.687 ms 69.711 ms 69.778 ms 3 irb-0.agg1.lax1.us.m247.com (193.9.115.168) 633.031 ms 633.038 ms 633.034 ms 4 37.120.220.170 (37.120.220.170) 69.490 ms 69.452 ms 69.546 ms 5 72.14.204.180 (72.14.204.180) 69.661 ms te-4-3-0.bb1.lax1.us.m247.com (82.102.29.110) 69.769 ms 69.821 ms 6 10.252.217.158 (10.252.217.158) 69.615 ms 72.14.204.180 (72.14.204.180) 67.888 ms 10.23.211.158 (10.23.211.158) 68.754 ms 7 10.252.234.254 (10.252.234.254) 67.871 ms 142.250.228.74 (142.250.228.74) 68.216 ms 10.252.234.254 (10.252.234.254) 68.221 ms 8 108.170.247.244 (108.170.247.244) 68.254 ms 108.170.237.114 (108.170.237.114) 68.228 ms 108.170.247.244 (108.170.247.244) 68.243 ms 9 108.170.247.211 (108.170.247.211) 68.818 ms 108.170.247.148 (108.170.247.148) 68.598 ms 68.843 ms 10 108.170.230.123 (108.170.230.123) 68.806 ms 108.170.230.133 (108.170.230.133) 69.010 ms 172.253.75.217 (172.253.75.217) 76.905 ms 11 172.253.75.217 (172.253.75.217) 76.921 ms 172.253.70.153 (172.253.70.153) 80.406 ms 74.125.253.148 (74.125.253.148) 75.588 ms 12 142.250.234.59 (142.250.234.59) 81.965 ms 108.170.243.1 (108.170.243.1) 78.518 ms 80.377 ms 13 108.170.236.61 (108.170.236.61) 75.650 ms 75.356 ms 108.170.243.1 (108.170.243.1) 77.960 ms 14 sfo03s07-in-f14.1e100.net (172.217.5.110) 82.906 ms 108.170.236.63 (108.170.236.63) 77.106 ms sfo03s07-in-f110.1e100.net (172.217.5.110) 103.936 ms Ping to Indus PING 193.37.254.26 (193.37.254.26) 56(84) bytes of data. 64 bytes from 193.37.254.26: icmp_seq=1 ttl=57 time=69.5 ms 64 bytes from 193.37.254.26: icmp_seq=2 ttl=57 time=68.8 ms 64 bytes from 193.37.254.26: icmp_seq=3 ttl=57 time=69.1 ms 64 bytes from 193.37.254.26: icmp_seq=4 ttl=57 time=68.0 ms 64 bytes from 193.37.254.26: icmp_seq=5 ttl=57 time=69.3 ms 64 bytes from 193.37.254.26: icmp_seq=6 ttl=57 time=68.5 ms 64 bytes from 193.37.254.26: icmp_seq=7 ttl=57 time=70.0 ms 64 bytes from 193.37.254.26: icmp_seq=8 ttl=57 time=69.2 ms 64 bytes from 193.37.254.26: icmp_seq=9 ttl=57 time=69.7 ms 64 bytes from 193.37.254.26: icmp_seq=10 ttl=57 time=68.1 ms Hmm, I wonder why all the M247 router hops are all labelled as "LAX1" for a "Phoenix" location???

    Now we will compare this to Groombridge, a server in M247 Los Angeles

    Traceroute to Groombridge traceroute to groombridge.airservers.org (37.120.132.82), 30 hops max, 38 byte packets [Redacted my ISP's traceroute hops] 7 * * * 8 ae-2.r25.lsanca07.us.bb.gin.ntt.net (129.250.3.189) 74.561 ms 97.764 ms * 9 ae-5.r01.lsanca20.us.bb.gin.ntt.net (129.250.6.49) 73.048 ms 70.967 ms 73.707 ms 10 ce-0-1-0-0.r01.lsanca20.us.ce.gin.ntt.net (128.241.6.1) 65.112 ms 73.968 ms 71.939 ms 11 irb-0.agg1.lax1.us.m247.com (77.243.185.149) 77.359 ms * * 12 vlan2926.as15.lax1.us.m247.com (89.44.212.37) 75.003 ms 73.769 ms 217.138.223.35 (217.138.223.35) 67.763 ms 13 * * * 14 * * *

    Traceroute from Groombridge to YouTube traceroute to youtube.com (216.58.195.78), 30 hops max, 60 byte packets 1 10.15.134.1 (10.15.134.1) 71.514 ms 71.502 ms 71.493 ms 2 vlan170.as15.lax1.us.m247.com (37.120.132.81) 71.810 ms 71.986 ms 72.005 ms 3 * * * 4 37.120.220.198 (37.120.220.198) 75.969 ms te-1-2-0.bb1.nyc1.us.m247.com (77.243.185.18) 76.140 ms 37.120.220.198 (37.120.220.198) 75.971 ms 5 72.14.204.180 (72.14.204.180) 76.149 ms 76.154 ms te-4-3-0.bb1.lax1.us.m247.com (82.102.29.110) 75.138 ms 6 10.252.173.62 (10.252.173.62) 78.254 ms 72.14.204.180 (72.14.204.180) 73.797 ms 73.781 ms 7 209.85.254.86 (209.85.254.86) 73.773 ms 10.252.50.62 (10.252.50.62) 73.975 ms 108.170.247.193 (108.170.247.193) 74.551 ms 8 108.170.237.114 (108.170.237.114) 73.937 ms 108.170.247.193 (108.170.247.193) 74.759 ms 108.170.247.243 (108.170.247.243) 74.214 ms 9 * 108.170.247.244 (108.170.247.244) 74.196 ms 108.170.234.124 (108.170.234.124) 74.648 ms 10 209.85.254.229 (209.85.254.229) 86.701 ms * 108.170.234.27 (108.170.234.27) 72.588 ms 11 216.239.58.214 (216.239.58.214) 80.460 ms 142.250.234.56 (142.250.234.56) 81.648 ms 172.253.70.155 (172.253.70.155) 83.700 ms 12 108.170.242.241 (108.170.242.241) 80.580 ms 66.249.94.28 (66.249.94.28) 79.787 ms 108.170.242.241 (108.170.242.241) 81.349 ms 13 72.14.239.97 (72.14.239.97) 80.326 ms 108.170.242.241 (108.170.242.241) 81.308 ms 72.14.239.43 (72.14.239.43) 84.462 ms 14 72.14.239.43 (72.14.239.43) 82.598 ms sfo07s16-in-f78.1e100.net (216.58.195.78) 80.463 ms 81.950 ms

    Ping to Groombridge PING groombridge.airservers.org (37.120.132.82) 56(84) bytes of data. 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=1 ttl=57 time=68.8 ms 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=2 ttl=57 time=68.8 ms 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=3 ttl=57 time=68.9 ms 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=4 ttl=57 time=68.0 ms 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=5 ttl=57 time=70.4 ms 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=6 ttl=57 time=69.0 ms 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=7 ttl=57 time=70.4 ms 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=8 ttl=57 time=67.6 ms 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=9 ttl=57 time=68.3 ms 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=10 ttl=57 time=68.0 ms Hmm, looks suspiciously similar to me... Routes are both the same, ping is near-equal

    Exhibit B: "Barcelona" is really Madrid
    Traceroute and ping to Eridanus, allegedly in Barcelona
    Traceroute to Eridanus traceroute to eridanus.airservers.org (185.183.106.2), 30 hops max, 38 byte packets [Redacted my ISP's traceroute hops] 7 * * * 8 be2332.ccr32.bio02.atlas.cogentco.com (154.54.85.246) 83.833 ms 82.655 ms 83.244 ms 9 be2325.ccr32.mad05.atlas.cogentco.com (154.54.61.134) 86.389 ms 85.839 ms 86.422 ms 10 quantum-sistemas.demarc.cogentco.com (149.6.150.130) 110.559 ms 171.268 ms 118.386 ms 11 * * * 12 * * *
    Traceroute from Eridanus to YouTube traceroute to youtube.com (216.58.211.46), 30 hops max, 60 byte packets 1 10.16.134.1 (10.16.134.1) 89.066 ms 89.077 ms 89.072 ms 2 * * * 3 xe-1-2-3-0.bb1.mad1.es.m247.com (212.103.51.62) 89.002 ms 88.997 ms 88.992 ms 4 mad-b1-link.telia.net (213.248.95.33) 89.157 ms 89.176 ms 89.172 ms 5 google-ic-314668-mad-b1.c.telia.net (62.115.61.14) 89.168 ms 89.324 ms 89.328 ms 6 * * * 7 142.250.239.26 (142.250.239.26) 92.637 ms 72.14.233.124 (72.14.233.124) 91.657 ms 142.250.62.202 (142.250.62.202) 91.548 ms 8 108.170.234.221 (108.170.234.221) 92.059 ms 74.125.242.178 (74.125.242.178) 91.787 ms 144.397 ms 9 108.170.253.225 (108.170.253.225) 91.930 ms muc03s14-in-f14.1e100.net (216.58.211.46) 91.631 ms 108.170.253.225 (108.170.253.225) 91.934 ms Hmm, I wonder why M247's router hops in the "Barcelona" location are all labelled as "MAD1"

    Ping to Eridanus PING 185.183.106.2 (185.183.106.2) 56(84) bytes of data. 64 bytes from 185.183.106.2: icmp_seq=1 ttl=56 time=89.4 ms 64 bytes from 185.183.106.2: icmp_seq=2 ttl=56 time=85.9 ms 64 bytes from 185.183.106.2: icmp_seq=3 ttl=56 time=84.9 ms 64 bytes from 185.183.106.2: icmp_seq=4 ttl=56 time=85.5 ms 64 bytes from 185.183.106.2: icmp_seq=5 ttl=56 time=86.4 ms 64 bytes from 185.183.106.2: icmp_seq=6 ttl=56 time=85.0 ms 64 bytes from 185.183.106.2: icmp_seq=7 ttl=56 time=85.3 ms 64 bytes from 185.183.106.2: icmp_seq=8 ttl=56 time=87.1 ms 64 bytes from 185.183.106.2: icmp_seq=9 ttl=56 time=85.8 ms 64 bytes from 185.183.106.2: icmp_seq=10 ttl=56 time=85.3 ms
    Comparing this to Mekbuda, a server in Madrid M247

    Traceroute to Mekbuda [Redacted my ISP's traceroute hops] 7 * * * 8 be2332.ccr32.bio02.atlas.cogentco.com (154.54.85.246) 83.761 ms 82.333 ms 82.102 ms 9 be2325.ccr32.mad05.atlas.cogentco.com (154.54.61.134) 86.121 ms 85.032 ms 86.308 ms 10 quantum-sistemas.demarc.cogentco.com (149.6.150.130) 94.879 ms 87.337 ms 88.230 ms 11 * * * 12 * * *


    Route from Mekbuda to Youtube traceroute to youtube.com (216.58.215.142), 30 hops max, 60 byte packets 1 10.21.198.1 (10.21.198.1) 87.692 ms 87.693 ms 87.686 ms 2 vlan29.bb2.mad1.es.m247.com (185.93.182.161) 87.696 ms 87.690 ms 87.750 ms 3 xe-1-1-0-0.bb1.mad1.es.m247.com (82.102.29.25) 87.762 ms 87.758 ms 87.753 ms 4 mad-b1-link.telia.net (213.248.95.33) 87.956 ms 88.558 ms 87.931 ms 5 google-ic-314668-mad-b1.c.telia.net (62.115.61.14) 87.836 ms 87.992 ms 87.988 ms 6 * * * 7 mad41s04-in-f14.1e100.net (216.58.215.142) 86.846 ms 74.125.242.177 (74.125.242.177) 98.934 ms 98.992 ms

    Ping to Mekbuda PING mekbuda.airservers.org (185.93.182.170) 56(84) bytes of data. 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=1 ttl=56 time=87.0 ms 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=2 ttl=56 time=88.4 ms 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=3 ttl=56 time=86.2 ms 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=4 ttl=56 time=88.4 ms 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=5 ttl=56 time=86.7 ms 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=6 ttl=56 time=85.7 ms 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=7 ttl=56 time=85.7 ms 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=8 ttl=56 time=87.1 ms 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=9 ttl=56 time=88.3 ms 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=10 ttl=56 time=88.2 ms Once again, everything is near-identical, with only a slight difference in Youtube traceroute.


    Exhibit C: "Berlin" is really in Frankfurt

    First we will test ping and traceroute to Cujam, a Berlin M247 server

    Traceroute to Cujam
      [Redacted my ISP's traceroute hops] 6 * * * 7 ae-9.r20.londen12.uk.bb.gin.ntt.net (129.250.6.146) 73.904 ms ae-11.r20.parsfr04.fr.bb.gin.ntt.net (129.250.4.195) 78.812 ms 75.580 ms 8 ae-1.r21.londen12.uk.bb.gin.ntt.net (129.250.2.183) 79.099 ms ae-2.r21.parsfr04.fr.bb.gin.ntt.net (129.250.3.46) 85.715 ms ae-1.r21.londen12.uk.bb.gin.ntt.net (129.250.2.183) 78.384 ms 9 ae-16.r20.frnkge13.de.bb.gin.ntt.net (129.250.3.13) 91.553 ms ae-11.r21.frnkge13.de.bb.gin.ntt.net (129.250.5.26) 91.521 ms ae-16.r20.frnkge13.de.bb.gin.ntt.net (129.250.3.13) 94.728 ms 10 ae-0.a00.frnkge13.de.bb.gin.ntt.net (129.250.2.25) 92.855 ms 89.619 ms 90.740 ms 11 ae-8-501.a00.frnkge13.de.ce.gin.ntt.net (213.198.52.62) 91.869 ms 92.824 ms 93.136 ms 12 37.120.220.131 (37.120.220.131) 90.856 ms vlan2945.agg2.fra4.de.m247.com (193.27.15.241) 92.015 ms 37.120.220.116 (37.120.220.116) 89.007 ms 13 vlan2925.as03.fra4.de.m247.com (83.97.21.17) 88.304 ms vlan2901.as03.fra4.de.m247.com (82.102.29.155) 93.828 ms vlan2925.as03.fra4.de.m247.com (83.97.21.17) 89.713 ms 14 * * * 15 * * *
    Traceroute from Cujam to YouTube 1 10.11.102.1 (10.11.102.1) 89.968 ms 89.978 ms 89.972 ms 2 37.120.217.241 (37.120.217.241) 90.041 ms 90.036 ms 90.134 ms 3 vlan2925.agg2.fra4.de.m247.com (83.97.21.16) 89.915 ms 89.910 ms 89.905 ms 4 37.120.220.130 (37.120.220.130) 90.078 ms 193.27.15.240 (193.27.15.240) 89.956 ms 37.120.220.130 (37.120.220.130) 90.199 ms 5 vlan2906.bb1.ams1.nl.m247.com (37.120.128.248) 90.252 ms 90.009 ms 37.120.128.253 (37.120.128.253) 90.176 ms 6 37.120.128.253 (37.120.128.253) 90.171 ms no-mans-land.m247.com (185.206.226.71) 89.888 ms 37.120.128.253 (37.120.128.253) 89.597 ms 7 no-mans-land.m247.com (185.206.226.71) 89.851 ms 10.252.43.30 (10.252.43.30) 89.962 ms 10.252.45.126 (10.252.45.126) 89.649 ms 8 108.170.252.1 (108.170.252.1) 90.496 ms 108.170.235.248 (108.170.235.248) 89.578 ms 10.252.73.190 (10.252.73.190) 89.598 ms 9 108.170.252.83 (108.170.252.83) 90.067 ms 108.170.252.18 (108.170.252.18) 90.020 ms 108.170.252.65 (108.170.252.65) 90.430 ms 10 * * 209.85.252.77 (209.85.252.77) 90.872 ms 11 216.239.50.187 (216.239.50.187) 99.430 ms * 209.85.252.149 (209.85.252.149) 97.794 ms 12 108.170.230.210 (108.170.230.210) 98.329 ms 72.14.238.52 (72.14.238.52) 97.997 ms 97.910 ms 13 108.170.244.161 (108.170.244.161) 97.921 ms 108.170.235.98 (108.170.235.98) 98.316 ms 108.170.244.225 (108.170.244.225) 98.802 ms 14 108.170.232.125 (108.170.232.125) 97.839 ms 98.060 ms 98.173 ms 15 108.170.234.51 (108.170.234.51) 98.067 ms par10s27-in-f206.1e100.net (216.58.198.206) 97.811 ms 98.150 ms

    Ping to Cujam PING cujam.airservers.org (37.120.217.242) 56(84) bytes of data. 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=1 ttl=53 time=90.3 ms 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=2 ttl=53 time=91.8 ms 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=3 ttl=53 time=91.7 ms 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=4 ttl=53 time=92.5 ms 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=5 ttl=53 time=91.3 ms 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=6 ttl=53 time=92.1 ms 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=7 ttl=53 time=90.5 ms 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=8 ttl=53 time=91.3 ms 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=9 ttl=53 time=90.0 ms 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=10 ttl=53 time=92.1 ms I wonder why there's no mention of "Berlin" in the traceroute hops, instead says FRA4 for Frankfurt....

    Next we will compare this to Mirfak, a M247 Frankfurt server

    Traceroute to Mirfak [Redacted my ISP's traceroute hops] 5 * * * 6 if-ae-66-8.tcore1.l78-london.as6453.net (80.231.130.194) 93.049 ms if-ae-66-9.tcore1.l78-london.as6453.net (80.231.130.21) 92.427 ms if-ae-66-8.tcore1.l78-london.as6453.net (80.231.130.194) 92.662 ms 7 * if-ae-3-2.tcore1.pye-paris.as6453.net (80.231.154.142) 94.296 ms * 8 * * if-ae-11-2.tcore1.pvu-paris.as6453.net (80.231.153.49) 92.280 ms 9 * if-ae-49-2.tcore2.pvu-paris.as6453.net (80.231.153.21) 91.508 ms * 10 if-ae-55-2.tcore1.fr0-frankfurt.as6453.net (80.231.245.7) 100.752 ms 91.321 ms 92.308 ms 11 if-ae-55-2.tcore1.fr0-frankfurt.as6453.net (80.231.245.7) 88.325 ms 195.219.50.23 (195.219.50.23) 96.137 ms 94.877 ms 12 vlan2946.agg1.fra4.de.m247.com (193.27.15.243) 94.155 ms 37.120.220.116 (37.120.220.116) 93.367 ms 37.120.220.118 (37.120.220.118) 91.790 ms 13 vlan2917.as11.fra4.de.m247.com (212.103.51.191) 101.641 ms vlan2945.agg2.fra4.de.m247.com (193.27.15.241) 90.441 ms vlan2917.as11.fra4.de.m247.com (212.103.51.191) 93.836 ms 14 * vlan2917.as11.fra4.de.m247.com (212.103.51.191) 94.359 ms vlan2919.as11.fra4.de.m247.com (212.103.51.151) 96.080 ms 15 * * * 16 * * * The only difference in this traceroute is that the traffic goes through TATA instead of NTT which the Cujam server goes through, but the destination for both is the same: M247 in Frankfurt

    Traceroute to YouTube from Mirfak traceroute to youtube.com (172.217.17.46), 30 hops max, 60 byte packets 1 10.27.230.1 (10.27.230.1) 96.778 ms 96.764 ms 96.774 ms 2 vlan27.as11.fra4.de.m247.com (141.98.102.177) 97.067 ms 97.135 ms 97.329 ms 3 vlan2917.agg1.fra4.de.m247.com (212.103.51.190) 96.705 ms 96.704 ms 96.699 ms 4 37.120.128.148 (37.120.128.148) 97.120 ms 193.27.15.242 (193.27.15.242) 97.724 ms 37.120.128.148 (37.120.128.148) 97.107 ms 5 37.120.128.253 (37.120.128.253) 96.833 ms 96.835 ms vlan2906.bb1.ams1.nl.m247.com (37.120.128.248) 96.894 ms 6 no-mans-land.m247.com (185.206.226.71) 97.037 ms 37.120.128.253 (37.120.128.253) 95.349 ms 95.494 ms 7 no-mans-land.m247.com (185.206.226.71) 95.615 ms 10.252.45.190 (10.252.45.190) 98.342 ms 10.252.45.158 (10.252.45.158) 96.818 ms 8 216.239.47.244 (216.239.47.244) 96.897 ms 108.170.252.65 (108.170.252.65) 97.534 ms 142.250.46.244 (142.250.46.244) 96.712 ms 9 108.170.252.18 (108.170.252.18) 97.041 ms 108.170.251.144 (108.170.251.144) 97.279 ms 108.170.252.18 (108.170.252.18) 96.977 ms 10 * * * 11 209.85.244.158 (209.85.244.158) 104.649 ms * * 12 216.239.42.171 (216.239.42.171) 104.672 ms 216.239.42.102 (216.239.42.102) 116.455 ms 216.239.43.37 (216.239.43.37) 104.324 ms 13 216.239.42.171 (216.239.42.171) 104.748 ms 104.733 ms 216.239.43.37 (216.239.43.37) 115.898 ms 14 108.170.236.135 (108.170.236.135) 104.245 ms 104.183 ms 108.170.236.137 (108.170.236.137) 104.074 ms 15 ams16s29-in-f46.1e100.net (172.217.17.46) 103.791 ms 103.813 ms 102.372 ms


    Ping to Mirfak PING mirfak.airservers.org (141.98.102.234) 56(84) bytes of data. 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=1 ttl=53 time=89.3 ms 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=2 ttl=53 time=89.8 ms 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=3 ttl=53 time=89.1 ms 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=4 ttl=53 time=90.6 ms 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=5 ttl=53 time=89.6 ms 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=6 ttl=53 time=89.2 ms 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=7 ttl=53 time=90.0 ms 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=8 ttl=53 time=90.0 ms 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=9 ttl=53 time=87.6 ms 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=10 ttl=53 time=88.9 ms Again, everything is near-identical, suggesting that these Berlin, Phoenix, and Barcelona locations are just falsified geolocation information and nothing more.  With near-identical traceroutes, and ping values that don't differ by more than 1-2ms , it is extremely unrealistic that these servers are in the locations they claim to be.

    If you think my data is wrong/inaccurate, then feel free to repeat my experiment yourself, you will find the same thing.

    I would like to reiterate that I believe that AirVPN has no part in this falsification and that they have no ill will, I think they were duped/deceived by M247 to believe that the Phoenix, Berlin and Barcelona locations are actually real physical locations M247 has their servers located in. I think after these findings, AirVPN should have a long discussion with M247 staff about this falsification that took place.
×
×
  • Create New...