Location filter since core 148

Networking
1

Hi there.

Sorry if I miss placed the topic. It is about the location filtering since core 148.
I have an xmpp service running. Previously (before core 148) I had a location filtering on RED interface to only allow FR and BE locations to connect to XMPP.

Now with the new core 148 et libloc It does not work anymore.
I grabbed my cellphone ip once (from Orange in Belgium 94.109.230.190) it gets filtered with DROP_IN. If I replace the firewall rule with RED instead of the location group FR+BE for the input, the connection works. If I specify BE+FR or even just EU, I get DROP_IN

I check with location the lookup and it is belgium:
location lookup 94.109.230.190
94.109.230.190:
Network : 94.104.0.0/13
Country : Belgium
Autonomous System : AS47377 - Orange Belgium SA

Even in the firewall log, this IP is noted as BE ! Why is it dropped ? I really don’t understand :frowning:
Any idea ?
Thanks

2

Hi,

welcome to the IPFire community. :slight_smile:

Even in the firewall log, this IP is noted as BE ! Why is it dropped ? I really don’t understand :frowning:

This behaviour can be reproduced here by adding a firewall rule allowing ICMP type 8 messages to Belgium (for running mtr against 94.109.230.190) from GREEN network. The packets are both dropped and logged although they should pass. Changing the country to DE and pinging an IP address located in Germany works fine.

I have no idea about what is going on here. 94.104.0.0/13 is a rather large chunk, but this should not matter.

@stevee: Can you reproduce this issue as well?

Thanks, and best regards,
Peter MĂĽller

3

welcome to the IPFire community. :slightly_smiling_face:

Thank you !

Yes that’s strange. At least I believe it is not related to my config. Is there any log where I could dig to follow what’s going on ?

Best
Jordan

4

Hi,

for the records: Bug #12480 has been opened to track this.

Thanks, and best regards,
Peter MĂĽller

5

@pmueller Hi Peter,

after a short test i can report:

Only allow, ICMP type 8, DE

  • 78.48.0.0/13 78.48.0.5 works

Only allow, ICMP type 8, BE

  • 84.192.0.0/13 84.192.0.5 works
6

Hi,

yes, those work for me as well.

However, 94.109.230.190 is unreachable if Belgium is selected as a destination. Strange.

@tulpenknicker: Can you confirm this?

Thanks, and best regards,
Peter MĂĽller

7

@pmueller

Hello Peter,

first i want tell you, what i all tried few days ago and today. On my first try, i was not able to reach anything behind this IP. Also i used a online Ping tool. All i get there was a timeout.

So today i look a little bit closer.

[root@ipfire2 ~]# location lookup 94.109.230.190
94.109.230.190:
  Network                 : 94.104.0.0/13
  Country                 : Belgium
  Autonomous System       : AS47377 - Orange Belgium SA
[root@ipfire2 ~]#

And online

inetnum:        94.108.128.0 - 94.111.255.255
netname:        KPNBE
descr:          KPN Belgium IPv4 dynamic - Consumer
country:        BE
admin-c:        KPNB-RIPE
tech-c:         KPNB-RIPE
status:         ASSIGNED PA
mnt-by:         MNT-AS47377
created:        2008-11-03T12:22:10Z
last-modified:  2009-01-14T09:28:11Z
source:         RIPE

role:           KPN Belgium NV Role
remarks:        *** Mobistar Enterprise Services - ex KPN Belgium ***
address:        Mobistar Enterprise Services
address:        3, Avenue Jules Bordet
address:        1140 Brussels
address:        Belgium
address:        Belgium
org:            ORG-KBN2-RIPE
abuse-mailbox:  abuse@mail.mobistar.be
admin-c:        MB19327-RIPE
tech-c:         MB19327-RIPE
tech-c:         KG1356-RIPE
mnt-by:         MNT-AS47377
mnt-by:         MOBISTAR-MTNER
nic-hdl:        KPNB-RIPE
remarks:        Please direct all queries to this role
remarks:        and *not* to person objects
created:        2008-05-22T15:35:16Z
last-modified:  2011-07-01T07:35:14Z
source:         RIPE # Filtered

% Information related to '94.108.0.0/14AS47377'

route:          94.108.0.0/14
descr:          AS47377 IPv4 Network - BRAS
origin:         AS47377
mnt-by:         MNT-AS47377
created:        2008-10-14T08:06:57Z
last-modified:  2008-10-14T08:06:57Z
source:         RIPE

The Data are different. But should works anyway or?

Today, i was again not able to reach this IP. Also online tool again timeout.

Only allow BE, no matter if i can reach this IP or not it should not dropped, right? But all what i can say i confirm. Also only get a dropped log.

