From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthias Fischer To: development@lists.ipfire.org Subject: Re: Forcing DNS/NTP V2 - new approach Date: Wed, 06 Jan 2021 19:32:59 +0100 Message-ID: <26281959-0376-1a56-0533-cd5155fbaf32@ipfire.org> In-Reply-To: <4591cbaf45618f11565250305b4300b1e65cc726.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1860303105077493157==" List-Id: --===============1860303105077493157== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 06.01.2021 16:50, Stefan Schantl wrote: > Hello Matthias, Hi Stefan, > in general I like the possibility to force the usage of the local DNS > server by just redirecting all queries to it. This is way more elegant > instead of blocking the requests to any nameservers by firewall rules, > except the local unbound to force it's usage. >=20 > I reviewed your last patch and want to give you some thoughts - may the > can help you: >> ... >> 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. >>=20 >=20 > Yes, this is the reason, why reloading / restarting the whole firewall > should be avoided if possible. I completely dropped this - got a new solution which works, but it could be better. It still uses a new init-file as mentioned below. >> 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. >>=20 >> So what about using an 'optionsfw' initscript for the DNS/NTP rules? >>=20 >=20 > This would be a possible solution, but ends in multiple files which are > doing the same - dealing with firewall rules. Ok. Thats right. I'm now using a new '/etc/rc.d/init.d/dnsntp'-file for this, but...: > This is not very intuitive and hard to maintain. Ok. I see your point. >> ... >>=20 >> The only affected chain is CUSTOMPREROUTING, so other >> functionalities/chains (IPSec, QoS) should not be affected. >=20 > Please do not use one of the CUSTOM firewall chains, they only should > be used by the users to customize their systems. > > I would suggest to use a new chain like "FORCEDREDIRECT" or similar > before the CUSTOMPREROUTING chain. I see two possibilities doing this in '/etc/rc,d/init.d/firewall'. Inserting at line 169: ... iptables -t nat -N FORCEREDIRECT iptables -t nat -A PREROUTING -j FORCEREDIRECT iptables -t nat -N CUSTOMPREROUTING iptables -t nat -A PREROUTING -j CUSTOMPREROUTING ... Or after (e.g): ... # Added for DNS REDIRECTS iptables -t nat -N FORCEREDIRECTS iptables -t nat -I PREROUTING 1 -j FORCEREDIRECTS ... Am I right doing it this way? > This would have the advantage, that you safely can flush this chain and > directly can insert you redirect rules for the network zones and > desired the protocol. So you not need to check each time if the rule > already exists. >=20 > This will speeds up the whole process and keeps the code clear. Makes sense. Thanks for the hints. > Instead of writing an additional init script for adding the rules you > directly can execute the iptables calls by your new optionsfw binary.=20 I didn't do this before: I'll take a look. > This allows you to easily call the binary from the CGI file and perform > all required operations inside the single chain without touching > anything else on the running firewall. Yep. I see. Good point. Thanks again. ;-) Best, Matthias --===============1860303105077493157==--