5353 UDP port listening to outward IP 224.0.0.251

I have enabled only 443,853 TCP ports for outgoing traffic. Firewalld is in drop mode(all incoming traffic block).UDP is disabled for all ports.
Systemd-resolved is taking care of DNS over TLS on 853 TCP port
Surprisingly many times i can see UDP port 5353 connection to 224.0.0.251 IP address with no Rx packets though
mDns is not enabled as only resolved.conf is configured.Not networkd.conf
I understand when mDns through networkd.conf is configured then port 5353 need to be enabled.
No such configuration exists.
Firewalld is configured for only TCP traffic. UDP is disabled for outgoing traffic.
iptables.service and ip6tables service disabled since firewalld frontend is talking to iptables-nft and nftables in the back end
How do i avoid port 5353UDP traffic to 224.0.0.251 IP
It is against firewalld configuration and rulesets


Can you share the firewalld rules you have for blocking outbound UDP traffic?

That’s multicast DNS. Most common users are cups or avahi.

1 Like

Here is a "List of TCP and UDP port numbers. I don’t know how up to date it is ?

As @khagaroth mentioned, 5353 is Multicast DNS

5353 	Assigned 	Yes 			Multicast DNS (mDNS)[11]

HTH

Pudge

It’s not really against the rules as you say, because it is not really normal traffic. I thought this explanation was pretty good:

Multicast IP traffic has different rules from the ordinary unicast or broadcast traffic. A multicast IP address is never used as a source address: it is always a destination address only. A system that is sending multicasts will use its regular IP address as the source address. Each multicast IP address will designate a multicast group: anything sent to that multicast address will be received by all hosts belonging to that group. (Or that’s the theory. In practice, unless you’ve made specific arrangements to route multicasts beyond your subnet or organization, multicast traffic tends to stop at those limits by default.)

When some software in a host wants to receive multicast traffic, it will tell the host’s kernel “I wish to receive multicasts addressed to this multicast IP address.” The kernel will then add that multicast IP address to the list of multicast addresses it will listen for, and send out an IGMP report message: "I wish to receive multicast traffic addressed to these multicast IPs: ". This IGMP report is itself a multicast IP message. In Linux, IGMP is handled at the kernel level: this is why you see no processes responsible for it.

The explanation goes on a bit actually; you can read the rest in this thread: https://unix.stackexchange.com/questions/425786/incoming-and-outgoing-traffic-when-nothing-is-running

One likely explanation for the fact that your device is sending out multicast traffic is:

Systemd-resolved has a built-in mDNS service. You can disable it if you wish by setting MulticastDNS=false in resolved.conf. More here: https://man.archlinux.org/man/resolved.conf.5

2 Likes

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.