Firewall is dropping DNS packets

jimbobrae · May 18, 2026, 4:48am

When a DNS request is sent to this host, a series of log entries, below, occurs showing dropped packets. This is not a good thing.

It appears that there is a rule that tells the firewall to drop those packets. The source IP does not matter.

How do I find and disable that rule?

2026-05-17T21:30:38-0700 sma-station12l.sma.com kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:24:8c:88:9d:f3:a0:ad:9f:32:9d:74:86:dd SRC=fd2f:4760:521f:3f3c:0000:0000:c0a8:45f6 DST=fd2f:4760:521f:3f3c:0000:0000:c0a8:456d LEN=73 TC=0 HOPLIMIT=64 FLOWLBL=330100 PROTO=UDP SPT=35051 DPT=53 LEN=33

These are the only reject rules.

 $ sudo sudo iptables -vnL | grep REJECT
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with tcp-reset
    0     0 REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-proto-unreachable

 $ sudo sudo iptables -vnL | grep DROP
Chain INPUT (policy DROP 0 packets, 0 bytes)
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           
Chain FORWARD (policy DROP 0 packets, 0 bytes)
   28  3009 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            PKTTYPE = broadcast
   23  6258 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* sfw2.insert.pos */ PKTTYPE != unicast
    0     0 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 5 tcp flags:0x17/0x02 LOG flags 6 level 4 prefix "SFW2-INext-DROP-DEFLT "
    0     0 LOG        icmp --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 5 LOG flags 6 level 4 prefix "SFW2-INext-DROP-DEFLT "
    5   357 LOG        udp  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 5 ctstate NEW LOG flags 6 level 4 prefix "SFW2-INext-DROP-DEFLT "
   44  3193 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

$ sudo iptables -vnL | grep "SFW2-INext-DROP-DEFLT "
    0     0 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 5 tcp flags:0x17/0x02 LOG flags 6 level 4 prefix "SFW2-INext-DROP-DEFLT "
    0     0 LOG        icmp --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 5 LOG flags 6 level 4 prefix "SFW2-INext-DROP-DEFLT "
    5   357 LOG        udp  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 5 ctstate NEW LOG flags 6 level 4 prefix "SFW2-INext-DROP-DEFLT "

deano_ferrari · May 18, 2026, 8:12am

The log entry you show pertains to IPv6 traffic, while you show only IPv4 output. The packet shown is IPv6 UDP traffic to port 53, so the issue may simply be that IPv6 DNS traffic is not permitted (or named is not listening on IPv6), rather than an explicit “DNS drop rule”.

Examine the results of
sudo ss -lnup | grep ':53'

Firewalld (the default firewall in openSUSE) uses the nftables backend by default. Can you confirm what firewall backend is actually active, and whether this system has inherited settings after upgraded from an older openSUSE release perhaps?
grep FirewallBackend /etc/firewalld/firewalld.conf

For nftables inspect the active nftables ruleset (instead of only iptables output) with…
sudo nft list ruleset

jimbobrae · May 18, 2026, 6:25pm

$ sudo grep FirewallBackend /etc/firewalld/firewalld.conf
# FirewallBackend
FirewallBackend=nftables

IP fd2f:4760:521f:3f3c::c0a8:456d is the assigned IP6 for the host. I do not know what all the other IP6’s are; they are apparently created by the system.

 sudo ss -lnup | grep ':53'
