Nihal server after 2 Months still Portuguese instead of Spanish

[doveoriginal 9]

Dear Staff,

 

After multiple people, including me, already mentioned in this thread - https://airvpn.org/topic/11908-new-1-gbits-server-available-nihal-es/ - whenever we connect to the Nihal server, ANY service (in my case TV and Pay-TV, which very annoyingly does not work with your "Spanish" server) recognises Nihal as being in Lisbon, Portugal. Furthermore it is supposedly registered to a portuguese name, too. 

 

If I understood you guys right, the server actually is in Spain, but that does not change anything for us users, as every "normal" ip-checking website locates the server in Portugal. So the server actually being in Spain, but showing itself as Portuguese to basically every website I was testing, does not help at all. It is rather unpleasant that internet-based Spanish Pay TV contents are not possible to access with AirVPN. The old spanish servers, albeit supposedly much slower, worked perfectly in that respect. 

 

As we didn't get any additional and/or problem-solving replies in the above attached thread, I would appreciate it very highly if you could help us out with this and fix that problem.

 

Having said all that, I want to emphasize that I absolutely love AirVPN and what you guys offer. I think it is amazing and you have all my respect for the way you are running AirVPN. The above problem is the only drop of bitterness I am experiencing.

 

Cheers

 

[Staff 9973]

Hello!

 

You can verify that in the RIPE database all the Nihal IP addresses are correctly geo-located in Spain:

https://apps.db.ripe.net/search/geolocation-finder.html

 

RIPE NCC is one of the five world RIRs (for Europe, Middle East and some Asia regions) so everything is fine. We can't follow all the hundreds, or maybe thousands, of geo-location IP addresses databases that contain errors. Unfortunately maintaining such a database in good order is a hard task, and it is not uncommon that maintainers are unable to fulfill this task.

 

Kind regards

[doveoriginal 9]

Dear Staff,

 

Thank you for your quick reply.

 

I am aware of the RIPE database showing the Nihal IP addresses as in Spain, but I repeat, for us users this doesn't change anything for the better. Every single database (at least every database I checked when googling all kinds of ip-checking websites) shows otherwise. Even "ipleak.net", developed and powered by AirVPN (if the information on the bottom of the page is correct) shows Nihal as Portuguese. 

 

In the end users who rely on Spanish servers - and that includes me - will need to pay for another VPN service to be able to enjoy Spanish TV (& Pay TV as in my case).

I would prefer to give that money to AirVPN in the form of a new or additional subscription and not give it to some other, inferior, service.

 

So in terms of RIPE database geo-location you are perfectly right. When it comes to the customer experience, though, only the result counts. And there the fact remains thatwe can't use the Spanish server for sites which require Spanish IP, because basically any site, including ipleak.net, recognizes it as Portuguese.

 

I really hope you guys can find a solution. I am delighted with AirVPN and I would prefer to support you and to pay for your services before other services any day.

 

Kind regards

[Staff 9973]

database (at least every database I checked when googling all kinds of ip-checking websites) shows otherwise. Even "ipleak.net", developed and powered by AirVPN (if the information on the bottom of the page is correct) shows Nihal as Portuguese. 

 

Hello!

 

ipleak.net queries commercial MaxMind database (and we pay for it), which is wrong as well. We'll think about your suggestions and a solution!

 

Kind regards

[doveoriginal 9]

Thank you very much, that is very nice to hear!

 

Kind regards

[Zaroad 26]

We can complain here ->> https://www.maxmind.com/en/correction

[OpenSourcerer 1435]

We do not accept requests to change anonymous proxy or VPN IP addresses.

 

You better don't mention it's a VPN server's IP address..

[doveoriginal 9]

Almost a year has passed and I still can't use the Spanish servers to circumvate geoblocking. We went from having multiple Spanish servers, which were all working fine, to having one Spanish server, which is not being recognized as Spanish. Even if it actually is Spanish, it doesn't give us any value and is of no use when it's recognized as Portuguese. Very disappointing, AirVPN! 

 

