From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernhard Bitsch To: development@lists.ipfire.org Subject: Re: IPFire 2.27 - Core Update 160 released Date: Wed, 06 Oct 2021 15:49:03 +0200 Message-ID: <50ccf096-1868-85e3-b00d-a2317282ac39@ipfire.org> In-Reply-To: <6bbe85a241ebb62fb3b5b6c332d88cdf@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5216140198920379233==" List-Id: --===============5216140198920379233== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Daniel, I tried to eliminate this double messages. First I found the standard rules in 'Incoming Firewall Access' for DNS=20 enabled. Interpreting these as the 'RETURN' rules discussed in the=20 development process, I defined similiar rules for NTP. The 'INPUTFW' messages are gone. They show up again, when I enable=20 logging for these rules. Maybe this helps a bit to clarify the issue. Bernhard Am 06.10.2021 um 15:22 schrieb Daniel Weism=C3=BCller: > 6. Oktober 2021 14:12, "Bernhard Bitsch" schrieb: >=20 >> Hello, >> >> Am 06.10.2021 um 12:04 schrieb Daniel Weism=C3=BCller: >> >>> Hello >>> I have also had a look at this. >>> There are now two Wiki pages on this topic. >>> - A general one (https://wiki.ipfire.org/configuration/firewall/rules/red= irect-services). >>> - A very specific one for DNS redirect (https://wiki.ipfire.org/configura= tion/firewall/dns). >>> This is true, but the first page can't be found by a normal research in t= he wiki. >>> Since core160 the general method works. This is equivalent to the method = 1 described on the >>> specific page. >>> Following the general instructions, I have created a few firewall rules t= o redirect DNS, DoT and >>> NTP. >>> This works very well now. >>> In general, I think that general instructions are always better than spec= ific step-by-step >>> instructions. >>> Agreed. >>> In my eyes, the described method 2, which had to be taken as a temporary = solution, is therefore >>> obsolete. In addition, pure blocking can lead to some devices no longer w= orking. >>> Having implemented the second method until now, I can see a difference. >> >> Label 'DNAT' in the logging isn't nice. 'REDIRECT' would be more helpful. >> If I define a rule for NTP, I get two log entries ( one with 'DNAT', one w= ith 'INPUTFW' ). A >> similiar rule for DNS produces one log message only. >> - >> Bernhard >=20 > I have checked my logs and cannot confirm this. >=20 > 15:16:30 INPUTFW blue0 UDP 192.168.56.127 > 192.168.56.1 57803 > 53(DOMAIN) b8:85:84:a6:a0:f7 > 15:16:30 DNAT blue0 UDP 192.168.56.127 > 192.168.56.1 57803 > 53(DOMAIN) b8:85:84:a6:a0:f7 > 15:16:30 INPUTFW green0 UDP 192.168.55.30 > 192.168.55.1 123(NTP) > 123(NTP) 00:1a:e8:ad:07:52 > 15:16:30 DNAT green0 UDP 192.168.55.30 > 192.168.55.1 123(NTP) > 123(NTP) 00:1a:e8:ad:07:52 >=20 > As you can see, two entries are always generated for me. >=20 > - > Daniel >=20 >> >>> Do you see it the same way? >>>> - >>> Daniel >>> 5. Oktober 2021 22:10, "Bernhard Bitsch" schrieb: >>> Hi all, >>>> Thanks. >>>> So it was only a misunderstanding. I thought, there would be options to = redirect DNS requests and >>>> NTP requests. >>>> But this 'any port solution' is much mightier. >>>> I'll try to convert my actual firewall.local solution to the main stream= and report about the >>>> results. >>>> >>>> Regards, >>>> Bernhard >>>> >>>> Am 05.10.2021 um 18:28 schrieb Michael Tremer: >>> >>> Hello, >>> Simply using -j REDIRECT. >>> This was always part of the firewall engine, but the UI was broken and di= d not allow to create >>> these rules. >>> -Michael >>> On 5 Oct 2021, at 14:55, Bernhard Bitsch wrote: >>> Just a question. How is the activation of redirection implemented? >>> >>> Am 05.10.2021 um 12:45 schrieb IPFire Project: >>> >>> IPFire Logo >>> there is a new post from Michael Tremer on the IPFire Blog: >>> *IPFire 2.27 - Core Update 160 released* >>> This is the release announcement for IPFire 2.27 - Core Update 160. >>> It comes with a large number of bug fixes and package updates and >>> prepare for removing Python 2 which has reached its end of life. >>> Click Here To Read More >>> The IPFire Project >>> Don't like these emails? Unsubscribe . --===============5216140198920379233==--