[sudo] password for root: 
Sorry, try again.
[sudo] password for root: 
UNCONN 0      0                                 192.168.69.109:53         0.0.0.0:*    users:(("named",pid=31161,fd=55))                       
UNCONN 0      0                                 192.168.69.109:53         0.0.0.0:*    users:(("named",pid=31161,fd=54))                       
UNCONN 0      0                                 192.168.69.109:53         0.0.0.0:*    users:(("named",pid=31161,fd=53))                       
UNCONN 0      0                                 192.168.69.109:53         0.0.0.0:*    users:(("named",pid=31161,fd=56))                       
UNCONN 0      0                                      127.0.0.1:53         0.0.0.0:*    users:(("named",pid=31161,fd=42))                       
UNCONN 0      0                                      127.0.0.1:53         0.0.0.0:*    users:(("named",pid=31161,fd=43))                       
UNCONN 0      0                                      127.0.0.1:53         0.0.0.0:*    users:(("named",pid=31161,fd=41))                       
UNCONN 0      0                                      127.0.0.1:53         0.0.0.0:*    users:(("named",pid=31161,fd=44))                       
UNCONN 0      0                                        0.0.0.0:53         0.0.0.0:*    users:(("dnsmasq",pid=1772,fd=4))                       
UNCONN 0      0                                        0.0.0.0:5353       0.0.0.0:*    users:(("avahi-daemon",pid=1054,fd=11))                 
UNCONN 0      0                                           [::]:53            [::]:*    users:(("dnsmasq",pid=1772,fd=6))                       
UNCONN 0      0                                          [::1]:53            [::]:*    users:(("named",pid=31161,fd=62))                       
UNCONN 0      0                                          [::1]:53            [::]:*    users:(("named",pid=31161,fd=63))                       
UNCONN 0      0                                          [::1]:53            [::]:*    users:(("named",pid=31161,fd=61))                       
UNCONN 0      0                                          [::1]:53            [::]:*    users:(("named",pid=31161,fd=64))                       
UNCONN 0      0                [fe80::224:8cff:fe88:9df3]%eth0:53            [::]:*    users:(("named",pid=31161,fd=70))                       
UNCONN 0      0                [fe80::224:8cff:fe88:9df3]%eth0:53            [::]:*    users:(("named",pid=31161,fd=68))                       
UNCONN 0      0                [fe80::224:8cff:fe88:9df3]%eth0:53            [::]:*    users:(("named",pid=31161,fd=69))                       
UNCONN 0      0                [fe80::224:8cff:fe88:9df3]%eth0:53            [::]:*    users:(("named",pid=31161,fd=66))                       
UNCONN 0      0      [fd2f:4760:521f:3f3c:dfa8:4776:af35:9354]:53            [::]:*    users:(("named",pid=31161,fd=75))                       
UNCONN 0      0      [fd2f:4760:521f:3f3c:dfa8:4776:af35:9354]:53            [::]:*    users:(("named",pid=31161,fd=72))                       
UNCONN 0      0      [fd2f:4760:521f:3f3c:dfa8:4776:af35:9354]:53            [::]:*    users:(("named",pid=31161,fd=74))                       
UNCONN 0      0      [fd2f:4760:521f:3f3c:dfa8:4776:af35:9354]:53            [::]:*    users:(("named",pid=31161,fd=71))                       
UNCONN 0      0       [fd2f:4760:521f:3f3c:224:8cff:fe88:9df3]:53            [::]:*    users:(("named",pid=31161,fd=83))                       
UNCONN 0      0       [fd2f:4760:521f:3f3c:224:8cff:fe88:9df3]:53            [::]:*    users:(("named",pid=31161,fd=82))                       
UNCONN 0      0       [fd2f:4760:521f:3f3c:224:8cff:fe88:9df3]:53            [::]:*    users:(("named",pid=31161,fd=81))                       
UNCONN 0      0       [fd2f:4760:521f:3f3c:224:8cff:fe88:9df3]:53            [::]:*    users:(("named",pid=31161,fd=80))                       
UNCONN 0      0               [fd2f:4760:521f:3f3c::c0a8:456d]:53            [::]:*    users:(("named",pid=31161,fd=79))                       
UNCONN 0      0               [fd2f:4760:521f:3f3c::c0a8:456d]:53            [::]:*    users:(("named",pid=31161,fd=76))                       
UNCONN 0      0               [fd2f:4760:521f:3f3c::c0a8:456d]:53            [::]:*    users:(("named",pid=31161,fd=77))                       
UNCONN 0      0               [fd2f:4760:521f:3f3c::c0a8:456d]:53            [::]:*    users:(("named",pid=31161,fd=78))                       
UNCONN 0      0      [fd2f:4760:521f:3f3c:e187:d456:f65a:4dc2]:53            [::]:*    users:(("named",pid=31161,fd=89))                       
UNCONN 0      0      [fd2f:4760:521f:3f3c:e187:d456:f65a:4dc2]:53            [::]:*    users:(("named",pid=31161,fd=84))                       
UNCONN 0      0      [fd2f:4760:521f:3f3c:e187:d456:f65a:4dc2]:53            [::]:*    users:(("named",pid=31161,fd=85))                       
UNCONN 0      0      [fd2f:4760:521f:3f3c:e187:d456:f65a:4dc2]:53            [::]:*    users:(("named",pid=31161,fd=88))                       
UNCONN 0      0                                           [::]:5353          [::]:*    users:(("avahi-daemon",pid=1054,fd=12))

