> On 6 Oct 2021, at 20:40, Jon Murphy <jcmurphy26(a)gmail.com> wrote:
> 
> Hello *,
> 
> Just to add more info.  I was trying to eliminate the Log info for the new redirect rule.  

Can anyone confirm this?

> 
> With the Rule enabled AND the Log enabled I see this in `/var/log/messages`:
> Oct  6 13:17:07 ipfireHP kernel: DNAT IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=1.1.1.1 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=10636 PROTO=UDP SPT=57109 DPT=53 LEN=44 
> Oct  6 13:17:07 ipfireHP kernel: INPUTFW IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=192.168.1.1 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=10636 PROTO=UDP SPT=57109 DPT=53 LEN=44 
> Oct  6 13:17:07 ipfireHP kernel: DNAT IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=1.2.3.4 LEN=65 TOS=0x00 PREC=0x00 TTL=64 ID=6382 PROTO=UDP SPT=55200 DPT=53 LEN=45 
> Oct  6 13:17:07 ipfireHP kernel: INPUTFW IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=192.168.1.1 LEN=65 TOS=0x00 PREC=0x00 TTL=64 ID=6382 PROTO=UDP SPT=55200 DPT=53 LEN=45 
> 
> 
> With the Rule enabled AND the Log NOT enabled I see this in `/var/log/messages`:
> Oct  6 13:50:16 ipfireHP kernel: DNAT IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=192.168.1.1 LEN=69 TOS=0x00 PREC=0x00 TTL=255 ID=60778 PROTO=UDP SPT=59328 DPT=53 LEN=49 
> Oct  6 13:50:16 ipfireHP kernel: INPUTFW IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=192.168.1.1 LEN=69 TOS=0x00 PREC=0x00 TTL=255 ID=60778 PROTO=UDP SPT=59328 DPT=53 LEN=49 
> Oct  6 13:50:17 ipfireHP kernel: DNAT IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=192.168.1.1 LEN=62 TOS=0x00 PREC=0x00 TTL=255 ID=15801 PROTO=UDP SPT=57028 DPT=53 LEN=42 
> Oct  6 13:50:17 ipfireHP kernel: INPUTFW IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=192.168.1.1 LEN=62 TOS=0x00 PREC=0x00 TTL=255 ID=15801 PROTO=UDP SPT=57028 DPT=53 LEN=42 
> 
> It seems like logging cannot be disabled for this rule.
> 
> See:
> https://bugzilla.ipfire.org/show_bug.cgi?id=12654
> 
> 
> Jon
> 
> 
>> On Oct 6, 2021, at 8:49 AM, Bernhard Bitsch <bbitsch(a)ipfire.org> wrote:
>> 
>> Hi Daniel,
>> 
>> I tried to eliminate this double messages.
>> First I found the standard rules in 'Incoming Firewall Access' for DNS enabled. Interpreting these as the 'RETURN' rules discussed in the development process, 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.
>> 
>> Bernhard
>> 
>> Am 06.10.2021 um 15:22 schrieb Daniel Weismüller:
>>> 6. Oktober 2021 14:12, "Bernhard Bitsch" <bbitsch(a)ipfire.org> schrieb:
>>>> Hello,
>>>> 
>>>> Am 06.10.2021 um 12:04 schrieb Daniel Weismüller:
>>>> 
>>>>> 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/redirect-services).
>>>>> - A very specific one for DNS redirect (https://wiki.ipfire.org/configuration/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 method 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 specific 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 working.
>>>>> 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 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
>>>> 
>>>>> Do you see it the same way?
>>>>>> -
>>>>> Daniel
>>>>> 5. Oktober 2021 22:10, "Bernhard Bitsch" <bbitsch(a)ipfire.org> 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 did not allow to create
>>>>> these rules.
>>>>> -Michael
>>>>> On 5 Oct 2021, at 14:55, Bernhard Bitsch <bbitsch(a)ipfire.org> 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 <https://blog.ipfire.org/post/ipfire-2-27-core-update-160-released>
>>>>> The IPFire Project
>>>>> Don't like these emails? Unsubscribe <https://people.ipfire.org/unsubscribe>.
>