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-firewall/3512/91

['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