While comparing source (CU197) / target (CU202) settings of a backup/restore procedure nearly everything looks perfect, but Location Block settings differ. While they where all (but Germany) set in the source system, some locations became unset in the target system, examples see picture.
Update: The same happens, when source and target are CU197 systems. So there is definitely something going wrong with the backup/restore of the Location Block settings.
The only thing related to the location system in the restore is that a script is run that checks if the old location program, that was used before the IPFire own location package was put together, is being used.
You can tell this if in the restore the following file exists
/var/ipfire/firewall/geoipblock
That script, convert-to-location, then converts the geoipblock list to the locationblock list.
However for that geoipblock to be in your backup it must have been created in an earlier version than CU140, around 6.5 years ago.
Check in the backup file itself (it is just a tar archive) to see if geoipblock is present in /var/ipfire/firewall/
If it is there then you need to setup your location block as you want and then create a new backup.
If it is not there then there is nothing else in the restore code from backup.pl that would modify the locationblock file from the backup.
If the file /var/ipfire/firewall/locationblock exists then have a look at the contents of that file in the backup to see if it has all the entries set to “on” except for XK, which will be set as “off”.
If they are not all set to on then it means that you must have not done a backup of your source system after setting them all to on.
I just had a closer look at the convert-to-location script and even if geoipblock exists in your backup then the conversion to the locationblock file is just a name change. The contents are not changed at all.
The only changes would occur to the input, config or outgoing firewall rules contents where it would replace cust_geoip with cust_location but not any change to the contents of what becomes locationblock.
I would suggest checking the contents of the locationblock file in the backup file and confirming if it has all entries except XK set to on of if ones like A1, AN, AT etc are set to off.
Thanks a lot for your analysis. Both files are in the backup:
geoipblock from 8.12.2019 with identical settings as shown in screenshot of target CU197 system.
locationblock from 22.3.2026 with all countries set to on, but only DE off. This is the running configuration of the source CU197 system.
So the logic in the restore script seems to use the old geoipblock settings instead of the running ones from locationblock file.
Yes, it does, because if you still have that file then you have the old version and so it needs to take the old version and name it to the new version.
After doing that, if you then do a new backup then you will have a backup with only locationblock.
I don’t know how you have ended up with both files in the backup. Maybe there was a period between two core updates where the restore code had not been modified to convert the geoipblock to locationblock.
Can you confirm that in /var/ipfire/firewall/ you don’t have a file named geoipblock.
If you do then delete it because geoipblock should not be on your IPFire system.
Then set up your location block page as you want and then do a fresh backup. You should then find that the backup only has the locationblock file in it and not geoipblock, which is what I have in my backup’s.
Then you should get rid of all the old backup’s and make a new backup regularly, best at least every CU.
I checked back and the change to locationblock from geoipblock occurred in CU148. The update script ran the convert-to-location script and that was also added in to the backup.pl file in CU148 so the update would have replaced geoipblock on your system with locationblock and also any restore from a previous backup that had geoipblock would have it updated to locationblock.
I can find nothing in the code that would result in the old geoipblock file being on the IPFire system at the same time as the locationblock file but it seems to me that somehow both ended up your system because that is the only way I can think of that you would end with both geoipblock and locationblock in the same backup.
I activated geo blocking on 2019-11-22 and Update IPFire 2.23 core 138. Before that there was a file geoipblock with 0 byte size. After activation it had 1.533 byte size.
After introducing libloc www.ipfire.org - On retiring the Maxmind GeoIP database my backups always contain both files, so I asume that the leftover of geoipblock happened during that transition. Maybe other readers can check their files, too.
However, on the target system only the locationblock file with 251 lines is present. So I guess, editing the country settings on/off on that system is sufficient and I do not have to create a new backup on the source system, true?
I found XK set to on, but what does it stand for? Neither I do find an equivalent in the GUI nor an explanation in the documentation www.ipfire.org - Location Block
Update: I found it here XK Location not found in Location DB and not displayed in UI, but exists in settings file - IPFire Projects / IPFire Location - IPFire Community
It is set to off automatically by IPFire because it is not a valid country location and should not be used as such. Hence why it is not in the WUI to select.
Having done a backup/restore from a CU202 system to the same one I get these kind of messages a lot while rebooting the new system:
ipset v7.24: The set with the given name does not exist
ERROR: ipset swap ZWv4 ZW
Try `iptables -h' or 'iptables --help' for more information.
ERROR: iptables --wait -A LOCATIONBLOCK -m set --match-set ZM src -j DROP
ipset v7.24: The set with the given name does not exist
ERROR: ipset rename ZWv4 ZW
iptables v1.8.13 (legacy): Set ZW doesn't exist.
I just found out, that most of the files in directory /var/lib/location/ipset are empty and lead to these messages. How can I get valid ipset data, by deleting the empty files?
...
-rw-r--r-- 1 root root 0 Jul 11 09:50 UYv4.ipset
-rw-r--r-- 1 root root 0 Jul 11 09:50 UZv4.ipset
-rw-r--r-- 1 root root 0 Jul 11 09:50 VAv4.ipset
-rw-r--r-- 1 root root 0 Jul 11 09:50 VCv4.ipset
-rw-r--r-- 1 root root 0 Jul 11 09:50 VEv4.ipset
-rw-r--r-- 1 root root 0 Jul 11 09:50 VGv4.ipset
-rw-r--r-- 1 root root 0 Jul 11 09:50 VIv4.ipset
-rw-r--r-- 1 root root 0 Jul 11 09:50 VNv4.ipset
-rw-r--r-- 1 root root 0 Jul 11 09:50 VUv4.ipset
-rw-r--r-- 1 root root 0 Jul 11 09:50 WFv4.ipset
-rw-r--r-- 1 root root 0 Jul 11 09:50 WSv4.ipset
-rw-r--r-- 1 root root 32719 Jul 11 09:50 XDv4.ipset
-rw-r--r-- 1 root root 0 Jul 11 09:50 YEv4.ipset
-rw-r--r-- 1 root root 0 Jul 11 09:50 YTv4.ipset
-rw-r--r-- 1 root root 24546 Jul 11 09:50 ZAv4.ipset
-rw-r--r-- 1 root root 0 Jul 11 09:50 ZMv4.ipset
-rw-r--r-- 1 root root 0 Jul 11 09:50 ZWv4.ipset
run these commands in sequence.
location version
this will tell you the current version on your system of the location database.
update-location-database
this will make update the database if it is more than a week old.
If it comes back and says that the database was recently updated then you will need to run the following commands
/usr/bin/location export --directory=/var/lib/location/ipset --family=ipv4 --format=ipset
This should export the location info from the database into ipsets in that directory.
If you then have correct ipset files then you will need to reload the firewall
/etc/init.d/firewall reload
That worked exactly as described, thanks a 1,000 times!
No problems.
I have no idea why so many ipset files were empty. Never seen that before.
Glad it sorted it out for you.