Re: Forcing DNS/NTP V2 - new approach

[Matthias Fischer <matthias.fischer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 3612 bytes --]

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.
> 
> 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.
>> 
> 
> 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". ;-)
>> 
>> 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
>> 
>> And perhaps that would give us the chance to tidy things up. Just a
>> thought.
>> 
>> So what about using an 'optionsfw' initscript for the DNS/NTP rules?
>> 
> 
> 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.

>> ...
>> 
>> The only affected chain is CUSTOMPREROUTING, so other
>> functionalities/chains (IPSec, QoS) should not be affected.
> 
> 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.
> 
> 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. 

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