No more access to ipfire - Core 150 | Location-Filter

Getting Started with IPFire Updates Trouble
22

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.

23

Same here, problem is in AU (Australia) networks:
LocBlock AU Problem

After disabling AU (by serial commandline!) box is up again.

24

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.

25

yes, two times but no result.
Had to turn off location filter

26

How can i turn off this *** over the commandline? Any hints?

27

@zonediver look here

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

28

@bladerunner
Thanks for your help - was able to bring back the GUI and deactivated this GeoBlock**** :+1: :smile:

29

an other way is using elinks via console login to webinterface turn off locationfilter and reboot.

30

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:

  1. 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.
  2. 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 :expressionless: ), 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. :slight_smile:

Thanks, and best regards,
Peter Müller

10 Likes
31

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.

:+1:

7 Likes
32

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 :sweat_smile: I watched it like a hawk for the last three days :nerd_face:

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…)

1 Like
33

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

2 Likes
34

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?

1 Like
35

Hi,

yes, that’s what I thought as well. :expressionless: 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

1 Like
36

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.

37

Hi,

welcome to the IPFire community and thanks for providing feedback. :slight_smile:

Did you reload your firewall engine afterwards (/etc/init.d/firewall reload)?

Thanks, and best regards,
Peter Müller

38

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

39

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.

40

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.

4 Likes
41

Hi,

…“for the records” and for everyone who runs into this problem with Core 150 - perhaps it helps:

Despite upgrading to Core 150 a few days ago, nothing was blocked. I waited.

Yesterday morning, 8:00, I suddenly couldn’t get any access to the GUI or via SSH. ‘ping’ was OK, but that was all. I had apparently joined the bug. Database update!? Ok, lets see.

What I did (memory protocol!):

Since there is no keyboard or monitor down in the cellar where my box is standing, I had to take her upstairs with me.

I attached monitor, keyboard and GREEN only. No RED available here…

Disabled Geo-IP-Blocking by editing /var/ipfire/firewall/locationblock, changing LOCATIONBLOCK_ENABLED=on
to
LOCATIONBLOCK_ENABLED=off.

Added the fix from:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=c69c820025c21713cdb77eae3dd4fa61ca71b5fb to ./usr/lib/firewall/rules.pl

Rebooted. Access to GUI was OK. Hm.

I brought the box back in the cellar and attached GREEN and RED.

After a restart, GUI was still OK, but DNS and DNSSEC were completely broken.

I opened https://[GREEN_IPFIRE_IP]:444/cgi-bin/location-block.cgi (Enable Location based blocking: was unchecked as intended), changed NOTHING, just clicked on SAVE and reloaded all rules on https://[GREEN_IPFIRE_IP]:444/cgi-bin/firewall.cgi.

Then I activated Geo-IP-Blocking again and its still running OK.

IPTables / LOCATIONBLOCK on https://[GREEN_IPFIRE_IP]/cgi-bin/iptables.cgi have to look like this:

2020-10-17_iptables_location_block
2020-10-17_iptables_location_block823×285 6.13 KB

HTH,
Matthias

1 Like