Firewalld and nftables rules for NFS, Samba, NTP, DNS and DHCP: exactly which ports to open

What it is

Each infrastructure service in this series needs exactly one thing from the host firewall: the port(s) it actually listens on, open to the clients that should reach it and nowhere else. Firewalld ships predefined service definitions with these values built in: the NFS4 protocol is documented as using TCP 2049; Samba's definition opens TCP 139 and 445 for Windows file and printer sharing and, through its included samba-client service, UDP 137/138 for NetBIOS (SMB2 and later need only TCP 445); DNS opens TCP and UDP 53; DHCP's definition allows a DHCP server to accept messages from DHCP clients and relay agents on UDP 67 (clients use UDP 68, a client-side concern); and NTP opens UDP 123 (an NTS server additionally needs TCP 4460). For NFSv3, the nfs3, mountd (20048) and rpc-bind (111) services are needed as well, plus statd/lockd ports that are dynamic unless pinned in /etc/nfs.conf.

Why it matters

A rule that is too narrow breaks the service in a way that looks like a server-side bug (clients time out, no error), which is what NFSv3's extra ports most often cause when only 2049 is opened. A rule that is too broad — a whole zone trusted, or a range opened "to be safe" — is exposure with no offsetting benefit.

How to apply

• With firewalld, prefer the predefined services over hand-built port rules where one exists: firewall-cmd --permanent --zone=internal --add-service=nfs, then repeat with samba, dns, dhcp and ntp, followed by firewall-cmd --reload as root; rules in that zone apply only to traffic from the sources or interfaces bound to it. Where no predefined service fits, --add-port adds the port. This option can be specified multiple times, once per port or range needed.
• With nftables directly, match the same values explicitly in the input chain, for example udp dport 123 accept and tcp dport 2049 accept, scoped to the relevant interface or source address set; nft's manual page documents this dport matching syntax for both tcp and udp. Rules added with nft add rule are lost at reboot unless also written to the ruleset file (/etc/nftables.conf or /etc/sysconfig/nftables.conf); do not mix raw nft rules with an active firewalld.
• Scope every rule to a source address or firewalld zone, not just a port; a port open to every address on an internal-only service defeats the purpose of listing exact ports at all.
• Test a TCP service from a client with nc -zv <host> <port> for a quick connect/refuse signal. For UDP services (NTP, DNS, DHCP), a bare nc -u or nmap -sU probe is far less conclusive: Nmap's own documentation on UDP scanning notes that no response received, even after retransmissions, is reported as the ambiguous open|filtered state rather than a clear answer — prefer testing UDP services with the real client tool (chronyc, dig, a DHCP lease renewal) over a port scanner.

Pitfalls

• Opening NFSv3's legacy ports "just in case" after already moving to NFSv4-only, re-exposing the portmapper.
• Reading a UDP nmap -sU result of open|filtered as proof either way; only closed (an ICMP port-unreachable reply) is a clear answer, and the real client test is still the better check.