From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: IPFire 2.27 - Core Update 160 released Date: Sat, 09 Oct 2021 13:42:37 +0100 Message-ID: <9DBDA03E-3976-465B-8078-9BA368FF141E@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0581242420380326364==" List-Id: --===============0581242420380326364== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 6 Oct 2021, at 20:40, Jon Murphy wrote: >=20 > Hello *, >=20 > Just to add more info. I was trying to eliminate the Log info for the new = redirect rule. =20 Can anyone confirm this? >=20 > With the Rule enabled AND the Log enabled I see this in `/var/log/messages`: > Oct 6 13:17:07 ipfireHP kernel: DNAT IN=3Dgreen0 OUT=3D MAC=3D S= RC=3D192.168.1.100 DST=3D1.1.1.1 LEN=3D64 TOS=3D0x00 PREC=3D0x00 TTL=3D64 ID= =3D10636 PROTO=3DUDP SPT=3D57109 DPT=3D53 LEN=3D44=20 > Oct 6 13:17:07 ipfireHP kernel: INPUTFW IN=3Dgreen0 OUT=3D MAC=3D SRC=3D192.168.1.100 DST=3D192.168.1.1 LEN=3D64 TOS=3D0x00 PREC=3D0x00 TTL= =3D64 ID=3D10636 PROTO=3DUDP SPT=3D57109 DPT=3D53 LEN=3D44=20 > Oct 6 13:17:07 ipfireHP kernel: DNAT IN=3Dgreen0 OUT=3D MAC=3D S= RC=3D192.168.1.100 DST=3D1.2.3.4 LEN=3D65 TOS=3D0x00 PREC=3D0x00 TTL=3D64 ID= =3D6382 PROTO=3DUDP SPT=3D55200 DPT=3D53 LEN=3D45=20 > Oct 6 13:17:07 ipfireHP kernel: INPUTFW IN=3Dgreen0 OUT=3D MAC=3D SRC=3D192.168.1.100 DST=3D192.168.1.1 LEN=3D65 TOS=3D0x00 PREC=3D0x00 TTL= =3D64 ID=3D6382 PROTO=3DUDP SPT=3D55200 DPT=3D53 LEN=3D45=20 >=20 >=20 > With the Rule enabled AND the Log NOT enabled I see this in `/var/log/messa= ges`: > Oct 6 13:50:16 ipfireHP kernel: DNAT IN=3Dgreen0 OUT=3D MAC=3D S= RC=3D192.168.1.100 DST=3D192.168.1.1 LEN=3D69 TOS=3D0x00 PREC=3D0x00 TTL=3D25= 5 ID=3D60778 PROTO=3DUDP SPT=3D59328 DPT=3D53 LEN=3D49=20 > Oct 6 13:50:16 ipfireHP kernel: INPUTFW IN=3Dgreen0 OUT=3D MAC=3D SRC=3D192.168.1.100 DST=3D192.168.1.1 LEN=3D69 TOS=3D0x00 PREC=3D0x00 TTL= =3D255 ID=3D60778 PROTO=3DUDP SPT=3D59328 DPT=3D53 LEN=3D49=20 > Oct 6 13:50:17 ipfireHP kernel: DNAT IN=3Dgreen0 OUT=3D MAC=3D S= RC=3D192.168.1.100 DST=3D192.168.1.1 LEN=3D62 TOS=3D0x00 PREC=3D0x00 TTL=3D25= 5 ID=3D15801 PROTO=3DUDP SPT=3D57028 DPT=3D53 LEN=3D42=20 > Oct 6 13:50:17 ipfireHP kernel: INPUTFW IN=3Dgreen0 OUT=3D MAC=3D SRC=3D192.168.1.100 DST=3D192.168.1.1 LEN=3D62 TOS=3D0x00 PREC=3D0x00 TTL= =3D255 ID=3D15801 PROTO=3DUDP SPT=3D57028 DPT=3D53 LEN=3D42=20 >=20 > It seems like logging cannot be disabled for this rule. >=20 > See: > https://bugzilla.ipfire.org/show_bug.cgi?id=3D12654 >=20 >=20 > Jon >=20 >=20 >> On Oct 6, 2021, at 8:49 AM, Bernhard Bitsch wrote: >>=20 >> Hi Daniel, >>=20 >> I tried to eliminate this double messages. >> First I found the standard rules in 'Incoming Firewall Access' for DNS ena= bled. Interpreting these as the 'RETURN' rules discussed in the development p= rocess, I defined similiar rules for NTP. >> The 'INPUTFW' messages are gone. They show up again, when I enable logging= for these rules. >> Maybe this helps a bit to clarify the issue. >>=20 >> Bernhard >>=20 >> Am 06.10.2021 um 15:22 schrieb Daniel Weism=C3=BCller: >>> 6. Oktober 2021 14:12, "Bernhard Bitsch" schrieb: >>>> Hello, >>>>=20 >>>> Am 06.10.2021 um 12:04 schrieb Daniel Weism=C3=BCller: >>>>=20 >>>>> 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/r= edirect-services). >>>>> - A very specific one for DNS redirect (https://wiki.ipfire.org/configu= ration/firewall/dns). >>>>> This is true, but the first page can't be found by a normal research in= the wiki. >>>>> Since core160 the general method works. This is equivalent to the metho= d 1 described on the >>>>> specific page. >>>>> Following the general instructions, I have created a few firewall rules= to redirect DNS, DoT and >>>>> NTP. >>>>> This works very well now. >>>>> In general, I think that general instructions are always better than sp= ecific step-by-step >>>>> instructions. >>>>> Agreed. >>>>> In my eyes, the described method 2, which had to be taken as a temporar= y solution, is therefore >>>>> obsolete. In addition, pure blocking can lead to some devices no longer= working. >>>>> Having implemented the second method until now, I can see a difference. >>>>=20 >>>> 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= with 'INPUTFW' ). A >>>> similiar rule for DNS produces one log message only. >>>> - >>>> Bernhard >>> I have checked my logs and cannot confirm this. >>> 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 >>> As you can see, two entries are always generated for me. >>> - >>> 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 t= o 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 stre= am and report about the >>>>>> results. >>>>>>=20 >>>>>> Regards, >>>>>> Bernhard >>>>>>=20 >>>>>> Am 05.10.2021 um 18:28 schrieb Michael Tremer: >>>>>=20 >>>>> Hello, >>>>> Simply using -j REDIRECT. >>>>> This was always part of the firewall engine, but the UI was broken and = did 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? >>>>>=20 >>>>> Am 05.10.2021 um 12:45 schrieb IPFire Project: >>>>>=20 >>>>> 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 . >=20 --===============0581242420380326364==--