8

Hi there.

Thank you for the investigation you are doing.
I did not specify at first, but this IP is/was from my GSM with 4G. I don’t know if this is related or not but I tried several things to understand the situation.
With my GSM and 4G, I tried to connect to my XMPP server -> ipfire reported the previous IP drop packaged.
With the very same GSM and connection, a few second later, I tried to open a web page on my very same server and the IP logged in apache was different. It seems my provider has several endpoint which are used more or less randomly ? Even checking my ip on an online website did not report the same IP several times.

I don’t know how the location filtering works but in both @anon33261557 data the country is reported as Belgium … How does the filtering work ?

9

Good Morning.

The same thing happens to me in a Client which, has published with a DNAT an IP to port 8080 and supposedly only should or would have to access from Bilbao - Spain, but if I activate the Location Filter, leaving all the countries of the EU including Spain, cannot access certain clients. I have looked at the Firewall Logs and the allowed requests, they do perfectly DNAT (the countries allowed in the Location Filter) but they do not work for certain clients. If I deactivate the Location Filter, requests from a lot of countries appear (USA, China, Italy, Brazil, England, Germany, etc …) but it should only be accessed from Spain and even if Spain is allowed, they cannot access it.

I am waiting for you to give me a list of public IPs from which they cannot access to check it with the Location Filter to see which country appears in the IPFire.

I had to disable everything related to the Location Filter and so on, if it works.

I hope I have explained myself well. :+1:

Regards.

10

@diablotin

This explains why iam not able to ping it, no matter if allowed or not. From my own experience, i know that mobile Provider you dont(often?) give you an IP what you can not reach from outside. Thats why you normally can not setup a service on your phone that you can reach. But thats not important. As i wrote it should not dropped log if you try it anyway.

If you have Firewall → Location Block enabled,

you find afterwards under

Firewall → iptables → Locationblock,

what happens behind the curtain. You see here that for the countries you do not want are drop iptable entrys for each country.

If you have a Locationblock rule done by yourself, you find the entry under

Firewall → iptables → FORWARDFW

@roberto

here for example is exactly the same. I tested the first few. in location lookup they are all correct in CN, but do not work anyway. Only allow, ICMP type 8, CN do not work only get dropped log.

I have all understand :wink:

11

Hi @anon33261557.

This IP is Spanish and even allowing Spain (Barcelona), if I activate the filter, you cannot access:

195.57.123.182

[root@bs ~]# location lookup 195.57.123.182
195.57.123.182:
  Network                 : 195.57.0.0/16
  Country                 : Spain
  Autonomous System       : AS3352 - TELEFONICA DE ESPANA
[root@bs ~]#

imagen
imagen740Ă—298 18.4 KB

And one group called “Good Countries”.

imagen
imagen935Ă—767 28.9 KB

And Rules:

imagen
imagen970Ă—631 37.5 KB

For it to work I have to put ANY, if I put Good Countries + Location Filter it doesn’t work.

I will try to get more IPs.

Thank you. :wink:

12

And this, Firewall Log:

imagen
imagen1012Ă—189 17.1 KB

A DROP_INPUT to a supposedly allowed Spanish IP.

Regards.

13

And this one, which being physically in Spain, says that it is from the United States.

47.60.49.96

[root@bs ~]# location lookup 47.60.49.96
47.60.49.96:
  Network                 : 47.60.0.0/16
  Country                 : United States of America
  Autonomous System       : AS12430 - VODAFONE ESPANA S.A.U.
[root@bs ~]#

And here it says that it is Spanish:

imagen

Something is wrong.

Regards.

14

@roberto

Hello Roberto,

maybe i have confused you about my testing? If so iam sorry. I do not have the possibility to test from each of the countries if they are able to reach anything behind my IPFire. So i do the opposite, i test from IPFire to the countries. For this, i block all ICMP (blocked by Forward Firewall policy). Afterwards i only allow ICMP type 8, country from green, what i want test. The result must be the same as in your testing, so it plays no matter. Your example is the same as the others who not works. So sometimes they work and sometimes not. Iam not able to understand whats the problem. But i saw @ms itself works now on this and i read here

it should fixed latest by core 150. So all what we have to do is wait :wink:

If i understood this correct (iam not sure) is the problem the following. Vodafone have here a network, range 47.58.0.0 - 47.73.255.255 and the company is located in

Organization: Vodafone US Inc. (VGE-3).

They have split there network. And thats, whats not in the IPFire database. Why, i have not understood myself.