Edit 02:04 PM: I have just seen and immediately tried the new Spanish server located in Valencia. It does show as Spanish, which is great (!!!!!), it is extremely slow for me, though. Tried with various protocols and checked against servers located in other countries and only the new Spanish server was that slow. Anyone else got that problem? Problems with Nihal still persist as of now. If the new Spanish one turns out to work properly, I will still be very happy, so thanks for that.

[Staff 9973]

Almost a year has passed and I still can't use the Spanish servers to circumvate geoblocking. We went from having multiple Spanish servers, which were all working fine, to having one Spanish server, which is not being recognized as Spanish. Even if it actually is Spanish, it doesn't give us any value and is of no use when it's recognized as Portuguese. Very disappointing, AirVPN! 

 

 

Hello!

 

Frankly we fail to understand the reasons of such a message.

 

There are two Spanish servers and IP addresses of both are correctly geo-located in Spain by RIPE. They both have 1 Gbit/s uplink port and line. It makes no sense to have additional servers in Spain. They are normally used by less than 35 customers at any given time, and the required bandwidth is a tiny fraction of the total 2 Gbit/s available. For most time of the day Spain servers clients require less then 20 Mbit/s IN TOTAL. Therefore infrastructure in Spain is massively over-sized and there is absolutely no reason at the moment to enlarge it.

 

Please click "Status" from our web site upper menu as usual for additional information. Click on a server name to see specific stats and additional data pertaining to that server.

 

Kind regards

[Zaroad 26]

 

Almost a year has passed and I still can't use the Spanish servers to circumvate geoblocking. We went from having multiple Spanish servers, which were all working fine, to having one Spanish server, which is not being recognized as Spanish. Even if it actually is Spanish, it doesn't give us any value and is of no use when it's recognized as Portuguese. Very disappointing, AirVPN!

 

Hello!

 

Frankly we fail to understand the reasons of such a message.

 

There are two Spanish servers and IP addresses of both are correctly geo-located in Spain by RIPE. They both have 1 Gbit/s uplink port and line. It makes no sense to have additional servers in Spain. They are normally used by less than 35 customers at any given time, and the required bandwidth is a tiny fraction of the total 2 Gbit/s available. For most time of the day Spain servers clients require less then 20 Mbit/s IN TOTAL. Therefore infrastructure in Spain is massively over-sized and there is absolutely no reason at the moment to enlarge it.

 

Please click "Status" from our web site upper menu as usual for additional information. Click on a server name to see specific stats and additional data pertaining to that server.

 

Kind regards

Yes but RTVE, Movistar TV, Mediaset and other services uses Maxmind DB

[OpenSourcerer 1435]

Just my 222 cents.

• bgp.he.net says Bitcanal is in a portuguese IP range.
• IP-API shows it in Silveira, PT.
• YouTube is unsure, shows the worldwide side.
• Bitcanal.pt and bitcanal.es both exist.
• There are two WHOIS versions.

What I don't understand, is this sentence:

 

Frankly we fail to understand the reasons of such a message.

 

Explanation: Your customers cannot view spanish TV because the GeoIP service used by the TV provider locates Nihal in Portugal. Although you are right that one of the WHOIS versions is showing the IP as a spanish one you can't change the fact they are located in PT - because many GeoIP providers are doing so. Quite stunning you don't understand that.. no offense, though.

 

It's the same as if I wanted to view ZDF or ARD Mediathek in Germany (geo-restricted services) and my IP would be located by all GeoIP providers in the Netherlands (fortunately, not the case). I therefore can't view them because ARD/ZDF locate me in NL. Not your fault, really, but in that case the situation for me, the customer, is:

I can't use one of your VPN servers to view ARD/ZDF anymore. The situation gets worse the more servers in a country are affected by this.

I understand all the ones who suffer from this. One solution could be to correct the underlying GeoIP data. If we don't know what data such services use, another idea is to just look for another datacenter with correct GeoIP results.

[Staff 9973]

Hello giganerd!

 

 

Explanation: Your customers cannot view spanish TV ...

 

 

As we already wrote to the previous user, if the problem were with Nihal, we added a 2nd server in Spain well before his/her message, so this part of your new message is even more insensate.

 

 

