From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthias Fischer To: development@lists.ipfire.org Subject: Re: Forcing all DNS traffic from the LAN to the firewall Date: Fri, 13 Nov 2020 17:57:33 +0100 Message-ID: <79177e1f-7be3-f088-2313-eff26c78a328@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6213181548905475128==" List-Id: --===============6213181548905475128== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 = wrote: >>=20 >> Hi, >>=20 >> 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...". >>=20 >> Current discussion =3D> >> https://community.ipfire.org/t/forcing-all-dns-traffic-from-the-lan-to-the= -firewall/3512 >>=20 >> But not only in the forums - the oldest Wiki article is dated "May 22, >> 2015". Long time, but still editing scripts manually... >>=20 >> 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. >=20 > Very good. I like a discussion. >=20 >> 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'. >>=20 >> Screenshots of the result can be found in the forum thread cited above: >> =3D> >> https://community.ipfire.org/t/forcing-all-dns-traffic-from-the-lan-to-the= -firewall/3512/91 >>=20 >> But some points are IMHO still unclear and need clarification. And I >> think I'm not the one to decide where to go... >>=20 >> My thoughts until now: >>=20 >> - Do we need this? >> [Hm. ;-) As I heard, some folks do.] >=20 > Very good question. >=20 > I do not entirely understand the use-case for this. And I think nobody has = shown an example at all here. >=20 > So what I could come up with is this: >=20 > * 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 simp= ly 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 doe= s 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=E2=80=99s revenue. >=20 > 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=E2=80=99t think so. >=20 > I would say that that checkbox that you have added should block using any o= ther 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. >=20 > If you really really want to redirect, I think the best option is to add th= at functionality to the firewall UI that users can create a rule that redirec= ts this traffic. That way it is absolutely explicit and the admin hopefully k= nows what they are doing. >=20 >> - Is the 'optionsfwcgi' the right place for this? >> [In my opinion: yes. It was easy to add and sits beside other >> interface "options"] >=20 > Yes. I believe this is the right place. >=20 >> - Do we really want this for all installations? >> [For someone, who doesn't want or doesn't need it: it can be switched OFF] >=20 > Default must be OFF. We should not tamper with people=E2=80=99s packets. I see. Perhaps I wasn't clear enough: of course the default should be switched OFF. > Apart from blocking packets, IPFire=E2=80=99s most popular feature is forwa= rding them. >=20 >> - Is this function usable under ALL circumstances? >> [If not: it can be switched OFF] >=20 > 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!?] >=20 > 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. >=20 > 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 >=20 >>=20 >> Any hints are welcome... >>=20 >> Best, >> Matthias >>=20 >=20 --===============6213181548905475128==--