Forcing all DNS traffic from the LAN to the firewall

Forcing all DNS traffic from the LAN to the firewall

[Matthias Fischer]

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

Hi,

there have been several discussions with several solution attempts in
both IPFire forums (old/new), generally starting with (e.g.) "...I am
trying to redirect all of my DNS traffic to go thru the IPFire DNS
instead of directly to an outside DNS server...".

Current discussion =>
https://community.ipfire.org/t/forcing-all-dns-traffic-from-the-lan-to-the-firewall/3512

But not only in the forums - the oldest Wiki article is dated "May 22,
2015". Long time, but still editing scripts manually...

Hoping that there is a chance for a (final) integrated solution which
doesn't include editing code, but having a checkbox to switch this
functionality ON/OFF on a standardized and more secure base, I would
like to open a discussion on the list.

For a start and to test how this could probably be done - and to find
out if I can do it - I customized '/srv/web/ipfire/cgi-bin/optionsfw.cgi'.

Screenshots of the result can be found in the forum thread cited above:
=>
https://community.ipfire.org/t/forcing-all-dns-traffic-from-the-lan-to-the-firewall/3512/91

But some points are IMHO still unclear and need clarification. And I
think I'm not the one to decide where to go...

My thoughts until now:

- Do we need this?
  [Hm. ;-) As I heard, some folks do.]

- Is the 'optionsfwcgi' the right place for this?
  [In my opinion: yes. It was easy to add and sits beside other
interface "options"]

- Do we really want this for all installations?
  [For someone, who doesn't want or doesn't need it: it can be switched OFF]

- Is this function usable under ALL circumstances?
  [If not: it can be switched OFF]

- Where (E.g: firewall init script, rules.pl, wirelessctrl.c, ...)
should the necessary iptables rules be processed?
  [Some ideas how this could be done, but no "breakthrough". Current
option-settings are processed in several scripts. Which one to use!?]

Before going on and investing more time in this (on the forum), I'd like
to know how the developers think about this and would like to collect
ideas and suggestions here.

Any hints are welcome...

Best,
Matthias

Re: Forcing all DNS traffic from the LAN to the firewall

[Tapani Tarvainen]

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

Hi,

Just two quick points:

(1) In general changes like this that could break existing installations
should be left off by default, letting just those who want it turn it on.

(2) This has already become almost moot by the ever-increasing use of DoH.
On the other hand, unbound already supports DoH, so how about enabling it
in IPFire, too?

Tapani

On Mon, Nov 09, 2020 at 06:47:26PM +0100, Matthias Fischer (matthias.fischer(a)ipfire.org) wrote:
> 
> Hi,
> 
> there have been several discussions with several solution attempts in
> both IPFire forums (old/new), generally starting with (e.g.) "...I am
> trying to redirect all of my DNS traffic to go thru the IPFire DNS
> instead of directly to an outside DNS server...".
> 
> Current discussion =>
> https://community.ipfire.org/t/forcing-all-dns-traffic-from-the-lan-to-the-firewall/3512
> 
> But not only in the forums - the oldest Wiki article is dated "May 22,
> 2015". Long time, but still editing scripts manually...
> 
> Hoping that there is a chance for a (final) integrated solution which
> doesn't include editing code, but having a checkbox to switch this
> functionality ON/OFF on a standardized and more secure base, I would
> like to open a discussion on the list.
> 
> For a start and to test how this could probably be done - and to find
> out if I can do it - I customized '/srv/web/ipfire/cgi-bin/optionsfw.cgi'.
> 
> Screenshots of the result can be found in the forum thread cited above:
> =>
> https://community.ipfire.org/t/forcing-all-dns-traffic-from-the-lan-to-the-firewall/3512/91
> 
> But some points are IMHO still unclear and need clarification. And I
> think I'm not the one to decide where to go...
> 
> My thoughts until now:
> 
> - Do we need this?
>   [Hm. ;-) As I heard, some folks do.]
> 
> - Is the 'optionsfwcgi' the right place for this?
>   [In my opinion: yes. It was easy to add and sits beside other
> interface "options"]
> 
> - Do we really want this for all installations?
>   [For someone, who doesn't want or doesn't need it: it can be switched OFF]
> 
> - Is this function usable under ALL circumstances?
>   [If not: it can be switched OFF]
> 
> - Where (E.g: firewall init script, rules.pl, wirelessctrl.c, ...)
> should the necessary iptables rules be processed?
>   [Some ideas how this could be done, but no "breakthrough". Current
> option-settings are processed in several scripts. Which one to use!?]
> 
> Before going on and investing more time in this (on the forum), I'd like
> to know how the developers think about this and would like to collect
> ideas and suggestions here.
> 
> Any hints are welcome...
> 
> Best,
> Matthias

-- 
Tapani Tarvainen

Re: Forcing all DNS traffic from the LAN to the firewall

[Rainer Kemme]

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

Hello,

Am 09.11.2020 um 18:47 schrieb Matthias Fischer:
> 
> "...I am trying to redirect all of my DNS traffic to go thru the
> IPFire DNS instead of directly to an outside DNS server...".
Before I replaced the old ZyXEL ZyWALL 35 by IPFire I intercepted / 
Redirected UDP 53 (DNS) and UDP 123 (NTP) using the ZyWALLs so called 
policy routing:

Based on the policy I redirected UDP 53,123 to one of my Linux machines.

On the Linux maschine I defined IPTABLE rules in order to redirect the 
requests to my favorite (internal) DNS-Server.

A rule for the request:
   iptables -t nat
            -A PREROUTING
            -p udp
            -s 172.22.100.0/22
          ! -d 172.22.0.0/16
           --dport 53
            -j DNAT
          --to 172.22.10.181

A rule for the reply:
   iptables -t nat
            -A POSTROUTING
            -p udp
            -s 172.22.100.0/22
            -d 172.22.10.181
           --dport 53
            -j SNAT
           --to 172.22.10.179

My LAN:
   172.22.0.0/16
The requesting range:
   172.22.100.0/22
The Linux machine
   172.22.10.179
My DNS-Server
   172.22.10.181

So, what I would appreciate in IPFire is a policy based routing :-)

Regards,
   Rainer

Re: Forcing all DNS traffic from the LAN to the firewall

[Michael Tremer]

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

Hi Matthias,

Sorry for my late reply. I am surprised this discussion is so quiet.

> On 9 Nov 2020, at 17:47, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
> 
> Hi,
> 
> there have been several discussions with several solution attempts in
> both IPFire forums (old/new), generally starting with (e.g.) "...I am
> trying to redirect all of my DNS traffic to go thru the IPFire DNS
> instead of directly to an outside DNS server...".
> 
> Current discussion =>
> https://community.ipfire.org/t/forcing-all-dns-traffic-from-the-lan-to-the-firewall/3512
> 
> But not only in the forums - the oldest Wiki article is dated "May 22,
> 2015". Long time, but still editing scripts manually...
> 
> Hoping that there is a chance for a (final) integrated solution which
> doesn't include editing code, but having a checkbox to switch this
> functionality ON/OFF on a standardized and more secure base, I would
> like to open a discussion on the list.

Very good. I like a discussion.

