Core-Update-Level: 148 (Location-Filter)

Hello,

there is a problem with the “Location-Filter”. IP addresses from the area of the Germany are blocked and thus identified:

What can I do without switching off the “Location-Filter”?

Thanks
Olaf

root@michael:/build/location-database# location lookup 84.119.88.202
84.119.88.202:
  Network                 : 84.119.0.0/16
  Country                 : Netherlands
  Autonomous System       : AS6830 (Liberty Global B.V.)

This IP address belongs to Liberty Global which is a Dutch company.

If i use for example Whois | heise Netze

i get also

% Information related to ‘84.119.0.0/16AS20825’

route: 84.119.0.0/16
descr: Unitymedia
origin: AS20825
mnt-by: UNITYMEDIA-MNT
created: 2013-04-05T08:22:18Z
last-modified: 2013-04-05T08:22:18Z
source: RIPE

Interesting, GeoData gives this location (which also fits)

There are two routing entries in the Ripe Database and the AS6830 is newer

inetnum:         84.119.0.0 - 84.119.255.255
org:             ORG-iGCK3-RIPE
netname:         UNITYMEDIA-B2C-POOL-NET
descr:           Unitymedia dynamic DHCP B2C customer pool
country:         DE
remarks:         ====================================================
remarks:         Kontaktdaten fuer Behoerdenanfragen Mo-Fr. 08-16 Uhr
remarks:         Contact data for any legal/law enforcement inquiries
remarks:         behoerdenauskunft (at) unitymedia.de
remarks:         Fax: +49 221 2991 9002
remarks:         Notrufrueckverfolgung / Gefahr im Verzug 24x7h unter
remarks:         Fax: +49 221 2991 9003
remarks:         ====================================================
abuse-c:         UMAB-RIPE
admin-c:         UMAC-RIPE
tech-c:          UMTC-RIPE
status:          ASSIGNED PA
mnt-by:          UNITYMEDIA-MNT
created:         2018-03-26T12:35:32Z
last-modified:   2019-01-11T10:17:50Z
source:          RIPE

route:           84.119.0.0/16
descr:           Unitymedia
origin:          AS20825
mnt-by:          UNITYMEDIA-MNT
created:         2013-04-05T08:22:18Z
last-modified:   2013-04-05T08:22:18Z
source:          RIPE

route:           84.119.0.0/16
descr:           Liberty Global - UMKBW
origin:          AS6830
mnt-by:          AS6830-MNT
created:         2015-05-27T09:53:39Z
last-modified:   2015-05-27T09:53:39Z
source:          RIPE    

OK, I assume that the data is on IPFire? If so, how can I update the database?

Yes, WHOIS says it is Germany, but the data from RIPE shows NL.

This database is not supposed to report the actual physical location of a host on the Internet, but rather its jurisdiction - whenever that is possible.

You can run “location update”.

What in here suggests DE?

I want only informed you that i get another entry. The same what Arne after my post also report. Nothing more. My knowledge is not enough to give you a answer what you maybe searching for.

Isn’t it possible to include an option that determines whether the determination of the location is queried via RIPE or WHOIS?

That would simplify the whole thing a bit, because my boss would like to have access only within the DE region, for example. By the query RIPE I must release now however also the NL. Or do I get the whole thing wrong?

Thanks
Olaf

Hi,

unfortunately, things are not that simple.

We cannot scrape Whois en masse, since RIRs tend to have very strict ratelimits
on their servers. Their raw data is all we have (except for RIPE, where things look
a little bit better), which cover direct RIR allocations only.

So, if a company acquires a /22 and splits it up into four /24 networks, we will
not be able to determine the country codes of that sub-allocations, since they
simply do not show up in the data we have.

Depending on the network your superior happens to get connectivity from, it might
be a good idea to allow EU as well, since some networks are used across Europe.
Either way, using a VPN service should be sufficient in order to keep dial-up procedures
from your superior safe.

Thanks, and best regards,
Peter Müller

Isle of Man addresses under 2.25 148 are being classed as Great Britain, breaking location based rules that worked in 2.25 147.
This page of another location service contains addresses that are being misidentified:

I am on core 148 but I still see I have xt_geoip_update

And fcron.weekly also keeps using it xt_geoip_update -> /usr/local/bin/xt_geoip_update

Late edit:
Fount the (new) location utility … I believe the old one should be removed including the fcron entry?!

Thanks!

I don’t know if it’s relatedu but…

a bug has been filed for libloc/location filtering.

Hi,

no, to my knowledge, this issue is not related to #12480. It has been instead filed
as #12477 and is expected to be at least partially fixed with processing
various inetnum RIR files again (see #12458 for details).

Thanks, and best regards,
Peter Müller