Summary: | Core Update 165 (testing): Outgoing firewall rules containing a location group as destination are not present in iptables after a reboot | ||
---|---|---|---|
Product: | IPFire | Reporter: | Peter Müller <peter.mueller> |
Component: | --- | Assignee: | Stefan Schantl <stefan.schantl> |
Status: | CLOSED FIXED | QA Contact: | Peter Müller <peter.mueller> |
Severity: | Major Usability | ||
Priority: | - Unknown - | CC: | michael.tremer |
Version: | 2 | Keywords: | Blocker |
Hardware: | unspecified | ||
OS: | Unspecified | ||
See Also: | https://bugzilla.ipfire.org/show_bug.cgi?id=12812 |
Description
Peter Müller
2022-03-20 10:03:01 UTC
I was able to track this down: Outgoing firewall rules containing a single country as a destination work fine, outgoing firewall rules containing a location group as a destination do not. This bug can be reproduced by: (a) Installing Core Update 165 (testing) on a Core Update 164 machine. (b) Creating two outgoing firewall rules, one to a single country, and one to a location group. (c) Reboot the system. (d) Inspect the output of "iptables -L -n -v" after rebooting. There, the outgoing firewall rule containing a single country is present, the other is not. Please let me know if further information is required. Okay, this is helpful. Is there any output on the screen at boot time? We need to find out whether incorrect firewall rules are being created that could not be inserted into the kernel, or if the script didn’t even attempt to load anything. I do not know why this would be different at boot time compared to later on. The only thing I could come up with is that RED isn’t up (yet)? I just reverted my firewall rule changes, connected a display to the testing machine, and rebooted it. On boot, the iptables rules containing the output firewall rules are outputted, and it says: "Set DE doesn't exist" Later, a couple of these are printed on the screen: "Another app is currently holding the xtables lock. Perhaps you might want to use the -w option?" To me, this confirms the suspicion bug #12812 is related to this, since the xtables lock is not being released properly, perhaps causing some iptables rules for the IPS not being written correctly either. > On 23 Mar 2022, at 10:10, IPFire Bugzilla <bugzilla@ipfire.org> wrote: > > > Comment # 3 on bug 12809 from Peter Müller > I just reverted my firewall rule changes, connected a display to the testing > machine, and rebooted it. On boot, the iptables rules containing the output > firewall rules are outputted, and it says: > > "Set DE doesn't exist" Yes, Stefan knows why this is happening. He will submit a patch hopefully by the end of the day. > Later, a couple of these are printed on the screen: > > "Another app is currently holding the xtables lock. Perhaps you might want to > use the -w option?" We should always call iptables with —-wait. In which script is this? Hello Peter, thanks for pointing this out. The problem on appears when using location based groups for various rules, because of a parsing issue. I've sent a fix to the development mailing list. https://patchwork.ipfire.org/project/ipfire/patch/20220323170852.2964-1-stefan.schantl@ipfire.org/ Best regards, -Stefan https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=c55f5c8eaaa5b91a63765b1ac5fec4da8ce028fb @Stefan: Thank you for the quick fix. :-) |