> For a start and to test how this could probably be done - and to find
> out if I can do it - I customized '/srv/web/ipfire/cgi-bin/optionsfw.cgi'.
> 
> Screenshots of the result can be found in the forum thread cited above:
> =>
> https://community.ipfire.org/t/forcing-all-dns-traffic-from-the-lan-to-the-firewall/3512/91
> 
> But some points are IMHO still unclear and need clarification. And I
> think I'm not the one to decide where to go...
> 
> My thoughts until now:
> 
> - Do we need this?
>  [Hm. ;-) As I heard, some folks do.]

Very good question.

I do not entirely understand the use-case for this. And I think nobody has shown an example at all here.

So what I could come up with is this:

* You have a host on your network that does not use your DNS servers.

* You have a host on your network that does not allow you to put in custom DNS servers.

I would simply say: Throw them away. That is not network equipment. It simply is a bug, and that should not be fixed by us.

* You might have a host or an app (YouTube is my favourite) that simply does not give a fuck about your network configuration and will try to break any filtering either by DNS or proxy just to show you advertising and to increase $BIGCORP’s revenue.

I consider that malware or simply broken.

Should we fix that by redirecting? I don’t think so.

I would say that that checkbox that you have added should block using any other DNS server except the ones configured by the DHCP server.

As an admin you want to know what is going wrong and not silently redirect this.

If you really really want to redirect, I think the best option is to add that functionality to the firewall UI that users can create a rule that redirects this traffic. That way it is absolutely explicit and the admin hopefully knows what they are doing.

> - Is the 'optionsfwcgi' the right place for this?
>  [In my opinion: yes. It was easy to add and sits beside other
> interface "options"]

Yes. I believe this is the right place.

> - Do we really want this for all installations?
>  [For someone, who doesn't want or doesn't need it: it can be switched OFF]

Default must be OFF. We should not tamper with people’s packets.

Apart from blocking packets, IPFire’s most popular feature is forwarding them.

> - Is this function usable under ALL circumstances?
>  [If not: it can be switched OFF]

No, I believe that this should be the exception and users can switch it on if they want to.

> - Where (E.g: firewall init script, rules.pl, wirelessctrl.c, ...)
> should the necessary iptables rules be processed?
>  [Some ideas how this could be done, but no "breakthrough". Current
> option-settings are processed in several scripts. Which one to use!?]

This would probably go into /etc/init.d/firewall.

> Before going on and investing more time in this (on the forum), I'd like
> to know how the developers think about this and would like to collect
> ideas and suggestions here.

I hope I could answer the questions.

I would like to hear more opinions.

Best,
-Michael

> 
> Any hints are welcome...
> 
> Best,
> Matthias
> 

Re: Forcing all DNS traffic from the LAN to the firewall

[Michael Tremer]

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

Hi,

> On 10 Nov 2020, at 13:07, Tapani Tarvainen <ipfire(a)tapanitarvainen.fi> wrote:
> 
> Hi,
> 
> Just two quick points:
> 
> (1) In general changes like this that could break existing installations
> should be left off by default, letting just those who want it turn it on.
> 
> (2) This has already become almost moot by the ever-increasing use of DoH.
> On the other hand, unbound already supports DoH, so how about enabling it
> in IPFire, too?

I do not see how that would be possible with dynamic configuration of clients with DHCP and getting some sort of valid certificate for the DNS service.

-Michael

> 
> Tapani
> 
> On Mon, Nov 09, 2020 at 06:47:26PM +0100, Matthias Fischer (matthias.fischer(a)ipfire.org) wrote:
>> 
>> Hi,
>> 
>> there have been several discussions with several solution attempts in
>> both IPFire forums (old/new), generally starting with (e.g.) "...I am
>> trying to redirect all of my DNS traffic to go thru the IPFire DNS
>> instead of directly to an outside DNS server...".
>> 
>> Current discussion =>
>> https://community.ipfire.org/t/forcing-all-dns-traffic-from-the-lan-to-the-firewall/3512
>> 
>> But not only in the forums - the oldest Wiki article is dated "May 22,
>> 2015". Long time, but still editing scripts manually...
>> 
>> Hoping that there is a chance for a (final) integrated solution which
>> doesn't include editing code, but having a checkbox to switch this
>> functionality ON/OFF on a standardized and more secure base, I would
>> like to open a discussion on the list.
>> 
>> For a start and to test how this could probably be done - and to find
>> out if I can do it - I customized '/srv/web/ipfire/cgi-bin/optionsfw.cgi'.
>> 
>> Screenshots of the result can be found in the forum thread cited above:
>> =>
>> https://community.ipfire.org/t/forcing-all-dns-traffic-from-the-lan-to-the-firewall/3512/91
>> 
>> But some points are IMHO still unclear and need clarification. And I
>> think I'm not the one to decide where to go...
>> 
>> My thoughts until now:
>> 
>> - Do we need this?
>>  [Hm. ;-) As I heard, some folks do.]
>> 
>> - Is the 'optionsfwcgi' the right place for this?
>>  [In my opinion: yes. It was easy to add and sits beside other
>> interface "options"]
>> 
>> - Do we really want this for all installations?
>>  [For someone, who doesn't want or doesn't need it: it can be switched OFF]
>> 
>> - Is this function usable under ALL circumstances?
>>  [If not: it can be switched OFF]
>> 
>> - Where (E.g: firewall init script, rules.pl, wirelessctrl.c, ...)
>> should the necessary iptables rules be processed?
>>  [Some ideas how this could be done, but no "breakthrough". Current
>> option-settings are processed in several scripts. Which one to use!?]
>> 
>> Before going on and investing more time in this (on the forum), I'd like
>> to know how the developers think about this and would like to collect
>> ideas and suggestions here.
>> 
>> Any hints are welcome...
>> 
>> Best,
>> Matthias
> 
> -- 
> Tapani Tarvainen

Re: Forcing all DNS traffic from the LAN to the firewall

[Tapani Tarvainen]

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

On Fri, Nov 13, 2020 at 02:24:23PM +0000, Michael Tremer (michael.tremer(a)ipfire.org) wrote:

> > unbound already supports DoH, so how about enabling it
> > in IPFire, too?

> I do not see how that would be possible with dynamic configuration
> of clients with DHCP and getting some sort of valid certificate for
> the DNS service.

Well enabling DoH in IPFire should be reasonably easy. Actually
getting clients to use it, yeah, hard to automate or enforce, unless
you have an environment where you centrally control browser
configurations.

Which does make it questionable if having DoH in IPFire would be
useful. Not very right now, I guess, beyond allowing people to
experiment with it. But that may change.

Anyway, not urgent, but something to keep in mind, in the list of
things that may be needed sooner or later. (Even unbound only
implemented it this October.)

-- 
Tapani Tarvainen

Re: Forcing all DNS traffic from the LAN to the firewall

[Tapani Tarvainen]

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

On Fri, Nov 13, 2020 at 02:23:10PM +0000, Michael Tremer (michael.tremer(a)ipfire.org) wrote:

> > - Do we need this?
> >  [Hm. ;-) As I heard, some folks do.]
> 
> Very good question.
> 
> I do not entirely understand the use-case for this. And I think
> nobody has shown an example at all here.

Agreed. The use case has been dubious to begin with, and as noted
DoH is making it increasingly so.

> So what I could come up with is this:
> 
> * You have a host on your network that does not use your DNS servers.
> 
> * You have a host on your network that does not allow you to put in custom DNS servers.
>
> I would simply say: Throw them away. That is not network equipment.
> It simply is a bug, and that should not be fixed by us.

Agreed.