NetRange:       47.58.0.0 - 47.73.255.255
CIDR:           47.72.0.0/15, 47.64.0.0/13, 47.60.0.0/14, 47.58.0.0/15
NetName:        VODAFONE-IP-SERVICE
NetHandle:      NET-47-58-0-0-1
Parent:         NET47 (NET-47-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       
Organization:   Vodafone US Inc. (VGE-3)
RegDate:        2012-05-15
Updated:        2018-01-31
Ref:            https://rdap.arin.net/registry/ip/47.58.0.0


OrgName:        Vodafone US Inc.
OrgId:          VGE-3
Address:        560 Lexington Avenue
Address:        9th Floor
City:           New York
StateProv:      NY
PostalCode:     10022
Country:        US
RegDate:        2013-10-07
Updated:        2020-03-06
Ref:            https://rdap.arin.net/registry/entity/VGE-3

# start

NetRange:       47.60.0.0 - 47.63.255.255
CIDR:           47.60.0.0/14
NetName:        VODAFONE-IP-SERVICE
NetHandle:      NET-47-60-0-0-1
Parent:         VODAFONE-IP-SERVICE (NET-47-58-0-0-1)
NetType:        Reassigned
OriginAS:       AS12430
Organization:   Vodafone Spain (VS-42)
RegDate:        2012-09-19
Updated:        2012-09-19
Ref:            https://rdap.arin.net/registry/ip/47.60.0.0


OrgName:        Vodafone Spain
OrgId:          VS-42
Address:        Isabel Colbrand n22
City:           Madrid
StateProv:      MADRID
PostalCode:     28041
Country:        ES
RegDate:        2012-09-19
Updated:        2012-09-19
Ref:            https://rdap.arin.net/registry/entity/VS-42
15

Hi,

indeed, this Belgium IP address problem is a bug and will be fixed in upcoming Core Update 150 (Core Update 149 is already closed and about to be released next week, so we cannot include a fix there anymore).

Thanks for all testing and confirmation efforts. :slight_smile:

Regarding 47.60.49.96 and 47.60.0.0/16 located in the US: The story behind this is complicated indeed and goes as follows:

There are five RIRs on this planet (ARIN, LACNIC, AfriNIC, RIPE, APNIC), publishing data about the IP address space maintained by them on different FTP servers in a different format. Except for ARIN and LACNIC, all of them provide data regarding suballocated IP networks, such as a /24 assignment under a /22 LIR chunk.

We are currently working on importing those data, and expect to return more accurate data for all regions of the world except for both North, Latin and South America as well as the Caribbean.

From ARIN and LACNIC, who serve those areas, we only get data initially collected for statistical purposes, which are way more inaccurate. Exact results are provided by querying their public Whois services, which are strictly rate-limited, so we cannot scrape data from them in a reasonable amount of time.

This is why results for those RIRs are likelier to be inaccurate, which includes 47.60.0.0/16, as this network is assigned by ARIN, albeit being used outside their area.

We introduced something called “overrides”, which allows us to manually set the country of entire networks or Autonomous Systems in case we know they are wrong on purpose or by chance. I will add an override for 47.60.0.0/16, however, this is a best-effort approach, and I am currently the only person maintaining it (to be honest, I do not think it’s an elegant one, but this is all we’ve got, so we have to make do with it).

In the end, this topic deals with two separate libloc-related issues:

  1. Bug #12480
  2. Inaccurate data from ARIN and LACNIC

The first will be fixed in Core Update 150, the latter probably will never be complete and is subject to ongoing efforts. A modern Sisyphus task, if you like to put it that way…

Thanks, and best regards,
Peter MĂĽller

3 Likes
16

Hi,

for the records: https://patchwork.ipfire.org/patch/3443/

Thanks, and best regards,
Peter MĂĽller

17

Hi all

I have managed to reproduce the problem in a Client. From a Movistar mobile with Public IP 176.87.55.182 which is from Spain and the mobile was in Spain, in Zumaia exactly, if in this rule I only put that they can access from ES, it does not work:

imagen
imagen918Ă—47 2.44 KB

Only works fine with “Any”.

[root@bs ~]# location lookup 176.87.55.182
176.87.55.182:
  Network                 : 176.80.0.0/13
  Country                 : Spain
[root@bs ~]#

Will this be solved with the Core 150?

First of all, thank you all very much for your effort. :clap:

Best regards.

18

Hi,

as I wrote above, yes.

Thanks, and best regards,
Peter MĂĽller

19

Hi,

for the records: https://patchwork.ipfire.org/patch/3443/

meanwhile, this patch made it into the location repository. Since IPFire machines update their location databases once a week, you should receive that change shortly. :slight_smile:

Thanks, and best regards,
Peter MĂĽller

20

Thank you for your great work and reactivity.
Can wait to test core 150 :wink:
Jordan