There are two WHOIS versions. ... ... If we don't know what data such services use, another idea is to just look for another datacenter with correct GeoIP results.

 

 

That's a terribly wrong approach for VPN servers, but it can be acceptable for closed servers only with "micro" routing purposes. However, we did not find any suitable datacenter in Spain during the last year, not even for micro-routing.

 

Some due clarifications for you and the readers:

 

- RIPE NCC is the only RIR for Europe, Middle East and some Asia areas, and it maintains the correct data for all Nihal IP addresses since almost one year ago

 

- there is only one WHOIS version (see below). It is correct as well. We don't know what you're talking about. We talk about query of the RIPE database service via WHOIS.

 

- the RIPE database correctly locates Nihal IP addresses in Madrid, Spain, where the server Nihal is actually located https://apps.db.ripe.net/search

 

About the second server we added in Spain, we have not looked for a datacenter that pleases this or that TV or any other geo-discriminatory service, we have picked a network neutral datacenter, compliant to our requirements. We also tend to avoid contacts with datacenters which do not respect Net Neutrality, even if such a feature is not essential for a closed server only used for micro-routing, simply because it's not very elegant to give money to someone who is against our mission.

 

Here is the WHOIS (40.439206460032445 -3.6216259002685547 are longitude and latitude of some point in Madrid).  "geoloc" entry and all the other entries are correct since August 2014. Privately maintained databases, if what you report is true, are clearly not updated every year and even refuse corrections, even when the RIPE says they are wrong.

 

~$ whois 46.182.35.14
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '46.182.35.0 - 46.182.35.255'

% Abuse contact for '46.182.35.0 - 46.182.35.255' is 'abuse@bitcanal.com'

inetnum:        46.182.35.0 - 46.182.35.255
netname:        PT-BITCANAL
descr:          Bitcanal PoP Madrid
descr:          Bitcanal INFRA-AW
org:            ORG-ETL18-RIPE
country:        ES
geoloc:         40.439206460032445 -3.6216259002685547
admin-c:        BAC13-RIPE
tech-c:         BTC14-RIPE
status:         ASSIGNED PA
mnt-by:         JS65083-MNT
mnt-lower:      JS65083-MNT
mnt-domains:    JS65083-MNT
remarks:        **********************************
remarks:        ABUSE REPORTS MUST BE SEND TO ABUSE@BITCANAL.PT
remarks:        **********************************
created:        2012-11-08T11:25:41Z
last-modified:  2014-08-02T09:54:46Z
source:         RIPE # Filtered

organisation:   ORG-ETL18-RIPE
org-name:       EBONYHORIZON TELECOMUNICACOES, LDA.
org-type:       OTHER
address:        Calle Albazans, 71
address:        28037 Madrid
address:        SPAIN
phone:          +351 912386351
fax-no:         +351 220915985
mnt-ref:        JS65083-MNT
mnt-by:         JS65083-MNT
mnt-ref:        ELT-MNT
abuse-mailbox:  abuse@bitcanal.pt
created:        2014-08-02T09:51:05Z
last-modified:  2015-03-23T10:49:31Z
source:         RIPE # Filtered

role:           Bitcanal Admin Contact
address:        Praceta da Geminacao, 19 - 1 Dir. Tras
address:        4430-105 Vila Nova de Gaia
phone:          +351 224922637
fax-no:         +351 224922637
remarks:        trouble: Abuse Reports abuse@bitcanal.com
remarks:        trouble: Network Issues bitcanal.tech@bitcanal.com
admin-c:        JS9081-RIPE
tech-c:         MG12824-RIPE
nic-hdl:        BAC13-RIPE
remarks:        Bitcanal Administrative Contact
mnt-by:         JS65083-MNT
created:        2010-11-18T15:27:31Z
last-modified:  2014-02-05T10:30:58Z
source:         RIPE # Filtered
abuse-mailbox:  abuse@bitcanal.com