But I guess the situation some people have in mind is that you have
*users* in your network you can't really control or trust not to mess
up with DNS settings in their machines. As in, children.

But any kid smart enough to change DNS settings in their laptop or
whatever is also smart enough to work around such redirection.

> I would say that that checkbox that you have added should block
> using any other DNS server except the ones configured by the DHCP
> server.

Yes. That'd be better, although even its usefulness is doubtful.

> As an admin you want to know what is going wrong and not silently
> redirect this.

You should. At best it would give you an excuse, a way to claim you
tried to prevent <whatever>. Might be useful in a school or a library
in some places...

But I seriously dislike such reasons and don't think IPFire should
cave in even if someone actually argues for them (not that people
are likely to, as it'd obviously undermine them!).

> If you really really want to redirect, I think the best option is to
> add that functionality to the firewall UI that users can create a
> rule that redirects this traffic. That way it is absolutely explicit
> and the admin hopefully knows what they are doing.

I could live with that, even if I doubt the need.

Actually I'd prefer a generic mechanism for setting redirections
for whatever types of packets. But not a high priority for me.

-- 
Tapani Tarvainen

Re: Forcing all DNS traffic from the LAN to the firewall

[Matthias Fischer]

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

On 13.11.2020 15:23, Michael Tremer wrote:
> Hi Matthias,

Hi,

> Sorry for my late reply. I am surprised this discussion is so quiet.

Me, too. ;-)

>> On 9 Nov 2020, at 17:47, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>> 
>> Hi,
>> 
>> there have been several discussions with several solution attempts in
>> both IPFire forums (old/new), generally starting with (e.g.) "...I am
>> trying to redirect all of my DNS traffic to go thru the IPFire DNS
>> instead of directly to an outside DNS server...".
>> 
>> Current discussion =>
>> https://community.ipfire.org/t/forcing-all-dns-traffic-from-the-lan-to-the-firewall/3512
>> 
>> But not only in the forums - the oldest Wiki article is dated "May 22,
>> 2015". Long time, but still editing scripts manually...
>> 
>> Hoping that there is a chance for a (final) integrated solution which
>> doesn't include editing code, but having a checkbox to switch this
>> functionality ON/OFF on a standardized and more secure base, I would
>> like to open a discussion on the list.
> 
> Very good. I like a discussion.
> 
>> For a start and to test how this could probably be done - and to find
>> out if I can do it - I customized '/srv/web/ipfire/cgi-bin/optionsfw.cgi'.
>> 
>> Screenshots of the result can be found in the forum thread cited above:
>> =>
>> https://community.ipfire.org/t/forcing-all-dns-traffic-from-the-lan-to-the-firewall/3512/91
>> 
>> But some points are IMHO still unclear and need clarification. And I
>> think I'm not the one to decide where to go...
>> 
>> My thoughts until now:
>> 
>> - Do we need this?
>>  [Hm. ;-) As I heard, some folks do.]
> 
> Very good question.
> 
> I do not entirely understand the use-case for this. And I think nobody has shown an example at all here.
> 
> So what I could come up with is this:
> 
> * You have a host on your network that does not use your DNS servers.

I have. Smartphones. *sigh*

> * You have a host on your network that does not allow you to put in custom DNS servers.

Yep. Not only one host, but some Apps on several hosts doesn't. On
smartphones. Every now and then. Again: *sigh*

> I would simply say: Throw them away. That is not network equipment. It simply is a bug, and that should not be fixed by us.

M2C: This would be consistent, but unfortunately this is not always
possible.

> * You might have a host or an app (YouTube is my favourite) that simply does not give a fuck about your network configuration and will try to break any filtering either by DNS or proxy just to show you advertising and to increase $BIGCORP’s revenue.
> 
> I consider that malware or simply broken.

ACK, but...see above. In reality it seems to me that its not that easy.

> Should we fix that by redirecting? I don’t think so.
> 
> I would say that that checkbox that you have added should block using any other DNS server except the ones configured by the DHCP server.

ACK. That is the goal.

> As an admin you want to know what is going wrong and not silently redirect this.
> 
> If you really really want to redirect, I think the best option is to add that functionality to the firewall UI that users can create a rule that redirects this traffic. That way it is absolutely explicit and the admin hopefully knows what they are doing.
> 
>> - Is the 'optionsfwcgi' the right place for this?
>>  [In my opinion: yes. It was easy to add and sits beside other
>> interface "options"]
> 
> Yes. I believe this is the right place.
> 
>> - Do we really want this for all installations?
>>  [For someone, who doesn't want or doesn't need it: it can be switched OFF]
> 
> Default must be OFF. We should not tamper with people’s packets.

I see. Perhaps I wasn't clear enough: of course the default should be
switched OFF.

> Apart from blocking packets, IPFire’s most popular feature is forwarding them.
> 
>> - Is this function usable under ALL circumstances?
>>  [If not: it can be switched OFF]
> 
> No, I believe that this should be the exception and users can switch it on if they want to.

Yep. See above.

>> - Where (E.g: firewall init script, rules.pl, wirelessctrl.c, ...)
>> should the necessary iptables rules be processed?
>>  [Some ideas how this could be done, but no "breakthrough". Current
>> option-settings are processed in several scripts. Which one to use!?]
> 
> This would probably go into /etc/init.d/firewall.

Ok.

>> Before going on and investing more time in this (on the forum), I'd like
>> to know how the developers think about this and would like to collect
>> ideas and suggestions here.
> 
> I hope I could answer the questions.

Yes. ;-)

> I would like to hear more opinions.

Me, too. And feedback from testers... ;-)

Best,
Matthias

> Best,
> -Michael
> 
>> 
>> Any hints are welcome...
>> 
>> Best,
>> Matthias
>> 
> 

Re: Forcing all DNS traffic from the LAN to the firewall

[Paul Simmons]

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

