From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Forcing DNS/NTP V2 - new approach Date: Thu, 07 Jan 2021 11:47:03 +0000 Message-ID: In-Reply-To: <73c3712d-2c60-fe92-1ddd-f0fee6ac67ac@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2473097603624137267==" List-Id: --===============2473097603624137267== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 30 Dec 2020, at 08:28, Matthias Fischer = wrote: >=20 > Hi, >=20 > since restarting the *whole* firewall through '/etc/rc.d/init.d/firewall > restart' as I did before is NOT an option, I'm thinking about another - > simpler way - to do this. >=20 > As Michael wrote "There are plenty of temporary rules that are being > created and which simply will get lost after restarting the firewall. > Mainly this affects IPsec, but also QoS." >=20 > For me - and of course for everybody who uses IPSec or QoS - this is a > showstopper. Saving the affected - temporary rules - is too complicated > (for me). I'm trying to make this as simple as possible. Independently from all of this DNS stuff, I would still be interested in this= feature. It would be possible to stop IPsec, then flush the firewall and start it agai= n. Tunnels would of course be gone for a brief moment, but that should not be to= o disruptive. I am not sure how we can make this clear when someone hits the = =E2=80=9CSave=E2=80=9D button that this could disrupt things. > So I'm thinking about separating the DNS/NTP-commands and use them in a > another init-file, apart from the firewall initscript. > I just want to "go out of the way". ;-) >=20 > As I see it, IPSec and QoS (e.g) would not be affected and furthermore > we would perhaps have the choice to control some other settings through > this file. > E.g., the settings from '/var/ipfire/optionsfw/settings' are processed > in various control files, see: > https://community.ipfire.org/t/forcing-all-dns-traffic-from-the-lan-to-the-= firewall/3512/89 >=20 > And perhaps that would give us the chance to tidy things up. Just a thought. I like tidying things up. > So what about using an 'optionsfw' initscript for the DNS/NTP rules? >=20 > This and *only* this file would be started through "Save and Restart' on > 'optionsfw.cgi', using a new binary. As before, this would be > 'optionsfwctrl(.c)', now just containing a call of > '/etc/rc.d/init.d/optionsfw'. Controlling other settings could be added > as needed. A complete firewall restart is NOT initiated. That would be possible, too. Right now we simply do not have some things in s= eparate functions that we could only reload the parts that we want. Most of t= he firewall is static anyways and wherever we have dynamic rules, those are i= n a chain that could be flushed and then recreated. > In this init, the existence of the needed values is first checked, and > only processed if they exist (e.g.): > ... > if [ -z "$DNS_FORCE_ON_GREEN" ] && [ "$DNS_FORCE_ON_GREEN" =3D=3D "on" ]; t= hen > ... This is very redundant. If you want to check for =E2=80=9Con=E2=80=9D, that i= mplies that the variable isn=E2=80=99t empty. It if it empty, you do not care. > The only affected chain is CUSTOMPREROUTING, so other > functionalities/chains (IPSec, QoS) should not be affected. >=20 > May I ask for your opinions? ;-) >=20 > Best, > Matthias -Michael --===============2473097603624137267==--