deano_ferrari · May 18, 2026, 6:55pm

The output that was shared changes things a bit. It shows that named is listening on the following IPv6 addresses:
fd2f:4760:521f:3f3c:dfa8:4776:af35:9354
fd2f:4760:521f:3f3c:224:8cff:fe88:9df3
but the dropped packet was addressed to fd2f:4760:521f:3f3c::c0a8:456d.

I do not see that address in the pasted ss output, but not clear if you posted the complete output, so I’m not sure whether named is actually listening on that specific IPv6 address?

jimbobrae · May 18, 2026, 7:36pm

Possibly you missed it? Is there a notation that indicates if it is active?

UNCONN 0      0               [fd2f:4760:521f:3f3c::c0a8:456d]:53            [::]:*    users:(("named",pid=31161,fd=79))                       
UNCONN 0      0               [fd2f:4760:521f:3f3c::c0a8:456d]:53            [::]:*    users:(("named",pid=31161,fd=76))                       
UNCONN 0      0               [fd2f:4760:521f:3f3c::c0a8:456d]:53            [::]:*    users:(("named",pid=31161,fd=77))                       
UNCONN 0      0               [fd2f:4760:521f:3f3c::c0a8:456d]:53            [::]:*    users:(("named",pid=31161,fd=78))

deano_ferrari · May 18, 2026, 7:57pm

Too early in the morning here (more coffee needed)

Are DNS queries actually failing? Or are you just concerned by the log entries?

jimbobrae · May 18, 2026, 10:19pm

Yes, the queries fail, The incoming packets are dropped.

Looking at the rules, it seems there is a time limit on the number of packets per minute and second and that limit is quickly reached. I see no purpose for the rules and would like to disable them.

deano_ferrari · May 19, 2026, 12:14am

Please share the output from sudo nft -a list ruleset.

jimbobrae · May 19, 2026, 4:41am

$ sudo nft -a list ruleset
$

deano_ferrari · May 19, 2026, 6:01am

No active nftables ruleset loaded? Is firewalld active?
sudo systemctl status firewalld

On your system sudo ip6tables -vnL yielded output - historical or transitional configuration? Your earlier ip6tables -vnL output clearly showed active IPv6 rules/chains/counters and SFW2-* logging rules, so something has instantiated a legacy ip6tables ruleset.

That is not what I would normally expect on a default Leap 15.6 firewalld+nftables system, so I’m wondering whether there is some historical or transitional firewall configuration present from an earlier openSUSE release or previous firewall framework.

jimbobrae · May 19, 2026, 5:14pm

$ sudo systemctl status firewalld
 firewalld.service - firewalld - dynamic firewall daemon
     Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; preset: disabled)
     Active: inactive (dead)
       Docs: man:firewalld(1)
$