On 11/13/20 10:57 AM, Matthias Fischer wrote:
> On 13.11.2020 15:23, Michael Tremer wrote:
>> Hi Matthias,
> Hi,
>
>> Sorry for my late reply. I am surprised this discussion is so quiet.
> Me, too. ;-)
>
>>> On 9 Nov 2020, at 17:47, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>>
>>> Hi,
>>>
>>> there have been several discussions with several solution attempts in
>>> both IPFire forums (old/new), generally starting with (e.g.) "...I am
>>> trying to redirect all of my DNS traffic to go thru the IPFire DNS
>>> instead of directly to an outside DNS server...".
>>>
>>> Current discussion =>
>>> https://community.ipfire.org/t/forcing-all-dns-traffic-from-the-lan-to-the-firewall/3512
>>>
>>> But not only in the forums - the oldest Wiki article is dated "May 22,
>>> 2015". Long time, but still editing scripts manually...
>>>
>>> Hoping that there is a chance for a (final) integrated solution which
>>> doesn't include editing code, but having a checkbox to switch this
>>> functionality ON/OFF on a standardized and more secure base, I would
>>> like to open a discussion on the list.
>> Very good. I like a discussion.
>>
>>> For a start and to test how this could probably be done - and to find
>>> out if I can do it - I customized '/srv/web/ipfire/cgi-bin/optionsfw.cgi'.
>>>
>>> Screenshots of the result can be found in the forum thread cited above:
>>> =>
>>> https://community.ipfire.org/t/forcing-all-dns-traffic-from-the-lan-to-the-firewall/3512/91
>>>
>>> But some points are IMHO still unclear and need clarification. And I
>>> think I'm not the one to decide where to go...
>>>
>>> My thoughts until now:
>>>
>>> - Do we need this?
>>>   [Hm. ;-) As I heard, some folks do.]
>> Very good question.
>>
>> I do not entirely understand the use-case for this. And I think nobody has shown an example at all here.
>>
>> So what I could come up with is this:
>>
>> * You have a host on your network that does not use your DNS servers.
> I have. Smartphones. *sigh*
>
>> * You have a host on your network that does not allow you to put in custom DNS servers.
> Yep. Not only one host, but some Apps on several hosts doesn't. On
> smartphones. Every now and then. Again: *sigh*
>
>> I would simply say: Throw them away. That is not network equipment. It simply is a bug, and that should not be fixed by us.
> M2C: This would be consistent, but unfortunately this is not always
> possible.
>
>> * You might have a host or an app (YouTube is my favourite) that simply does not give a fuck about your network configuration and will try to break any filtering either by DNS or proxy just to show you advertising and to increase $BIGCORP’s revenue.
>>
>> I consider that malware or simply broken.
> ACK, but...see above. In reality it seems to me that its not that easy.
>
>> Should we fix that by redirecting? I don’t think so.
>>
>> I would say that that checkbox that you have added should block using any other DNS server except the ones configured by the DHCP server.
> ACK. That is the goal.
>
>> As an admin you want to know what is going wrong and not silently redirect this.
>>
>> If you really really want to redirect, I think the best option is to add that functionality to the firewall UI that users can create a rule that redirects this traffic. That way it is absolutely explicit and the admin hopefully knows what they are doing.
>>
>>> - Is the 'optionsfwcgi' the right place for this?
>>>   [In my opinion: yes. It was easy to add and sits beside other
>>> interface "options"]
>> Yes. I believe this is the right place.
>>
>>> - Do we really want this for all installations?
>>>   [For someone, who doesn't want or doesn't need it: it can be switched OFF]
>> Default must be OFF. We should not tamper with people’s packets.
> I see. Perhaps I wasn't clear enough: of course the default should be
> switched OFF.
>
>> Apart from blocking packets, IPFire’s most popular feature is forwarding them.
>>
>>> - Is this function usable under ALL circumstances?
>>>   [If not: it can be switched OFF]
>> No, I believe that this should be the exception and users can switch it on if they want to.
> Yep. See above.
>
>>> - Where (E.g: firewall init script, rules.pl, wirelessctrl.c, ...)
>>> should the necessary iptables rules be processed?
>>>   [Some ideas how this could be done, but no "breakthrough". Current
>>> option-settings are processed in several scripts. Which one to use!?]
>> This would probably go into /etc/init.d/firewall.
> Ok.
>
>>> Before going on and investing more time in this (on the forum), I'd like
>>> to know how the developers think about this and would like to collect
>>> ideas and suggestions here.
>> I hope I could answer the questions.
> Yes. ;-)
>
>> I would like to hear more opinions.
> Me, too. And feedback from testers... ;-)
>
> Best,
> Matthias
>
>> Best,
>> -Michael
>>
>>> Any hints are welcome...
>>>
>>> Best,
>>> Matthias
>>>

+1


Anxiously awaiting decision / implementation.

-- 
Who messed with my anti-paranoia shot?

Re: Forcing all DNS traffic from the LAN to the firewall

[Matthias Fischer]

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

Hi,

On 13.11.2020 15:55, Tapani Tarvainen wrote:
> On Fri, Nov 13, 2020 at 02:23:10PM +0000, Michael Tremer (michael.tremer(a)ipfire.org) wrote:
> ...
>> So what I could come up with is this:
>> 
>> * You have a host on your network that does not use your DNS servers.
>> 
>> * You have a host on your network that does not allow you to put in custom DNS servers.
>>
>> I would simply say: Throw them away. That is not network equipment.
>> It simply is a bug, and that should not be fixed by us.
> 
> Agreed.
> 
> But I guess the situation some people have in mind is that you have
> *users* in your network you can't really control or trust not to mess
> up with DNS settings in their machines. As in, children.

Or you have *machines* (in this case, Apps) you can't control, because
they don't even have an input field for "DNS".

> But any kid smart enough to change DNS settings in their laptop or
> whatever is also smart enough to work around such redirection.

I'm curious. How could this be done? I have tested the REDIRECT rules
with various arbitrary entries, even with non-existing addresses. So
far, DNS queries were always redirected to the DNS servers specified in
IPFire until now. I even didn't notice that I tested withirregular or
invalid addresses.

...

Best,
Matthias

Re: Forcing all DNS traffic from the LAN to the firewall

[Matthias Fischer]

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

Hi,

On 13.11.2020 17:57, Matthias Fischer wrote:
> On 13.11.2020 15:23, Michael Tremer wrote:

[Slightly shortened, kept the relevant parts]

>> ... 
> 
>>> - Where (E.g: firewall init script, rules.pl, wirelessctrl.c, ...)
>>> should the necessary iptables rules be processed?
>>>  [Some ideas how this could be done, but no "breakthrough". Current
>>> option-settings are processed in several scripts. Which one to use!?]
>> 
>> This would probably go into /etc/init.d/firewall.

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?

Besides, deactivating these rules would need a complete reboot!? Or do I
overlook something?

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?

Best,
Matthias

Re: Forcing all DNS traffic from the LAN to the firewall

[Michael Tremer]

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

Hi,

> On 13 Nov 2020, at 14:55, Tapani Tarvainen <ipfire(a)tapanitarvainen.fi> wrote:
> 
> On Fri, Nov 13, 2020 at 02:23:10PM +0000, Michael Tremer (michael.tremer(a)ipfire.org) wrote:
> 
>>> - Do we need this?
>>> [Hm. ;-) As I heard, some folks do.]
>> 
>> Very good question.
>> 
>> I do not entirely understand the use-case for this. And I think
>> nobody has shown an example at all here.
> 
> Agreed. The use case has been dubious to begin with, and as noted
> DoH is making it increasingly so.
> 
>> So what I could come up with is this:
>> 
>> * You have a host on your network that does not use your DNS servers.
>> 
>> * You have a host on your network that does not allow you to put in custom DNS servers.
>> 
>> I would simply say: Throw them away. That is not network equipment.
>> It simply is a bug, and that should not be fixed by us.
> 
> Agreed.
> 
> But I guess the situation some people have in mind is that you have
> *users* in your network you can't really control or trust not to mess
> up with DNS settings in their machines. As in, children.

Hmm, I get the problem with children on the network.

But I do not think that the fix is a redirection. The fix is to cut them off the network by simply dropping any packets to any alternative DNS servers. This can simply be configured using the current firewall UI.

For anybody else: If you have people on your network that you do not trust and who might temper with the settings: do not have them on your network.

