[root@router ~]# location lookup 10.10.0.0
Network : 8.0.0.0/5
Country : European Union
[root@router ~]# location lookup 192.168.0.0
Network : 192.168.0.0/15
Country : European Union
———————
What does the 10 IP address range have to do with EU?
Neither 192.168.0.0/24
still 10.0.0.0/8 are used in the Internet and are reserved for private networks.
Even that should only work on the red interface of the location filter would make sense to me.
@roberto many thanks, you saved my day!!!
by the way only turning off EU did not work for my ipfire,
had to turn off location filter to regain access to web interface and internet.
first, thanks to everybody who reported this and helping other community members experiencing the same problem.
Technically, the root cause for this is a combination of two bugs:
The xt_geoip kernel module we continue to use after migrating from the GeoIP database to libloc consumes a list of networks, not a tree, hence causing mismatches in case of overlapping networks.
In order to generate as accurate results for AFRINIC, APNIC and RIPE as we can, we have changed the generation script of the location database on Monday night, becoming effective Tuesday morning. Unfortunately, some of those RIRs publish networks such as 0.0.0.0/5, which are currently garbage and of no use.
We filtered out anything that is not globally routable as such (e. g. 10.0.0.0/8), but those large networks covering other RFC 1918 IP space (172.16.0.0/12 and 192.168.0.0/16) slipped through. Because of (1), xt_geoip interprets them as a match for a large chunk of the IPv4 address space, causing the outage you observed.
To prevent this topic to be scattered across several threads, I am now going to close duplicates - please post your question here so we can all easily keep track of it.
The technical/development aspect of this issue is tracked at bug #12499.
We will keep you updated (it is probably going to be a long night for us ), in the meanwhile, please stay patient and - just to have it mentioned - avoid the temptation of ranting at us - it won’t bring you the fix faster.
Whoever insults you (developer) is not to be helped. Ipfire is a very good project and product which I have been using for years and appreciate very much. Anyone who does not appreciate the product and its stability is welcome to turn to another product.
The ipfire team does a professional job and you can’t be praised enough.
Thanks for the explanation and now I know why it works for me, I use 10.0.0.0/16 for all my internal networking needs, so the updated database works for my case I watched it like a hawk for the last three days
And I wholeheartedly agree with Pablo78, I have IPFire boxes at every single of my small business customers and they work exceptionally well. This is a glitch for a small use case, I really like the new location filter, it rivals or is better than commercial offers (unifi looking at you…)
However, this does not solve the glitches while creating the database and exporting it on an IPFire system for xt_geoip; we are still working on those parts of the issue.
Why does a (wrong) rule of 192.0.0.0/8 in the Location Block module, block access to IPFire from the INSIDE Green net?
I just thought that the Location Block examines and blocks traffic from Red to the firewall?
yes, that’s what I thought as well. But man proposes, God disposes; due to a bug, the location filter has been active on any interface, thus causing the interference.
The commit mentioned above now restricts it to work on red0 only.
@ms: That should work for ppp0 (dial-up connections) as well, since the traffic appears on red0 for those systems, too - or am I missing something?
I did commit this code to my 150 release. This is not doing its job. It is still blocking my 172.16.40.0/24 segment. Only by allowing AU and EU i regain access to my host.