role:           Bitcanal Tech Contact
address:        Praceta da Geminacao, 19 -1 Dir. Tras.
address:        4430-105 Vila Nova de Gaia
phone:          +351 224922637
fax-no:         +351 224922637
remarks:        trouble: Abuse Reports abuse@bitcanal.com
remarks:        trouble: Network Issues bitcanal.tech@bitcanal.com
admin-c:        JS9081-RIPE
tech-c:         MG12824-RIPE
tech-c:         VA4061-RIPE
nic-hdl:        BTC14-RIPE
remarks:        Bitcanal Technical Contact
mnt-by:         JS65083-MNT
created:        2010-11-18T15:32:44Z
last-modified:  2015-04-02T09:35:04Z
source:         RIPE # Filtered
abuse-mailbox:  abuse@bitcanal.com

% Information related to '46.182.35.0/24AS197426'
 

 

[zhang888 1066]

Hello Staff,

Let me try to share some of my experience, and hopefully everyone will benefit from this eventually.

 

The mistake in this case is not RIPE's or geo-db maintainers, it's clearly Bitcanals.

GeoIP database aggregators cannot "scrape" records of every given /32 (single) IP address so for the sake of size and logic, the country databases

are aggregated by NETNAMEs.

 

That means, if you have 2 single NETNAME records in the same AS, you have very slim to none chances that a GeoIP provider will re-index your location,

since there is no such automatic procedure of doing so, not only for RIPEs IPs, but also for ARINs and APAC.

 

Bitcanal's NOC decided that it should be enough to update the RIPE record, keep the same "netname: PT-BITCANAL" record and call it a day.

Wel... Not exactly. Changing the address only in the RIR record won't matter much.

Right now Nihal's IPs look exactly same as 

http://bgp.he.net/net/185.18.156.0/24#_whois  under the same country.

 

However, a good example of how to do this right is on another subnet on Bitcanal's AS197426, which is the Russian E-Light-Telecom.

http://bgp.he.net/net/158.46.144.0/20#_whois

That record is only a few months old, but it was done correctly - no overlapping subnets have the same netname and a different country.

 

You can check IPs on the maxmind databases (which seems to be the most common on the internet) here:

http://whoer.net

 

 

This could probably be explained to Bitcanal, and after a few weeks it will be solved.

[OpenSourcerer 1435]

The other one:

 

as-block:       AS196608 - AS197631
descr:          RIPE NCC ASN block
remarks:        These AS Numbers are assigned to network operators in the RIPE NCC service region.
mnt-by:         RIPE-NCC-HM-MNT
created:        2009-03-25T07:46:28Z
last-modified:  2014-02-24T13:15:18Z
source:         RIPE # Filtered


aut-num:        AS197426
as-name:        Bitcanal-AS
descr:          Joao Carlos de Almeida Silveira trading as Bitcanal
org:            ORG-JCdA1-RIPE
import:         from AS29003 action pref=50; accept ANY
import:         from AS1930 action pref=100; accept AS-RCCN
import:         from AS13156 action pref=100; accept AS13156
import:         from AS12353 action pref=100; accept AS-VODAFONE-PT
import:         from as15169 action pref=100; accept AS-GOOGLE
import:         from AS12305 action pref=100; accept AS12305
import:         from AS26415 action pref=100; accept AS26415
import:         from AS6939 action pref=100; accept AS6939
import:         from AS13826 action pref=100; accept AS13826
import:         from AS8220 action pref=100; accept AS-COLT
import:         from AS2914 action pref=50; accept ANY
export:         to AS29003 announce AS-BITCANAL
export:         to AS2914 announce AS-BITCANAL
export:         to AS1930 announce AS-BITCANAL
export:         to AS13156 announce AS-BITCANAL
export:         to AS12353 announce AS-BITCANAL
export:         to AS15169 announce AS-BITCANAL
export:         to AS12305 announce AS-BITCANAL
export:         to AS26415 announce AS-BITCANAL
export:         to AS6939 announce AS-BITCANAL
export:         to AS13826 announce AS-BITCANAL
export:         to AS8220 announce AS-BITCANAL
remarks:        as2914 IPv6 (PEER) - NTT
mp-import:      afi ipv6.unicast from AS2914 accept ANY
mp-export:      afi ipv6.unicast to AS2914 announce AS-BITCANAL
remarks:        AS8426 (PEER) - Claranet
mp-import:      afi ipv4.unicast from AS8426 193.136.250.50 at 193.136.250.130 accept AS-CLARANET
mp-export:      afi ipv4.unicast to AS8426 193.136.250.50 at 193.136.250.130 announce AS-BITCANAL
remarks:        AS9186 (PEER) - ONI
mp-import:      afi ipv4.unicast from AS9186 193.136.250.170 at 193.136.250.130 accept AS-ONI
mp-export:      afi ipv4.unicast to AS9186 193.136.250.170 at 193.136.250.130 announce AS-BITCANAL
default:        to AS29003 action pref=100; networks ANY
admin-c:        JS9081-RIPE
tech-c:         MG12824-RIPE
remarks:        For information on "status:" attribute read https://www.ripe.net/data-tools/db/faq/faq-status-values-legacy-resources
status:         ASSIGNED
mnt-by:         RIPE-NCC-END-MNT
mnt-by:         JS65083-MNT
created:        2010-11-24T16:46:44Z
last-modified:  2015-05-05T04:30:28Z
source:         RIPE # Filtered