> But any kid smart enough to change DNS settings in their laptop or
> whatever is also smart enough to work around such redirection.
> 
>> I would say that that checkbox that you have added should block
>> using any other DNS server except the ones configured by the DHCP
>> server.
> 
> Yes. That'd be better, although even its usefulness is doubtful.
> 
>> As an admin you want to know what is going wrong and not silently
>> redirect this.
> 
> You should. At best it would give you an excuse, a way to claim you
> tried to prevent <whatever>. Might be useful in a school or a library
> in some places...
> 
> But I seriously dislike such reasons and don't think IPFire should
> cave in even if someone actually argues for them (not that people
> are likely to, as it'd obviously undermine them!).
> 
>> If you really really want to redirect, I think the best option is to
>> add that functionality to the firewall UI that users can create a
>> rule that redirects this traffic. That way it is absolutely explicit
>> and the admin hopefully knows what they are doing.
> 
> I could live with that, even if I doubt the need.
> 
> Actually I'd prefer a generic mechanism for setting redirections
> for whatever types of packets. But not a high priority for me.

I am currently leaning towards that, too.

That way people can redirect whatever they like and we won’t only limit this to DNS.

I do not see many other reasons why you would need this, but it is indeed a niche feature which some users might need sometimes.

-Michael

> 
> -- 
> Tapani Tarvainen

Re: Forcing all DNS traffic from the LAN to the firewall

[Michael Tremer]

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



> On 15 Nov 2020, at 13:16, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
> 
> Hi,
> 
> On 13.11.2020 15:55, Tapani Tarvainen wrote:
>> On Fri, Nov 13, 2020 at 02:23:10PM +0000, Michael Tremer (michael.tremer(a)ipfire.org) wrote:
>> ...
>>> So what I could come up with is this:
>>> 
>>> * You have a host on your network that does not use your DNS servers.
>>> 
>>> * You have a host on your network that does not allow you to put in custom DNS servers.
>>> 
>>> I would simply say: Throw them away. That is not network equipment.
>>> It simply is a bug, and that should not be fixed by us.
>> 
>> Agreed.
>> 
>> But I guess the situation some people have in mind is that you have
>> *users* in your network you can't really control or trust not to mess
>> up with DNS settings in their machines. As in, children.
> 
> Or you have *machines* (in this case, Apps) you can't control, because
> they don't even have an input field for "DNS".

Do you have any examples?

I have never encountered that, because if they allow static configuration of the IP address, they won’t get a DNS server at all.

For devices that only support DHCP, this might make sense. I have a Philips Hue bridge that does not support static configuration and simply gets a lease from the DHCP server. The intention probably is being all zero-configuration.

>> But any kid smart enough to change DNS settings in their laptop or
>> whatever is also smart enough to work around such redirection.
> 
> I'm curious. How could this be done? I have tested the REDIRECT rules
> with various arbitrary entries, even with non-existing addresses. So
> far, DNS queries were always redirected to the DNS servers specified in
> IPFire until now. I even didn't notice that I tested withirregular or
> invalid addresses.

Proxies. VPNs. Tor. Remotely logging in to another computer - like RDP, VNC, etc.

> ...
> 
> Best,
> Matthias

Re: Forcing all DNS traffic from the LAN to the firewall

[Michael Tremer]

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

Hi,

> On 15 Nov 2020, at 13:36, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
> 
> Hi,
> 
> On 13.11.2020 17:57, Matthias Fischer wrote:
>> On 13.11.2020 15:23, Michael Tremer wrote:
> 
> [Slightly shortened, kept the relevant parts]
> 
>>> ... 
>> 
>>>> - Where (E.g: firewall init script, rules.pl, wirelessctrl.c, ...)
>>>> should the necessary iptables rules be processed?
>>>> [Some ideas how this could be done, but no "breakthrough". Current
>>>> option-settings are processed in several scripts. Which one to use!?]
>>> 
>>> This would probably go into /etc/init.d/firewall.
> 
> 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.

> 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.

> 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.

-Michael

> Best,
> Matthias

Re: Forcing all DNS traffic from the LAN to the firewall

[Tapani Tarvainen]

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

On Sun, Nov 15, 2020 at 02:16:46PM +0100, Matthias Fischer (matthias.fischer(a)ipfire.org) wrote:

> > But I guess the situation some people have in mind is that you have
> > *users* in your network you can't really control or trust not to mess
> > up with DNS settings in their machines. As in, children.
> 
> Or you have *machines* (in this case, Apps) you can't control, because
> they don't even have an input field for "DNS".

... and have their own hardcoded DNS servers instead of trusting what
DHCP says nor any Private DNS configuration in the phone (I presume
you've tried that). Yeah, such abominations do exist.

And if you really can't avoid using them and still really need to be
able to control which addresses they see, I guess port 53 redirection
in the firewall makes sense.

I doubt that's a common enough case to warrant a custom setting in
IPFire, but I don't mind having one (I'm not doing the work after
all).

> > But any kid smart enough to change DNS settings in their laptop or
> > whatever is also smart enough to work around such redirection.

> I'm curious. How could this be done? I have tested the REDIRECT rules
> with various arbitrary entries, even with non-existing addresses. So
> far, DNS queries were always redirected to the DNS servers specified in
> IPFire until now. I even didn't notice that I tested with irregular or
> invalid addresses.

Well, today the easy way is to use DoH.

Or DoT, if you don't block port 853.

Other ways exist for the more nerdy types, from just /etc/hosts to
tunneling DNS via some other port or another app, even over Facebook.
(I was in working Saudi Arabia some 20 years ago when they introduced
Internet there, along with DNS-based censorship - people can be pretty
creative.)

Wardriving isn't an entirely forgotten art either.

And today's kids... you could find a 10-year-old running a virtual
machine in his laptop or a Raspberry Pi with a custom DNS+DHCP server
that fetches the forbidden addresses from his friends over WhatsApp.

-- 
Tapani Tarvainen

Re: Forcing all DNS traffic from the LAN to the firewall

[Tapani Tarvainen]

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

On Sun, Nov 15, 2020 at 02:50:09PM +0000, Michael Tremer (michael.tremer(a)ipfire.org) wrote:

> > deactivating these rules would need a complete reboot!? Or do I
> > overlook something?
> 
> Yes, this would be true.

Why? After all iptables supports deleting (-D) or replacing (-R)
rules anywhere any chain. Turning rules in a custom chain on
or off could be done with a single iptables command.

OK, I guess that'd require non-trivial amount of coding in IPFire.

> Maybe we should in general move these things to not require a reboot?

I'd like that. BTW unbound also supports changes without total reload.

> I believe reloading the whole firewall is something we can support right now.

That would already be helpful.

-- 
Tapani Tarvainen

Re: Forcing all DNS traffic from the LAN to the firewall

[Michael Tremer]

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

Hi,

> On 15 Nov 2020, at 15:33, Tapani Tarvainen <ipfire(a)tapanitarvainen.fi> wrote:
> 
> On Sun, Nov 15, 2020 at 02:16:46PM +0100, Matthias Fischer (matthias.fischer(a)ipfire.org) wrote:
> 
>>> But I guess the situation some people have in mind is that you have
>>> *users* in your network you can't really control or trust not to mess
>>> up with DNS settings in their machines. As in, children.
>> 
>> Or you have *machines* (in this case, Apps) you can't control, because
>> they don't even have an input field for "DNS".
> 
> ... and have their own hardcoded DNS servers instead of trusting what
> DHCP says nor any Private DNS configuration in the phone (I presume
> you've tried that). Yeah, such abominations do exist.

Again, what are those apps?

This is absolutely unacceptable behaviour.

I do not understand how these vendors always try to be “smart” and build these things so that their advertising is always loading, but actually are only causing us to create another hurdle which they will have to find another way to hop over, and so on…

It is a silly game of catch we are playing here.

> And if you really can't avoid using them and still really need to be
> able to control which addresses they see, I guess port 53 redirection
> in the firewall makes sense.
> 
> I doubt that's a common enough case to warrant a custom setting in
> IPFire, but I don't mind having one (I'm not doing the work after
> all).
> 
>>> But any kid smart enough to change DNS settings in their laptop or
>>> whatever is also smart enough to work around such redirection.
> 
>> I'm curious. How could this be done? I have tested the REDIRECT rules
>> with various arbitrary entries, even with non-existing addresses. So
>> far, DNS queries were always redirected to the DNS servers specified in
>> IPFire until now. I even didn't notice that I tested with irregular or
>> invalid addresses.
> 
> Well, today the easy way is to use DoH.
> 
> Or DoT, if you don't block port 853.

We cannot redirect DoT or DoH because the clients would validate the certificate which won’t match.

This is only possible for plain old DNS over UDP or TCP.

> Other ways exist for the more nerdy types, from just /etc/hosts to
> tunneling DNS via some other port or another app, even over Facebook.
> (I was in working Saudi Arabia some 20 years ago when they introduced
> Internet there, along with DNS-based censorship - people can be pretty
> creative.)
> 
> Wardriving isn't an entirely forgotten art either.
> 
> And today's kids... you could find a 10-year-old running a virtual
> machine in his laptop or a Raspberry Pi with a custom DNS+DHCP server
> that fetches the forbidden addresses from his friends over WhatsApp.
> 
> -- 
> Tapani Tarvainen

Re: Forcing all DNS traffic from the LAN to the firewall

[Michael Tremer]

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

Hi,

> On 15 Nov 2020, at 15:44, Tapani Tarvainen <ipfire(a)tapanitarvainen.fi> wrote:
> 
> On Sun, Nov 15, 2020 at 02:50:09PM +0000, Michael Tremer (michael.tremer(a)ipfire.org) wrote:
> 
>>> deactivating these rules would need a complete reboot!? Or do I
>>> overlook something?
>> 
>> Yes, this would be true.
> 
> Why? After all iptables supports deleting (-D) or replacing (-R)
> rules anywhere any chain. Turning rules in a custom chain on
> or off could be done with a single iptables command.
> 
> OK, I guess that'd require non-trivial amount of coding in IPFire.

It is in theory possible, but in practise would be surgically removing firewall rules.

If anyone has some custom changes in here, or if you install an update and the newer version of the script is expecting some changes, this won’t work any more.

Therefore the best way is to have a chain that can be flushed and recreated.

>> Maybe we should in general move these things to not require a reboot?
> 
> I'd like that. BTW unbound also supports changes without total reload.

Which ones?

>> I believe reloading the whole firewall is something we can support right now.
> 
> That would already be helpful.
> 
> -- 
> Tapani Tarvainen

Re: Forcing all DNS traffic from the LAN to the firewall

[Matthias Fischer]

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

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









[-- Attachment #2: 01_force_dns_in_optionsfw_cgi.patch --]
[-- Type: text/plain, Size: 6752 bytes --]

diff -U 3 C:/Compare/force dns/next/html_cgi-bin_optionsfw.cgi C:/Compare/force dns/tuned 01/optionsfw.cgi
--- C:/Compare/force dns/next/html_cgi-bin_optionsfw.cgi	Mon Nov 23 08:52:12 2020
+++ C:/Compare/force dns/tuned 01/optionsfw.cgi	Sun Nov  8 20:17:54 2020
@@ -158,6 +158,18 @@
 $selected{'MASQUERADE_BLUE'}{'off'} = '';
 $selected{'MASQUERADE_BLUE'}{'on'} = '';
 $selected{'MASQUERADE_BLUE'}{$settings{'MASQUERADE_BLUE'}} = 'selected="selected"';
+$checked{'DNS_FORCE_ON_GREEN'}{'off'} = '';
+$checked{'DNS_FORCE_ON_GREEN'}{'on'} = '';
+$checked{'DNS_FORCE_ON_GREEN'}{$settings{'DNS_FORCE_ON_GREEN'}} = "checked='checked'";
+$checked{'DNS_FORCE_ON_BLUE'}{'off'} = '';
+$checked{'DNS_FORCE_ON_BLUE'}{'on'} = '';
+$checked{'DNS_FORCE_ON_BLUE'}{$settings{'DNS_FORCE_ON_BLUE'}} = "checked='checked'";
+$checked{'NTP_FORCE_ON_GREEN'}{'off'} = '';
+$checked{'NTP_FORCE_ON_GREEN'}{'on'} = '';
+$checked{'NTP_FORCE_ON_GREEN'}{$settings{'NTP_FORCE_ON_GREEN'}} = "checked='checked'";
+$checked{'NTP_FORCE_ON_BLUE'}{'off'} = '';
+$checked{'NTP_FORCE_ON_BLUE'}{'on'} = '';
+$checked{'NTP_FORCE_ON_BLUE'}{$settings{'NTP_FORCE_ON_BLUE'}} = "checked='checked'";
 
 &Header::openbox('100%', 'center',);
 print "<form method='post' action='$ENV{'SCRIPT_NAME'}'>";
@@ -207,7 +219,38 @@
 END
 	}
 
-	print <<END
+print <<END;
+	<table width='95%' cellspacing='0'>
+		<tr bgcolor='$color{'color20'}'></tr>
+		<tr>&nbsp;</tr>
+			<td colspan='2' align='left'><b>$Lang::tr{'fw green'}</b></td>
+		</tr>
+		<tr><td align='left' width='60%'>$Lang::tr{'dns force on green'}</td><td align='left'>$Lang::tr{'on'} <input type='radio' name='DNS_FORCE_ON_GREEN' value='on' $checked{'DNS_FORCE_ON_GREEN'}{'on'} />/
+																						<input type='radio' name='DNS_FORCE_ON_GREEN' value='off' $checked{'DNS_FORCE_ON_GREEN'}{'off'} /> $Lang::tr{'off'}</td></tr>
+		<tr><td align='left' width='60%'>$Lang::tr{'ntp force on green'}</td><td align='left'>$Lang::tr{'on'} <input type='radio' name='NTP_FORCE_ON_GREEN' value='on' $checked{'NTP_FORCE_ON_GREEN'}{'on'} />/
+																						<input type='radio' name='NTP_FORCE_ON_GREEN' value='off' $checked{'NTP_FORCE_ON_GREEN'}{'off'} /> $Lang::tr{'off'}</td></tr>
+END
+
+	if (&Header::blue_used()) {
+		print <<END;
+		<table width='95%' cellspacing='0'>
+		<tr bgcolor='$color{'color20'}'><td colspan='2' align='left'><b>$Lang::tr{'fw blue'}</b></td></tr>
+		<tr>&nbsp;</tr>
+			<tr>
+			<tr><td align='left' width='60%'>$Lang::tr{'dns force on blue'}</td><td align='left'>$Lang::tr{'on'} <input type='radio' name='DNS_FORCE_ON_BLUE' value='on' $checked{'DNS_FORCE_ON_BLUE'}{'on'} />/
+																						<input type='radio' name='DNS_FORCE_ON_BLUE' value='off' $checked{'DNS_FORCE_ON_BLUE'}{'off'} /> $Lang::tr{'off'}</td></tr>
+			<tr><td align='left' width='60%'>$Lang::tr{'ntp force on blue'}</td><td align='left'>$Lang::tr{'on'} <input type='radio' name='NTP_FORCE_ON_BLUE' value='on' $checked{'NTP_FORCE_ON_BLUE'}{'on'} />/
+																						<input type='radio' name='NTP_FORCE_ON_BLUE' value='off' $checked{'NTP_FORCE_ON_BLUE'}{'off'} /> $Lang::tr{'off'}</td></tr>
+			<tr><td align='left' width='60%'>$Lang::tr{'drop proxy'}</td><td align='left'>$Lang::tr{'on'} <input type='radio' name='DROPPROXY' value='on' $checked{'DROPPROXY'}{'on'} />/
+																						<input type='radio' name='DROPPROXY' value='off' $checked{'DROPPROXY'}{'off'} /> $Lang::tr{'off'}</td></tr>
+			<tr><td align='left' width='60%'>$Lang::tr{'drop samba'}</td><td align='left'>$Lang::tr{'on'} <input type='radio' name='DROPSAMBA' value='on' $checked{'DROPSAMBA'}{'on'} />/
+																						<input type='radio' name='DROPSAMBA' value='off' $checked{'DROPSAMBA'}{'off'} /> $Lang::tr{'off'}</td></tr>
+			</td>
+			</tr>
+END
+	}
+
+	print <<END;
 	</table>
 
 	<br>
@@ -224,21 +267,25 @@
 																						<input type='radio' name='DROPOUTGOING' value='off' $checked{'DROPOUTGOING'}{'off'} /> $Lang::tr{'off'}</td></tr>
 <tr><td align='left' width='60%'>$Lang::tr{'drop portscan'}</td><td align='left'>$Lang::tr{'on'} <input type='radio' name='DROPPORTSCAN' value='on' $checked{'DROPPORTSCAN'}{'on'} />/
 																						<input type='radio' name='DROPPORTSCAN' value='off' $checked{'DROPPORTSCAN'}{'off'} /> $Lang::tr{'off'}</td></tr>
-<tr><td align='left' width='60%'>$Lang::tr{'drop wirelessinput'}</td><td align='left'>$Lang::tr{'on'} <input type='radio' name='DROPWIRELESSINPUT' value='on' $checked{'DROPWIRELESSINPUT'}{'on'} />/
+END
+
+	if (&Header::blue_used()) {
+		print <<END;
+		<table width='95%' cellspacing='0'>
+			<tr>
+			<tr><td align='left' width='60%'>$Lang::tr{'drop wirelessinput'}</td><td align='left'>$Lang::tr{'on'} <input type='radio' name='DROPWIRELESSINPUT' value='on' $checked{'DROPWIRELESSINPUT'}{'on'} />/
 																						<input type='radio' name='DROPWIRELESSINPUT' value='off' $checked{'DROPWIRELESSINPUT'}{'off'} /> $Lang::tr{'off'}</td></tr>
-<tr><td align='left' width='60%'>$Lang::tr{'drop wirelessforward'}</td><td align='left'>$Lang::tr{'on'} <input type='radio' name='DROPWIRELESSFORWARD' value='on' $checked{'DROPWIRELESSFORWARD'}{'on'} />/
+			<tr><td align='left' width='60%'>$Lang::tr{'drop wirelessforward'}</td><td align='left'>$Lang::tr{'on'} <input type='radio' name='DROPWIRELESSFORWARD' value='on' $checked{'DROPWIRELESSFORWARD'}{'on'} />/
 																						<input type='radio' name='DROPWIRELESSFORWARD' value='off' $checked{'DROPWIRELESSFORWARD'}{'off'} /> $Lang::tr{'off'}</td></tr>
-</table>
-<br/>
+			</tr>
+END
+	}
+
+	print <<END;
+	</table>
+
+	<br/>
 
-<table width='95%' cellspacing='0'>
-<tr bgcolor='$color{'color20'}'><td colspan='2' align='left'><b>$Lang::tr{'fw blue'}</b></td></tr>
-<tr><td align='left' width='60%'>$Lang::tr{'drop proxy'}</td><td align='left'>$Lang::tr{'on'} <input type='radio' name='DROPPROXY' value='on' $checked{'DROPPROXY'}{'on'} />/
-																						<input type='radio' name='DROPPROXY' value='off' $checked{'DROPPROXY'}{'off'} /> $Lang::tr{'off'}</td></tr>
-<tr><td align='left' width='60%'>$Lang::tr{'drop samba'}</td><td align='left'>$Lang::tr{'on'} <input type='radio' name='DROPSAMBA' value='on' $checked{'DROPSAMBA'}{'on'} />/
-																						<input type='radio' name='DROPSAMBA' value='off' $checked{'DROPSAMBA'}{'off'} /> $Lang::tr{'off'}</td></tr>
-</table>
-<br>
 <table width='95%' cellspacing='0'>
 <tr bgcolor='$color{'color20'}'><td colspan='2' align='left'><b>$Lang::tr{'fw settings'}</b></td></tr>
 <tr><td align='left' width='60%'>$Lang::tr{'fw settings color'}</td><td align='left'>$Lang::tr{'on'} <input type='radio' name='SHOWCOLORS' value='on' $checked{'SHOWCOLORS'}{'on'} />/

[-- Attachment #3: 02_force_dns_firewall_init.patch --]
[-- Type: text/plain, Size: 3464 bytes --]

diff -U 3 C:/Compare/force dns/next/src_initscripts_system_firewall C:/Compare/force dns/tuned 01/firewall_init
--- C:/Compare/force dns/next/src_initscripts_system_firewall	Mon Nov 23 09:09:24 2020
+++ C:/Compare/force dns/tuned 01/firewall_init	Sat Nov 21 01:37:54 2020
@@ -246,6 +246,77 @@
 		iptables -A ${i} -j CAPTIVE_PORTAL
 	done
 
+# Force DNS REDIRECT on GREEN (udp, tcp, 53)
+if [ "$DNS_FORCE_ON_GREEN" == "on" ]; then
+	if ! iptables -t nat -C CUSTOMPREROUTING -i green0 -p udp -m udp --dport 53 -j REDIRECT >/dev/null 2>&1; then
+		iptables -t nat -A CUSTOMPREROUTING -i green0 -p udp -m udp --dport 53 -j REDIRECT
+	fi
+
+	if ! iptables -t nat -C CUSTOMPREROUTING -i green0 -p tcp -m tcp --dport 53 -j REDIRECT >/dev/null 2>&1; then
+		iptables -t nat -A CUSTOMPREROUTING -i green0 -p tcp -m tcp --dport 53 -j REDIRECT
+	fi
+
+else
+
+	if iptables -t nat -C CUSTOMPREROUTING -i green0 -p udp -m udp --dport 53 -j REDIRECT >/dev/null 2>&1; then
+		iptables -t nat -D CUSTOMPREROUTING -i green0 -p udp -m udp --dport 53 -j REDIRECT >/dev/null 2>&1
+	fi
+
+	if iptables -t nat -C CUSTOMPREROUTING -i green0 -p tcp -m tcp --dport 53 -j REDIRECT >/dev/null 2>&1; then
+		iptables -t nat -D CUSTOMPREROUTING -i green0 -p tcp -m tcp --dport 53 -j REDIRECT >/dev/null 2>&1
+	fi
+fi
+
+# Force DNS REDIRECT on BLUE (udp, tcp, 53)
+if [ "$DNS_FORCE_ON_BLUE" == "on" ]; then
+	if ! iptables -t nat -C CUSTOMPREROUTING -i blue0 -p udp -m udp --dport 53 -j REDIRECT >/dev/null 2>&1; then
+		iptables -t nat -A CUSTOMPREROUTING -i blue0 -p udp -m udp --dport 53 -j REDIRECT
+	fi
+
+	if ! iptables -t nat -C CUSTOMPREROUTING -i blue0 -p tcp -m tcp --dport 53 -j REDIRECT >/dev/null 2>&1; then
+		iptables -t nat -A CUSTOMPREROUTING -i blue0 -p tcp -m tcp --dport 53 -j REDIRECT
+	fi
+
+else
+
+	if iptables -t nat -C CUSTOMPREROUTING -i blue0 -p udp -m udp --dport 53 -j REDIRECT >/dev/null 2>&1; then
+		iptables -t nat -D CUSTOMPREROUTING -i blue0 -p udp -m udp --dport 53 -j REDIRECT >/dev/null 2>&1
+	fi
+
+	if iptables -t nat -C CUSTOMPREROUTING -i blue0 -p tcp -m tcp --dport 53 -j REDIRECT >/dev/null 2>&1; then
+		iptables -t nat -D CUSTOMPREROUTING -i blue0 -p tcp -m tcp --dport 53 -j REDIRECT >/dev/null 2>&1
+	fi
+
+fi
+
+# Force NTP REDIRECT on GREEN (udp, 123)
+if [ "$NTP_FORCE_ON_GREEN" == "on" ]; then
+	if ! iptables -t nat -C CUSTOMPREROUTING -i green0 -p udp -m udp --dport 123 -j REDIRECT >/dev/null 2>&1; then
+		iptables -t nat -A CUSTOMPREROUTING -i green0 -p udp -m udp --dport 123 -j REDIRECT
+	fi
+
+else
+
+	if iptables -t nat -C CUSTOMPREROUTING -i green0 -p udp -m udp --dport 123 -j REDIRECT >/dev/null 2>&1; then
+		iptables -t nat -D CUSTOMPREROUTING -i green0 -p udp -m udp --dport 123 -j REDIRECT >/dev/null 2>&1
+	fi
+
+fi
+
+# Force DNS REDIRECT on BLUE (udp, 123)
+if [ "$NTP_FORCE_ON_BLUE" == "on" ]; then
+	if ! iptables -t nat -C CUSTOMPREROUTING -i blue0 -p udp -m udp --dport 123 -j REDIRECT >/dev/null 2>&1; then
+		iptables -t nat -A CUSTOMPREROUTING -i blue0 -p udp -m udp --dport 123 -j REDIRECT
+	fi
+
+else
+
+	if iptables -t nat -C CUSTOMPREROUTING -i blue0 -p udp -m udp --dport 123 -j REDIRECT >/dev/null 2>&1; then
+		iptables -t nat -D CUSTOMPREROUTING -i blue0 -p udp -m udp --dport 123 -j REDIRECT >/dev/null 2>&1
+	fi
+
+fi
+
 	# Accept everything connected
 	for i in INPUT FORWARD OUTPUT; do
 		iptables -A ${i} -j CONNTRACK

[-- Attachment #4: 03_firewall_restart_in_optionsfw_cgi.patch --]
[-- Type: text/plain, Size: 1959 bytes --]

diff -U 3 C:/Compare/force dns/tuned 01/optionsfw.cgi C:/Compare/force dns/tuned 02/optionsfw.cgi
--- C:/Compare/force dns/tuned 01/optionsfw.cgi	Sun Nov  8 20:17:54 2020
+++ C:/Compare/force dns/tuned 02/optionsfw.cgi	Sun Nov 22 20:06:56 2020
@@ -69,6 +69,31 @@
 	&General::readhash($filename, \%settings);             # Load good settings
 }
 
+if ($settings{'ACTION'} eq $Lang::tr{'fw settings save and restart'}) {
+	if ($settings{'defpol'} ne '1'){
+		$errormessage .= $Lang::tr{'new optionsfw later'};
+		&General::writehash($filename, \%settings);             # Save good settings
+		system("/usr/local/bin/firewallctrl");
+	}else{
+		if ($settings{'POLICY'} ne ''){
+			$fwdfwsettings{'POLICY'} = $settings{'POLICY'};
+		}
+		if ($settings{'POLICY1'} ne ''){
+			$fwdfwsettings{'POLICY1'} = $settings{'POLICY1'};
+		}
+		my $MODE = $fwdfwsettings{'POLICY'};
+		my $MODE1 = $fwdfwsettings{'POLICY1'};
+		%fwdfwsettings = ();
+		$fwdfwsettings{'POLICY'} = "$MODE";
+		$fwdfwsettings{'POLICY1'} = "$MODE1";
+		&General::writehash("${General::swroot}/firewall/settings", \%fwdfwsettings);
+		&General::readhash("${General::swroot}/firewall/settings", \%fwdfwsettings);
+		system("/usr/local/bin/firewallctrl");
+		system("/etc/rc.d/init.d/firewall restart >/dev/null 2>&1 ");
+	}
+	&General::readhash($filename, \%settings);             # Load good settings
+}
+
 &Header::openpage($Lang::tr{'options fw'}, 1, '');
 &Header::openbigbox('100%', 'left', '', $errormessage);
 &General::readhash($filename, \%settings);
@@ -370,7 +395,8 @@
 <br />
 <table width='100%' cellspacing='0'>
 <tr><td align='right'><form method='post' action='$ENV{'SCRIPT_NAME'}'>
-<input type='submit' name='ACTION' value=$Lang::tr{'save'} />
+<input type='submit' name='ACTION' value='$Lang::tr{'save'}' />
+<input type='submit' name='ACTION' value='$Lang::tr{'fw settings save and restart'}' />
 </form></td></tr>
 </table>
 </form>

[-- Attachment #5: 04_optionsfwctrl.c --]
[-- Type: text/plain, Size: 349 bytes --]

/* This file is part of the IPFire Firewall.
 *
 * This program is distributed under the terms of the GNU General Public
 * Licence.  See the file COPYING for details.
 *
 */

#include <stdlib.h>
#include "setuid.h"

int main(void)
{
	if (!(initsetuid()))
		exit(1);

	safe_system("/etc/rc.d/init.d/firewall restart >/dev/null 2>&1");

	return 0;
}

Re: Forcing all DNS traffic from the LAN to the firewall

[Matthias Fischer]

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

On 23.11.2020 10:08, Matthias Fischer wrote:
> Hi,
> 
> to keep this discussion going, I'd like to publish ...

A solution.

Finally I got it working.

Current discussion:
=> https://community.ipfire.org/t/testing-dns-redirect-code-snippet/3888

In the end, it was easier as I thought, having the missing link always
in front of my eyes. But didn't see it. Until today.

After I added 'optionsfwctrl.c' to the process, it was just one missing
line in 'optionsfw.cgi'.

But perhaps there are still some things left.

1. Having looked through the various options I can't see no option which
needs a *complete* reboot of the machine anymore. Is this right?

2. If I'm right I would remove "$errormessage .= $Lang::tr{'new
optionsfw later'};" after choosing "Save And Restart".
For me, it seems that this message is no longer needed at this point.
Am I right?

3. If we still need a reboot, I would mark the relevant options with a
star ("* Changing this option requires a reboot").

4. Otherwise the complete code is finally ready to be tested and
tortured ( ;-) ) snd I'll prepare something for patchwork.

As always: Hints and testers are welcome... ;-)

Best,
Matthias