Inconsistent country ID behaviour since updating Eddie

[Sharrow 3]

Hi

Apologies if this has come up before.

I am on Win7Pro (yeah i know) and I use Firefox. I updated to Eddie 2.18.9 a week or two back and ever since then I seem to have developed a gremlin or two. No issues with updated Eddie logging into any Dutch AirVPN server which has been my specific mo for years now,

The problem shows up when I go to dnsleaktest.com where my IP (213.152.162.165) corresponds to the correct Dutch AirVPN server as displayed on the Eddie overview page, HOWEVER, the country is listed as from, the United Kingdom (where I am actually located in real life).

Furthermore, when I go to Google it now selects google.co.uk when before updating Eddie it would normally show me the Dutch google page?

ipleak.net shows me my IP as 213.152.162.165 and that its located in The Netherlands so all good, right? FYI it also states that IPv6 test not reachable. (timeout)

So somethings up here as I am seemingly correctly connected to a Dutch AirVPN server but both dnsleaktest.com and Google see me as still being in the UK

Anyone have any ideas whats going on here?

Thanks for your time!

[Flx 76]

17 minutes ago, Sharrow said:

So somethings up here as I am seemingly correctly connected to a Dutch AirVPN server but both dnsleaktest.com and Google see me as still being in the UK

This problem was reported last week or so--->>>https://airvpn.org/forums/topic/46908-nl-servers-showing-as-being-in-the-uk/

[Sharrow 3]

Hi

Thanks for your response and my apologies for taking so long to reply back.

So its a month now since my original post and when logged into any Dutch AirVPN server - I'm on Alzirr right now:

- www.dnsleaktest.com is still showing me as being in the UK! IP shown is 109.202.107.15 which is the same as my Public Exit IP in Eddie
- www.speedtest.net defaults to a London based server (same as the other post you linked to)
- ipleak.net shows me as being in the Netherlands but this is an AIrVPN run site right?

As mentioned before I am actually located in the UK which makes this issue too much of a coincidence for me.

To quote giganerd from the post you linked to "That happens from time to time. IP geolocation is often quite coarse."

I have been using AirVPN for years now and this has never happened to me before. And it is still happening 30 days later. And it all started when I installed Eddie 2.18.9 that I almost certain about.

Could a staff member comment please?

Thanks again for your time!


 

[OpenSourcerer 1442]

You omitted the server names you noticed this on, so others can't get a chance at reproducing it. Because, you know, there are 67 servers in NL and hitting the one or two you might have experienced it on when using the country DNS name is a gamble.
 

3 hours ago, Sharrow said:

To quote giganerd from the post you linked to "That happens from time to time. IP geolocation is often quite coarse."

And I mean it. But to be fair, 30 days is a bit much for a geolocation provider to not notice a wrong info, so I'll happily check if I can reproduce it as well.

[Sharrow 3]

Hi giganerd

Thanks for your reply.

I did mention the name of the Dutch AirVPN server I am currently on: Alzirr

I have noticed this same issue on other Dutch AirVPN servers too.

[OpenSourcerer 1442]

Oh, right.
Will check Alzirr tomorrow.

[Sharrow 3]

Hi. Some more examples from a moment ago to help nail this issue down. Global Layer B.V. is the one constant here?

 

[OpenSourcerer 1442]

I forgot to actively check it today, I'm sorry. But one of the other non-AirVPN APIs (here, ip-api.com) is returning the correct info. So as of now, without looking deeper into the case, I'm inclined to stand by my previous statement about obsolete geolocation database entries. But I will try to remember to actively check it tomorrow.

$ ip-api 213.152.162.114
{
  "status"       : "success",
  "continent"    : "Europe",
  "continentCode": "EU",
  "country"      : "Netherlands",
  "countryCode"  : "NL",
  "region"       : "NH",
  "regionName"   : "North Holland",
  "city"         : "Amsterdam",
  "district"     : "",
  "zip"          : "1109",
  "lat"          : 52.374,
  "lon"          : 4.88969,
  "timezone"     : "Europe/Amsterdam",
  "offset"       : 7200,
  "currency"     : "EUR",
  "isp"          : "Global Layer network",
  "org"          : "",
  "as"           : "AS49453 Global Layer B.V.",
  "asname"       : "GLOBALLAYER",
  "mobile"       : false,
  "proxy"        : true,
  "hosting"      : true,
  "query"        : "213.152.162.114"
}

.

[vlad ip-api 0]

16 hours ago, giganerd said:

But one of the other non-AirVPN APIs (here, ip-api.com)

Slightly offtopic, ip-api.com now returns the correct location for all airvpn servers.

[OpenSourcerer 1442]