organisation:   ORG-JCdA1-RIPE
org-name:       Joao Carlos de Almeida Silveira trading as Bitcanal
org-type:       LIR
address:        Bitcanal
address:        Joao Silveira
address:        Praceta da Geminacao, 19 - 1 Dir. Tr.
address:        4430-105 Vila Nova de Gaia
address:        PORTUGAL
phone:          +351224922637
fax-no:         +351224922637
mnt-ref:        JS65083-MNT
mnt-ref:        RIPE-NCC-HM-MNT
mnt-by:         RIPE-NCC-HM-MNT
abuse-mailbox:  abuse@bitcanal.com
abuse-c:        BAC13-RIPE
created:        2010-11-10T10:22:49Z
last-modified:  2013-04-15T09:59:25Z
source:         RIPE # Filtered

person:         Joao Silveira
address:        Praceta da Geminacao, 19 - 1 Dir. Tras.
address:        4430-105 V. N. Gaia - Portugal
phone:          +351227136422
nic-hdl:        JS9081-RIPE
mnt-by:         JS65083-MNT
created:        2010-11-11T16:18:13Z
last-modified:  2010-11-11T16:18:14Z
source:         RIPE # Filtered

person:         Manuel Gomes
address:        Praceta da Geminacao, 19 - 1 Dir. Tras. 4430-105 V. N. Gaia
mnt-by:         JS65083-MNT
phone:          +351916478782
nic-hdl:        MG12824-RIPE
mnt-by:         JS65083-MNT
created:        2010-11-11T16:38:55Z
last-modified:  2010-11-19T10:09:04Z
source:         RIPE # Filtered

 

I entered the AS number. Explanation for the two version thing.

[Staff 9973]

Thanks Zhang888,

 

but it's not possible for us to get the whole /20 /21 subnet, because it is assigned to someone else and anyway it would be irrationally expensive for us for Spain (remember that Spain needs 20 Mbit/s for 35 customers at any given time...).

 

We got "just" a /24 subnet RIPE update (and we actually use only of a portion of that).

 

This one (46.182.35.0 - 46.182.35.255) is entirely and correctly geo-located to Madrid, so Bitcanal in our opinion operated correctly.

 

Is there any reason (limited resources?) for which not even a /24 subnet is scraped after almost a year or even never (if you know) when two NETNAME are in the same AS? Only "big" subnets such as /20 are scraped? If so, geo-IP database maintainers are even more unreliable than we suspected, because with IPv4 exhaustion we think it's not so rare to put two NETNAME records with the same AS.

 

Of course, if the remaining part of the /20 /21 subnet could agree to renounce to their NETNAME, then... but we think it's difficult, because they have another datacenter in Portugal and they probably need that.

 

Kind regards

[zhang888 1066]

Hello Staff,

I was actually talking -only- about 46.182.35.0/24, I don't know why you mentioned a /20 earlier,