It would seem not. This computer started using opensuse about 16 years ago. It has gone through 2 major hardware upgrades, the last one about 12 years ago. I suppose some older software is still running.

How much trouble is it to switch to firewalld?

deano_ferrari · May 19, 2026, 5:33pm

Ok, that confirms my suspicion, hence me asking earlier in this thread about whether this firewall config had been inherited from older/legacy Leap versions.

Migrating to modern firewalld/nftables is certainly possible, but I would approach it cautiously on a long-lived system providing DNS services. You would first want to fully understand the current legacy firewall behaviour before replacing it.

Is this a system you administer? Does it provide any other important services?

deano_ferrari · May 19, 2026, 5:37pm

Also check if legacy SuSEfirewall2 is active…
sudo systemctl status SuSEfirewall2

jimbobrae · May 19, 2026, 5:58pm

Yes.
No.
Its role as a DNS server is recent. It has mostly been a backup user station since our business was sold.


$ sudo systemctl status SuSEfirewall2
● SuSEfirewall2.service - SuSEfirewall2 phase 2
     Loaded: loaded (/usr/lib/systemd/system/SuSEfirewall2.service; enabled; preset: disabled)
     Active: active (exited) since Tue 2026-05-19 10:31:31 MST; 21min ago
    Process: 24293 ExecStart=/usr/sbin/SuSEfirewall2 boot_setup (code=exited, status=0/SUCCESS)
   Main PID: 24293 (code=exited, status=0/SUCCESS)
        CPU: 1.585s

May 19 10:31:29 sma-station12l.sma.com SuSEfirewall2[24343]: /usr/bin/stat: cannot statx '/etc/sysconfig/SuSEfirewall2.d>
May 19 10:31:29 sma-station12l.sma.com SuSEfirewall2[24293]: Cannot stat file /etc/sysconfig/SuSEfirewall2.d/services/sa>
May 19 10:31:29 sma-station12l.sma.com SuSEfirewall2[24344]: /usr/bin/stat: cannot statx '/usr/share/SuSEfirewall2/servi>
May 19 10:31:29 sma-station12l.sma.com SuSEfirewall2[24293]: Cannot stat file /usr/share/SuSEfirewall2/services/samba-se>
May 19 10:31:29 sma-station12l.sma.com SuSEfirewall2[24293]: Warning: config 'samba-server' not available
May 19 10:31:29 sma-station12l.sma.com SuSEfirewall2[24345]: <36>May 19 10:31:29 SuSEfirewall2[24293]: Warning: config '>
May 19 10:31:29 sma-station12l.sma.com SuSEfirewall2[24352]: sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_he>
May 19 10:31:29 sma-station12l.sma.com SuSEfirewall2[24293]: /usr/sbin/SuSEfirewall2: line 1624: [: : integer expression>
May 19 10:31:30 sma-station12l.sma.com SuSEfirewall2[24293]: Firewall rules successfully set
May 19 10:31:31 sma-station12l.sma.com systemd[1]: Finished SuSEfirewall2 phase 2.

deano_ferrari · May 19, 2026, 7:05pm

Ok, at this point I’m going to point you at
https://en.opensuse.org/Firewalld
which provides information on Firewalld as well as a " susefirewall2-to-firewalld" script to help with migration.

However, if your existing firewall config or requirements are reasonably simple, then the following may be sufficient…

sudo systemctl disable --now SuSEfirewall2
sudo systemctl enable --now firewalld

then permit DNS service in firewalld…

sudo firewall-cmd --permanent --add-service=dns
sudo firewall-cmd --reload

That should permit both IPv4 and IPv6 DNS traffic using the modern nftables backend. You can then test IPv4 and IPv6 queries to make sure it is working as expected.

Note: By default, with firewalld, if not specifically configured otherwise, interfaces typically end up assigned to the default zone, which on openSUSE is usually public. You can check for yourself with…

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zone
sudo firewall-cmd --list-all

The zones effectively provide predefined/default trust levels and service exposure policies. You can then further permit or restrict individual services (such as DNS) within the selected zone.

This will show all available zones, including the default (public) zone), and how they are configured…
sudo firewalld-cmd --list-all-zones