I've done some checks with Alzirr and Sheliak. Some APIs really seem to suggest it's in London, some others say it's in Amsterdam. Whatever PIA and Ookla are using, they really seem to be outdated.
You see, this is a traceroute from my location:

$ sudo traceroute -T alzirr.airvpn.org
traceroute to alzirr.airvpn.org (109.202.107.14), 30 hops max, 60 byte packets
 1  Router hop
 2  ISP hop
 3  217.5.116.90 (217.5.116.90)  11.546 ms  11.621 ms  11.633 ms
 4  80.156.162.158 (80.156.162.158)  16.372 ms  16.412 ms  16.433 ms
 5  ae5-2074.ams10.core-backbone.com (81.95.2.138)  16.907 ms  17.153 ms  17.166 ms
 6  core-backbone.global-layer.com (5.56.20.22)  27.830 ms  25.929 ms  25.593 ms
 7  185.23.212.5 (185.23.212.5)  29.237 ms  29.209 ms  29.201 ms
 8  * * *
 9  14.107.202.109.in-addr.arpa (109.202.107.14)  27.689 ms  28.103 ms  28.000 ms

Hop 6 is in Bavaria (Germany) according to all the APIs quoted here, and hop 7 is in Amsterdam, also according to all APIs quoted here. For hop 9 to be in the UK, which is the destination, hop 8 must be doing a slight bit of dark sorcery there to suddenly jump from Amsterdam right into a server in a datacenter in London without any more routers in between. For 8 to be in the UK, I'd expect at least one other router after it as part of an internal transfer network or so. But there's only one hop incognito, and right after it we've got the dedicated v4 of our destination server. And since hop 7 was already in Amsterdam, I'd say 8 is some router serving as an internal transfer router in a datacenter in Amsterdam. This allows the conclusion that 9 is definitely in Amsterdam as well.

[Staff 10018]

@giganerd

Yes, NL servers in Alblasserdam (i.e all of them) are connected to AMS-IX with 40 Gbit/s. The IANA database (for the readers: this is the only database that counts because https://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority) is also correct, entries of NL servers IP addresses show the Netherlands, without changes since 2016 (so there is apparently no explanation for such gross errors in poorly maintained databases? puzzling). If you find errors in whois please warn us.

Example:

$ whois 109.202.107.14
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

refer:        whois.ripe.net

inetnum:      109.0.0.0 - 109.255.255.255
organisation: RIPE NCC
status:       ALLOCATED

whois:        whois.ripe.net

changed:      2009-01
source:       IANA

# whois.ripe.net

inetnum:        109.202.104.0 - 109.202.107.255
netname:        GLOBALLAYER
descr:          Global Layer network
country:        NL
admin-c:        GL6540-RIPE
tech-c:         GL6540-RIPE
remarks:        INFRA-AW
status:         ASSIGNED PA
mnt-by:         GLOBALLAYER
created:        2013-04-08T16:29:12Z
last-modified:  2016-03-29T20:47:41Z
source:         RIPE

person:         Global Layer
address:        Postbus 190
address:        2950AD Alblasserdam
address:        Netherlands
phone:          +31 78 20 20 228
nic-hdl:        GL6540-RIPE
mnt-by:         GLOBALLAYER
created:        2011-08-04T20:36:25Z
last-modified:  2017-10-30T22:14:45Z
source:         RIPE

% Information related to '109.202.107.0/24AS49453'

route:          109.202.107.0/24
descr:          Global Layer network
origin:         AS49453
mnt-by:         GLOBALLAYER
created:        2016-03-17T11:39:02Z
last-modified:  2016-03-17T11:39:02Z
source:         RIPE

% This query was served by the RIPE Database Query Service version 1.97.2 (HEREFORD)

Kind regards
 

[OpenSourcerer 1442]

I'm probably not going to WHOIS/RDAP every single server of yours now. But I shall warn you if I ever get bored so much that I actually do.
Frankly, WHOIS/RDAP is just another test you can perform to have a better idea whether a server really is in an advertised location. I'd do a combination of different things to verify a server's location, including but not limited to the mentioned RDAP, traceroute, BGP analysis, latency tests, comparison with other hosts in similar IP ranges and IP-API requests. In this case, only a handful of IP-APIs showed UK (while others, not to write: the more reliable, showed NL), and traceroute hinted at NL in the last few hops, so incognito hop 8 is almost surely not in the UK, making the destination almost surely not UK, either. Plus, the BGP prefix is Dutch, the company bears a Dutch VAT ID, etcetcetc.
 

2 hours ago, Staff said:

so there is apparently no explanation for such gross errors in poorly maintained databases? puzzling

I'm almost certain all those services use one or two of the biggest geolocation API providers and all of them happen to struggle with database updates. Actually, it wouldn't be a surprise if they all used the same and that particular one can't get its shit together. Wouldn't be the first time, either…