Check the output of dig, IPS, libloc and logs. A bit more thoroughly than usual, if you can
No IPS events, no DROP_OUTPUT in /var/log/messages; dig looks happy … I suppose?
; <<>> DiG 9.11.21 <<>> location.ipfire.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46598
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;location.ipfire.org. IN A;; ANSWER SECTION:
location.ipfire.org. 3197 IN CNAME fw01.ipfire.org.
fw01.ipfire.org. 3197 IN A 81.3.27.38;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Oct 24 18:35:30 CDT 2020
;; MSG SIZE rcvd: 83
Is there something else I can provide? Where do I find logs for libloc?
I can fetch the file via curl without issue:
[root@ipfire ~] # curl https://location.ipfire.org/databases/1/location.db.xz --output location.db.xz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 4047k 100 4047k 0 0 2471k 0 0:00:01 0:00:01 --:–:-- 2469k
[root@ipfire ~]#
Yet, location update still yields:
[root@ipfire ~] # location update
Downloaded database is outdated. Trying next mirror…
Could not download a new database
[root@ipfire ~]#
Any clues, suggestions on how do diagnose the issue?
I installed a fresh core 150 on a VM, did the setup and usual config.
location update does not update the database.
Hello,
After upgrading to 150 the network works but behaves strangely, I connect to the GUI but its blank, I also can’t connect via SSH. Is it the same problem as others have?
I still have dropouts of the firewall, although the Location Filter already excludes DE, Austria and Europe. Only after a complete deactivation of the Location-Filter with a restart of the red one I can work again.
Apparently there is no really permanent solution yet, is there?
MfG Paul
Have you found which coutry contain the wrong network? If you enable location but not tik any country it should do nothing at all.
I haven’t found the corresponding country yet. My network has the following segments.
Green 10.10.1.0/24
DMZ 10.10.2.0/24
WLAN 10.10.3.0/24
Red
192.168.178.0/24 (Fritz Box)
I will just say that it is too risky to do upgrades in remote locations. Of the 6 locations that I update regularly, they rarely go smoothly at all. All praise for IPFire but a safer way to upgrade must be found. The feeling when IPFire is not online after update reboot… 
1 Like
IPFire 2.25 Core 151 released today - does not require reboot from Core 150.
I have installed on my fw, all OK. Rebooted and all OK.
Have also installed on a non-critical nearby site and that is OK too, so far.
Have you tried location update
My freshly upgraded core 151 will not update the database. Getting the same message,
Downloaded database is outdated. Trying next mirror…
Could not download a new database
Ditto for me also, still getting:
[root@ipfire location]# location update
Downloaded database is outdated. Trying next mirror…
Could not download a new database
[root@ipfire location]#
I have just installed the Core Update 151. According to the website IPFire 2.25 - Core Update 151 released you should be able to see where an IP address is assigned but I can’t find a point for it on the web interface. Is this only readable via command line?
In addition to that, we now show whether an IP address is marked as an “anonymous proxy”, “satellite provider” or “anycast” which helps debugging network issues and investigating attacks.
Is this perhaps what is meant here?
No. If you are in firewall logs https://wiki.ipfire.org/configuration/logs/firewall-ip
or connection tracking and can click on an IP address for a detailed page.
The issue seems to be that after an upgrade, the empty file /var/ipfire/remote/enablessh does not exist therefore remote access is refused. Go to your gui, System | Remote access and click save, it will recreate that empty file and you should be able to remote ssh.
It worked for 2 hours and is now offline or locked out of ipFire again 
I’m in the process of maintaining our mail servers or installing important updates and it’s really bad when you get fired 
Even with the Core 151 I had no network. After deactivating the location filter and reading the firewall rules everything worked again. Unfortunately I can’t test all regions here until the error occurs because then I can’t get to my actual work (data center operation).
Could not download a new database
[root@ipfire ~]# location update
Downloaded new database from Tue, 27 Oct 2020 04:27:20 GMT
Could not verify database
Downloaded database is outdated. Trying next mirror...
Could not download a new database
[root@ipfire ~]# cat /etc/os-release
NAME="IPFire"
VERSION="2.25"
ID=ipfire
VERSION_ID=2
PRETTY_NAME="IPFire 2.25 (x86_64) - core151"Hi,
It worked for 2 hours and is now offline or locked out of ipFire again
this should not happen anymore. Does this persist if you download a new version of the location database using this command:
location update
(This seems to fail on some systems for an unknown reason at the time of writing, please refer to this thread if you experience downloading issues as well.)
@all: Is anybody else still observing this on Core Update 151?
Thanks, and best regards,
Peter Müller
Hi @stylo,
please refer to this thread for the download issue.
Thanks, and best regards,
Peter Müller
I have the Core Update 151 and could update the DB once. Now I get the message that I have the latest version of the DB on my system.
I would have liked to write earlier today but it was not possible to register on the website here.