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-f...
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-f...
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
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@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-f...
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-f...
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
Hi,
On 10 Nov 2020, at 13:07, Tapani Tarvainen ipfire@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@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-f...
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-f...
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
On Fri, Nov 13, 2020 at 02:24:23PM +0000, Michael Tremer (michael.tremer@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.)
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
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@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-f...
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-f...
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
On Fri, Nov 13, 2020 at 02:23:10PM +0000, Michael Tremer (michael.tremer@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.
Hi,
On 13.11.2020 15:55, Tapani Tarvainen wrote:
On Fri, Nov 13, 2020 at 02:23:10PM +0000, Michael Tremer (michael.tremer@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
On 15 Nov 2020, at 13:16, Matthias Fischer matthias.fischer@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@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
On Sun, Nov 15, 2020 at 02:16:46PM +0100, Matthias Fischer (matthias.fischer@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.
Hi,
On 15 Nov 2020, at 15:33, Tapani Tarvainen ipfire@tapanitarvainen.fi wrote:
On Sun, Nov 15, 2020 at 02:16:46PM +0100, Matthias Fischer (matthias.fischer@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
Hi,
On 13 Nov 2020, at 14:55, Tapani Tarvainen ipfire@tapanitarvainen.fi wrote:
On Fri, Nov 13, 2020 at 02:23:10PM +0000, Michael Tremer (michael.tremer@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
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@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-f...
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-f...
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
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@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-f...
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-f...
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.
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
Hi,
On 15 Nov 2020, at 13:36, Matthias Fischer matthias.fischer@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
On Sun, Nov 15, 2020 at 02:50:09PM +0000, Michael Tremer (michael.tremer@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.
Hi,
On 15 Nov 2020, at 15:44, Tapani Tarvainen ipfire@tapanitarvainen.fi wrote:
On Sun, Nov 15, 2020 at 02:50:09PM +0000, Michael Tremer (michael.tremer@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
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-f...
['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
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
-
Matthias Fischer -
Michael Tremer -
Paul Simmons -
Rainer Kemme -
Tapani Tarvainen