For example if you prefer to use another zone (eg internal), you add the interface in question (eg eth0) and the required services to allow like this…

sudo firewall-cmd --permanent --zone=internal --change-interface=eth0
sudo firewall-cmd --permanent --zone=internal --add-service=dns
sudo firewall-cmd --reload

jimbobrae · May 19, 2026, 8:32pm

I decided go the full susefirewall-to-firewalld route. There was one minor error, easily corrected (re-connecting eth0 to zone external). The installation went smoothly after that.

The change has cured the dropped DNS packets issue. Yay!

The journal is now littered with these new entries, though:

2026-05-19T13:06:18-0700 sma-station12l.sma.com kernel: filter_IN_external_REJECT: IN=eth0 OUT= MAC=33:33:00:00:00:01:ac:86:74:73:9c:60:86:dd SRC=fe80:0000:0000:0000:ae86:74ff:fe73:9c60 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=52 TC=0 HOPLIMIT=1 FLOWLBL=103921 PROTO=UDP SPT=16962 DPT=16962 LEN=12 
2026-05-19T13:06:28-0700 sma-station12l.sma.com kernel: filter_IN_external_REJECT: IN=eth0 OUT= MAC=01:00:5e:00:00:01:80:3f:5d:55:3f:5b:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2

How do I find these rules (?) and disable them?

Then there is this:

$ iptables -vnL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 6708 2331K NFQUEUE    all  --  *      *       0.0.0.0/0            0.0.0.0/0            NFQUEUE num 0 bypass

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 5657  574K NFQUEUE    all  --  *      *       0.0.0.0/0            0.0.0.0/0            NFQUEUE num 0 bypass

Which, I believe, indicates there is only one rule: NFQUEUE (it is expected). So, from where do the bonus REJECT entries arise?

deano_ferrari · May 19, 2026, 9:21pm

Firewalld is logging and rejecting multicast discovery traffic. You’re using the relatively strict external zone. If this is a trusted LAN interface rather than an Internet-facing interface, home or internal may be more appropriate for your needs. The packets themselves are fairly typical LAN multicast chatter and are usually harmless.

You could examine sudo nft list ruleset, but you don’t normally edit these directly. Instead choose a more appropriate zone, or consider allowing the required multicast protocols/services.

jimbobrae · May 19, 2026, 10:18pm

I changed the zone to home. It did not seem to make any difference to the number of log entries.

Since the number of log entries represent most of the journal at this point, it becomes quite difficult to see anything else in the journal.

How do I identify those multicast protocols/services?

deano_ferrari · May 19, 2026, 10:47pm

Those particular packets are mostly low-level multicast/broadcast discovery from other devices on your LAN, rather than named “services” in the usual sense.

The log examples you shared:

DST=224.0.0.1 PROTO=2 is IPv4 IGMP multicast membership traffic.
DST=ff02::1 is IPv6 link-local multicast traffic

Up to you how you want to handle it. These are very common on LANs and are often harmless background chatter from printers, TVs, IoT devices, etc.

If the real problem is “journal spam”, you could suppress it (disable firewalld denied-packet logging) with…

sudo firewall-cmd --set-log-denied=off

If you want to allow IGMP traffic, then do

sudo firewall-cmd --permanent --zone=home --add-protocol=igmp sudo firewall-cmd --reload

I’m not sure about the ICMPv6 multicast/listener discovery behaviour. It would probably require a rich rule to explicitly allow it. This kind of multicast chatter is generally harmless and best left dropped rather than broadly permitted unless you need it. On a simple workstation or DNS server, most of this traffic is usually unnecessary and safely dropped IMHO.