Hi all, it is currently not possible to use IPSet sets in firewall.local if the firewall initscript getting restarted cause the firewall.local sets getting destroyed while this process. Since the introduction of the locationblock, IPBlocklist but also the drop_hostile_networks features, rules.pl recognizes the used but also unused IPSet sets by their name and stores/restores them in a respective '$db_file'. Even if all by IPSet used set names are listed in rules.pl --> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=config/firewall/rules.pl;hb=7270984c460653f2215271b86286f74e6e9fb6ca#l1016 the 'ipset_restore' function --> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=config/firewall/rules.pl;hb=7270984c460653f2215271b86286f74e6e9fb6ca#l1037 does not recognize potential firewall.local sets and tries to delete them via 'ipset_cleanup' function --> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=config/firewall/rules.pl;hb=7270984c460653f2215271b86286f74e6e9fb6ca#l1113. Therefor the firewall initscript throws after an restart the following error ipset v7.17: Set cannot be destroyed: it is in use by a kernel component ERROR: ipset destroy companies and if the firewall.local getting reloaded after a firewall restart, the following error appears Try `iptables -h’ or ‘iptables --help’ for more information. iptables v1.8.9 (legacy): Set companies doesn’t exist. (companies is the name of a used set) and the IPTable rules which includes IPSet sets in firewall.local are not working anymore. A fix for this is in work. Best, Erik
Fix has been pushed --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=054422072f78d2a0cd2ce52417155c98e5d98b8f . Best, Erik
(In reply to Erik Kapfer from comment #1) > Fix has been pushed --> > https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit; > h=054422072f78d2a0cd2ce52417155c98e5d98b8f . > > Best, > > Erik Correct link is here --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=a61e0c9a5fb77a863de115251f906455bd1c9161 . Sorry
While debugging the firewall.local function in rules.pl a strange behavior and not wanted behavior comes up. If firewall.local does have IPSet entries the common way to restore such sets are an entry in /etc/sysconfig/rc.local like /usr/sbin/ipset restore < /etc/ipset/ipset.conf so such rules survive an system reboot. Since rules.pl does also an restore a testing scenario was to delete the rc.local entry for firewall.local IPSet sets with the side affect that all sets (IPBlocklist and drop_hostile_networks in my case) disappeared --> $ /etc/init.d/firewall restart Setting up firewall Used ipset sets: (<-- tested with debug mode 1 in rules.pl) and a manual reload of firewall.local shows also the not known (lost) IPSet sets $ /etc/sysconfig/firewall.local reload iptables v1.8.9 (legacy): Set companies doesn't exist. Try `iptables -h' or 'iptables --help' for more information. iptables v1.8.9 (legacy): Set companies doesn't exist. Try `iptables -h' or 'iptables --help' for more information. iptables v1.8.9 (legacy): Set companies doesn't exist. Try `iptables -h' or 'iptables --help' for more information. (all entries in /etc/ipset/ipset.conf are there) If the firewall.local sets are entered again and the firewall are manual restarted only the firewall.local entries showed up again --> /usr/sbin/firewall-policy Used ipset sets: companies /etc/sysconfig/firewall.local reload but the IPBlocklist and the other sets are gone. To get this clear in one sentence, if the entry in rc.local to restore ipset.conf via ipset for firewall.local entries is missing, it flushes the other sets too. Even the firewall.local entries are made again and the firewall.local will be restarted, the other sets are lost. If the rc.local entry exists, all sets survive a system reboot and a manual firewall restart... Need to investigate further or may someone have an idea what is missing here?! Best, Erik