IPTables rules for LAN traffic

Question

As a learning experience I'm building a secure web/Email server on a Raspberry Pi V4. I have it basically running but in looking at the sys/log file I see many records like the following:

Jul 31 14:04:17 EMail kernel: [ 1023.038514] iptables denied: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:b8:27:eb:1f:9e:50:08:00 SRC=10.0.7.95 DST=10.0.7.255 LEN=78 TOS=0$ $PROTO=UDP SPT=5353 DPT=5353 LEN=53

My LAN IP address are 10.0.7.0/24. Is there an IPTables rule I can add for both TCP and UDP which will allow LAN computers to access other LAN addresses? Is it safe? Actually it is not clear to me why this Pi (10.0.7.92) would even be seeing this traffic? Right now I have these LAN based IPTables rules:

ACCEPT udp -- 10.0.7.0/24 anywhere udp dpt:netbios-ns

ACCEPT udp -- 10.0.7.0/24 anywhere udp dpt:netbios-dgm

ACCEPT tcp -- 10.0.7.0/24 anywhere tcp dpt:netbios-ssn

ACCEPT tcp -- 10.0.7.0/24 anywhere tcp dpt:microsoft-ds

Thanks for any comments and suggestions....RDK

Answer 1

This does not have anything with mail server. Port 5353 is often used by local multicast DNS services (mDNS). Notice target IP address ends with .255, it is likely the broadcast address in you LAN, so the packet was destined "to all computers" within the LAN. The system with IP 10.0.7.95 seems to support mDNS, so it sends this kind of packets. This is nothing wrong, and often desirable.

If you don't have an mDNS responder software on your server, you can safely ignore these messages. It might be a good idea to silence them, so important warnings won't get lost in the stream of this crap. For this, you can add the drop rule just before the logging rule:

iptables -I <chain> <N> -p udp --dport 5353 -j DROP -m comment --comment "silence warnings about mDNS packets"

To determine chain and N, run iptables-save (without arguments, it'll just print the complete running ruleset). In its output, find the rule which produces the log (the one which has -j LOG target), and then find out which chain it is in (the thing right after -A). That's your chain value. Then, you count its position in the chain, from the first rule with that -A <chain>. That's your N value.

The new rule will be inserted just before the logging rule (into position N, the logging rule will become the next one), so packets to UDP port 5353 will not reach it anymore and won't generate any such noise.

Alternatively, you can install mDNS responder and permit this traffic (by inserting a similar rule with -j ACCEPT, but I doubt you need that on the mail server.