They only have a single /21 -  in that range which is divided as follows:

46.182.32.0/21 - Parent

 

46.182.32.0/24 - Portugal

46.182.33.0/24 - Portugal

46.182.34.0/24 - Brazil

46.182.35.0/24 - Spain

46.182.36.0/24 - UK

46.182.37.0/24 - Portugal

46.182.38.0/24 - Portugal

46.182.39.0/24 - Portugal

 

but they don't need to change the NETNAME on the entire /21, just on that particular /24, which is all

assigned for Madrid colocation anyway.

 

inetnum:        46.182.35.0 - 46.182.35.255
netname:        PT-BITCANAL
descr:          Bitcanal PoP Madrid
descr:          Bitcanal INFRA-AW

 

Right now they only have to change only a single record, NETNAME on 46.182.35.0/24, to something like ES-BITCANAL in

the RIPE database, because we have an overlapping NETNAME object in 46.182.39.0/24 for Portugal.

 

inetnum: 46.182.39.0 - 46.182.39.255
netname: PT-BITCANAL
descr: Bitcanal VoIP
country: PT

 

Trust me, it will do wonders and Maxmind will catch it in less than a month, and the TV stations will follow them most certainly.

[pj 72]

Hello Zhang888 and giganerd and everybody reading the thread.

 

I want to add a side note after I have examined a long mail intercourse between Bitcanal and me in August 2014 about this problem. All they could do was re-allocating the /24 subnet of our server.

 

We picked anyway this datacenter for excellent reasons: we had just withdrawn servers from or discarded several datacenters which stopped to be network neutral (for example asking us to monitor traffic, block p2p protocols and performing other horrible things that are incompatible with our mission). Bitcanal agreed to a special contract including explicit clauses for our needs and requirements and proved to be really network neutral. It also has very good connectivity (excellent for Spain standards).

 

In these cases, as reported in the previous message by Staff, the choice is obvious: the satisfied requirements are much more important than this (marginal in my opinion) issue. Personally I assumed that a /24 subnet would have been enough for a correct geo-location. Even if I was wrong, I still think that it's not very important. The important thing is that we have ensured net neutrality and higher privacy in the heart of Spain for a year, when all other providers were scared to death for a trivial notice about © or something like that.

 

Let's see what happens with this new server in Spain operating since a couple of weeks ago if I recall it correctly.

 

Kind regards

[pj 72]

 

but they don't need to change the NETNAME on the entire /21, just on that particular /24, which is all

assigned for Madrid colocation anyway.

 

That's clear, I will contact them about that. Personally, I totally missed that.

 

Kind regards

pj

[pj 72]

Right now they only have to change only a single record, NETNAME on 46.182.35.0/24, to something like ES-BITCANAL in

the RIPE database, because we have an overlapping NETNAME object in 46.182.39.0/24 for Portugal.

 

 

That was changed, I see RIPE db updated already. Now we just need to wait.

 

How's the other Spain server doing?

 

Kind regards

pj

[doveoriginal 9]

In any case, I just want to thank everybody looking for solutions and working together on them. There's a couple of messages that leave me excited waiting to see if now it gets solved finally and I am just extremely happy about that. All in all, I am extremely satisfied with AirVPN and I consider it by far the best VPN service out there, this issue with Nihal being the only criticism I had. After all I am happy that my initial message started a fruitful discussion and again - a big thank you to everybody involved.

[zhang888 1066]

A small update:

 

MaxMind, ip2location, and domaintools (3 largets GeoIP DB providers used on the internet) already changed the country accordingly.

 

 

 

 

 

 

 

 

 

The next natural thing would be a little more patience, until the sites that have GeoIP discriminations will update their

IP databases. Normally it is a proccess that happens monthly (with a cron scheduled task).

 

 

I guess you guys owe me a beer

[Staff 9973]

The next natural thing would be a little more patience, until the sites that have GeoIP discriminations will update their

IP databases. Normally it is a proccess that happens monthly (with a cron scheduled task).

 

 

I guess you guys owe me a beer

 

 

We owe you a lifetime supply of the finest non-industrial beers.

 

Kind regards