Have you restarted the firewall?
Just my âŹ0.02 as I got it working again with core150 here the steps taken as described in the bugtracker
- if not already done, disable location-block, methods in this thread
- upgrade, restart, login on shell
- run âlocation updateâ, take note that the version it gets is from tuesday at least
- restart
- enable location-block
- reload rules
- should be working again, if not login on shell, disable using above methods and wait patiently for final fix?
These steps worked for me, and I block all but two countries.
Same here, problem is in AU (Australia) networks:
After disabling AU (by serial commandline!) box is up again.
doesnât work for me. My database is from this morning after update location and then it doesnât work .
also without EU.
What works is Locationfilter turn off completly.
that could be a hint. Just My 2 Cents. Turn off locationfilter until it is fixed completly.
yes, two times but no result.
Had to turn off location filter
How can i turn off this *** over the commandline? Any hints?
Interesting, my Box seems to work normally for the last two daysâŚ
On the location, I get results for EU and AU:
[root@geoipblock ~]# location list-networks-by-cc EU | grep â192.0.0.0â
192.0.0.0/3
[root@geoipblock ~]# location list-networks-by-cc AU | grep â192.0.0.0â
192.0.0.0/8
@bladerunner
Thanks for your help - was able to bring back the GUI and deactivated this GeoBlock****
an other way is using elinks via console login to webinterface turn off locationfilter and reboot.
Hi all,
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 tolibloc
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
and192.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.
Thanks, and best regards,
Peter MĂźller
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âŚ)
Hi,
a fix for the location filter has been developed by @ms the other day and will be released with Core Update 151.
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.
Thanks, and best regards,
Peter MĂźller
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?
Hi,
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?
Thanks, and best regards,
Peter MĂźller
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.
Hi,
welcome to the IPFire community and thanks for providing feedback.
Did you reload your firewall engine afterwards (/etc/init.d/firewall reload
)?
Thanks, and best regards,
Peter MĂźller
I did a reload. I did a reboot. But i have to allow AU and EU to get it working with the present code.
Please check your current md5sum of my file against your file to make sure i applied the right commit
[root@ipfire firewall]# md5sum ./rules.pl
0f1a242f7ac26e176e1e689265bae38a ./rules.pl
Here Git - missing GLIBC Michael say the problems are fixed. Could we use the filter now? Can someone write a blogpost about the state please.
I am AU based and my Protectlii ipfire also succumbed to the same issue. I have all countries blocked and was totally locked out of ipfire.
Got caught up trying to get a connection with a serial cable but put that on hold when I realised I would need to purchase a serial to USB cable due to my desktop not having a serial port.
I then attempted a restore from my 149 backup and this in the end worked OK.
After a successful restore I then had to manually restart the DHCP service and re install the Guardian add-on. I did a reboot of the ipfire just to make sure the services were all active.
Iâm OCD when it comes to updates so I disabled location blocking and then then reapplied 150.
Once again Iâm shown the value of running regular backups across all of my systems and data.
Thanks to all who contributed to this topic by posting their troubleshooting and resolution steps on this issue.
Technical issues will always occur on the likes of an ipfire. These are given to us as opportunities to delve deeper, learn and improve our contingency planning.
Despite this glitch I remain grateful to the team for giving us the excellent product that ipfire is.