While the firewall changes introduced in Core Update 165 (testing) generally work fine for me, I just bumped into a rather nasty bug this morning: My testing machine is located behind a DSL connection, so it gets a new IP address assigned on every dial-in. Therefore, I am using DDNS (provider: https://desec.io/) to make a bunch of IPsec N2N connections work. Outgoing communication of the IPFire machine is limited; two firewall rules allow pinging any IP address in DE (for latency checks to the gateway), and TCP traffic to port 443 in DE (for the DDNS update API). The latter is necessary since I use an upstream proxy for everything else otherwise, but that is located behind an IPsec connection, so there is a chicken-and-egg-problem here. Therefore, calls to the DDNS update API have to happen directly, not via the upstream proxy. This scenario has been working fine for years, and is still working fine for other IPFire machines I administer, running Core Update 164. After a second, scheduled reboot at night of IPFire, the OUTGOINGFW iptables chain looks like this: Chain OUTGOINGFW (1 references) pkts bytes target prot opt in out source destination [outgoing rules for configured DoT servers, omitted for brevity] 73 5548 ACCEPT udp -- * ppp0 85.xxx.xxx.xxx 0.0.0.0/0 udp dpt:123 0 0 ACCEPT ah -- * * 85.xxx.xxx.xxx 185.xxx.xxx.xxx 0 0 ACCEPT ah -- * * 85.xxx.xxx.xxx 185.xxx.xxx.xxx 0 0 ACCEPT esp -- * * 85.xxx.xxx.xxx 185.xxx.xxx.xxx 0 0 ACCEPT esp -- * * 85.xxx.xxx.xxx 185.xxx.xxx.xxx 0 0 ACCEPT tcp -- * * 85.xxx.xxx.xxx 185.xxx.xxx.xxx tcp dpt:500 0 0 ACCEPT tcp -- * * 85.xxx.xxx.xxx 185.xxx.xxx.xxx tcp dpt:500 0 0 ACCEPT udp -- * * 85.xxx.xxx.xxx 185.xxx.xxx.xxx multiport dports 4500,500 0 0 ACCEPT udp -- * * 85.xxx.xxx.xxx 185.xxx.xxx.xxx multiport dports 4500,500 [outgoing rules for Whois communication to RIR Whois servers, omitted for brevity] 10 700 ACCEPT icmp -- * ppp0 85.xxx.xxx.xxx 0.0.0.0/0 match-set DE dst [outgoing rules for IPsec and OpenVPN communication, omitted for brevity] Here, only the location-based rule for permitting ICMP traffic is present, not the other one permitting HTTPS traffic. I had to manually reload the firewall engine to get the desired iptables state again, which is as follows: Chain OUTGOINGFW (1 references) pkts bytes target prot opt in out source destination [outgoing rules for configured DoT servers, omitted for brevity] 0 0 ACCEPT udp -- * ppp0 85.xxx.xxx.xxx 0.0.0.0/0 udp dpt:123 1 60 ACCEPT tcp -- * ppp0 85.xxx.xxx.xxx 0.0.0.0/0 tcp dpt:443 match-set DE dst <<<<< These rules are all configured in the GUI, but were 0 0 ACCEPT ah -- * ppp0 85.xxx.xxx.xxx 0.0.0.0/0 match-set DE dst <<<<< missing after a reboot, rendering DDNS unusable since 0 0 ACCEPT esp -- * ppp0 85.xxx.xxx.xxx 0.0.0.0/0 match-set DE dst <<<<< update calls to the API were not permitted. Oddly, they 0 0 ACCEPT tcp -- * ppp0 85.xxx.xxx.xxx 0.0.0.0/0 tcp dpt:500 match-set DE dst <<<<< all involve a location, but since the ICMP rule to DE 0 0 ACCEPT udp -- * ppp0 85.xxx.xxx.xxx 0.0.0.0/0 multiport dports 4500,500 match-set DE dst <<<<< _was_ present, there does not seem to be a general problem. 0 0 ACCEPT ah -- * * 85.xxx.xxx.xxx 185.xxx.xxx.xxx 0 0 ACCEPT ah -- * * 85.xxx.xxx.xxx 185.xxx.xxx.xxx 0 0 ACCEPT esp -- * * 85.xxx.xxx.xxx 185.xxx.xxx.xxx 0 0 ACCEPT esp -- * * 85.xxx.xxx.xxx 185.xxx.xxx.xxx 0 0 ACCEPT tcp -- * * 85.xxx.xxx.xxx 185.xxx.xxx.xxx tcp dpt:500 0 0 ACCEPT tcp -- * * 85.xxx.xxx.xxx 185.xxx.xxx.xxx tcp dpt:500 0 0 ACCEPT udp -- * * 85.xxx.xxx.xxx 185.xxx.xxx.xxx multiport dports 4500,500 0 0 ACCEPT udp -- * * 85.xxx.xxx.xxx 185.xxx.xxx.xxx multiport dports 4500,500 [outgoing rules for Whois communication to RIR Whois servers, omitted for brevity] 0 0 ACCEPT icmp -- * ppp0 85.xxx.xxx.xxx 0.0.0.0/0 match-set DE dst [outgoing rules for IPsec and OpenVPN communication, omitted for brevity] So far, this has only happened once, but I believe it is a blocker for C165. Should this bug happen again, I will update this ticket. @Stefan: I take the liberty to assign this to you, since I believe it has something to do with the ipset/xt_geoip-related changes in C165. Perhaps you can reproduce it - let me know if any help or further information is required.
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. :-)
https://blog.ipfire.org/post/ipfire-2-27-core-update-165-released