Hi,
to keep this discussion going, I'd like to publish some code that is already running here and ask for some hints. As Jon used to say: "Please don't hurt me". ;-)
I'm *not* sending this through patchwork - I strongly think this is not ready yet. Opinions?
The following seems to work as I want, but I'm at a point where I know what I want the code to do - but he/it has other thoughts. The last step is not working yet.
As in my previous post I "Slightly shortened, kept the relevant parts", current patches are based on 'next'.
On 15.11.2020 15:50, Michael Tremer wrote:
.... This would probably go into /etc/init.d/firewall.
Done. Done right?
Sorry, but *which* line? I'm really not sure. I suppose somewhere after line 179f which read: ... iptables -t nat -N CUSTOMPREROUTING iptables -t nat -A PREROUTING -j CUSTOMPREROUTING ...
I don't want to mess things up - especially in *this* script! We need an "if"-query to check for ON/OFF there, ok. But the more often I read this script the less sure I am where this code can be inserted best. Where? Hints?
If we do not go with the generic redirection option, I would suggest to put this before the CAPTIVE_PORTAL chain and create another chain with the redirection rules.
I used REDIRECT, see below. Is it ok this way?
To get a start I first altered 'optionsfw.cgi', so that I got '[DNS/NTP]_FORCED_ON_[INTERFACE] options in ''/var/ipfire/optionsfw/settings' (see: 01_force_dns_in_optionsfw.patch).
Here, it was important to me that the corresponding options are only visible if the respective interface is actually available. So if there is no BLUE interface, you don't see any ON/OFF switches for 'DNS/NTP on BLUE' or BLUE logging options. Language strings were altered accordingly.
Screenshot examples: => https://community.ipfire.org/t/forcing-all-dns-traffic-from-the-lan-to-the-f...
['Masquerading on BLUE' is not shown because screenshots were made on a testmachine.]
Then I went to the next problem: how and where to activate?
I used '/etc/rc.d/init.d/firewall' with REDIRECT rules and placed them just behind the CAPITVE_PORTAL_CHAIN, as Michael mentions. I hope, I got the right place (see: 02_force_dns_firewall_init.patch).
To avoid creating duplicate rule entries, I used code like 'if ! iptables -t nat -C..." or 'if iptables -t nat -C..." ("Check for the existence of a rule"). I wanted to be sure that a specific rule would only be created if it doesn't exist. To reduce output noise I added '>/dev/null 2>&1', where necessary. Opinions?
All this seemed to work. Manually testing was ok. If I delete just one rule manually, only the missing rule will be created, I experienced no duplicates. ON/OFF switches worked as expected. But still I have to do the necessary firewall restart in a console session. Hm.
Ok, up to next problem.
Restarting the firewall after making changes: How can I initiate *restarting* the firewall through 'optionsfw.cgi'!? This implements initiating '/etc/rc.d/init.d/firewall restart' and starting 'iptables' and this seems to be a point where I'm stuck. Or do I miss something!?
Like in 'squid', I wanted two buttons: 'Save' and 'Save and restart'.
I found a solution how to code this - perhaps not very professional - really simple, but works. Nearly. (see: 03_firewall_restart_in_optionsfw_cgi.patch
In this patch I'm trying to restart the firewall by adding: ... system("/etc/rc.d/init.d/firewall restart >/dev/null 2>&1 "); ...
Doesn't work.
I tried adding a new prog 'optionsfwctrl' (see: 04_optionsfwctrl.c). Doesn't work either.
I checked rights ("set user id on execution") and played with 'C' (try and error), but no chance. I think, I'm missing something important.
Current situation: If I run 'optionsfwctrl on a root console, it works. Settings are saved. But the firewall restart does not work. I'm not able to initiate '/etc/rc.d/init.d/firewall restart' through the web GUI. DNS/NTP rules won't be applied.
So I got my two buttons, but only ONE is working. The other is only saving, but doesn't restart.
Besides, deactivating these rules would need a complete reboot!? Or do I overlook something?
Yes, this would be true.
We could otherwise create a extra script that is only executed when this is enabled like we do with the captive portal.
Tried this(?), but haven't found the right way yet. How to do?
Because if this should be the case then on the firewall options page the entries that require a restart should be *marked* to make things easier and more clearly. Otherwise you switch ON <-> OFF or vice versa without *really* realising that your changes "need a reboot". The notice "Some options need a reboot to take effect" is not sufficiently meaningful. "Some options..."!? Which?
Yes, I find this quite annoying…
Maybe we should in general move these things to not require a reboot?
I believe reloading the whole firewall is something we can support right now.
I think, I need a 'restart'. Right? How can this be done?
Please correct me if I'm totally wrong with these patches (but it was fun coding this...).
Best, Matthias