"Recent posts
#1
26.1, 26,4 Series / Re: WAN Interface Statistics n...
Last post by cookiemonster - Today at 12:00:46 AMAfter the interface change the reporting database might have become corrupted. Just a guess.
Perhaps resetting would help? Reporting > Settings > Reporting Database Options.
There are options to reset / repair but beware, I imagine there could be data loss. I am not certain if the actions taken are destructive.
In the past when I changed interface hardware I had to do this. It didn't matter to me if resetting would reset to zero data but it fixed my reporting problem similar to yours.
Perhaps resetting would help? Reporting > Settings > Reporting Database Options.
There are options to reset / repair but beware, I imagine there could be data loss. I am not certain if the actions taken are destructive.
In the past when I changed interface hardware I had to do this. It didn't matter to me if resetting would reset to zero data but it fixed my reporting problem similar to yours.
#2
26.1, 26,4 Series / WAN Interface Statistics not w...
Last post by Component0002 - June 15, 2026, 11:17:31 PMHello,
I have upgraded my firewall to a Mellanox ConnectX-3 Pro from an Intel 4 port 1Gbps NIC. I reinstalled Opnsense enabled the kernel module with mlx4en_load=YES, edited the interface names in my config and reimported it.
Everyone works correctly apart from the Interface Statistics on the Dashboard. This will regularly go down even though I'm not restarting the firewall.
For example, currently it is at 1.73GB bytes out but if I check back in a few minutes it will be at 1.2GB bytes out. I have also had it regularly go to 18.45E which I believe is 18.45 Exabytes. This happens within minutes of the firewall having started so it is obviously not true as I only have a 900Mbps line...
Furthermore, when this happens it breaks the live traffic graph and the units are all wrong. I have confirmed that this bug happens with 26.1.9 and also with 26.1.10 now.
This was never an issue with the Intel card so I'm wondering if it is an issue with the driver? The VLAN Interface Statistics display without any issues.
How do I resolve this issue? I have checked the logs but I can't see any errors here.
I have upgraded my firewall to a Mellanox ConnectX-3 Pro from an Intel 4 port 1Gbps NIC. I reinstalled Opnsense enabled the kernel module with mlx4en_load=YES, edited the interface names in my config and reimported it.
Everyone works correctly apart from the Interface Statistics on the Dashboard. This will regularly go down even though I'm not restarting the firewall.
For example, currently it is at 1.73GB bytes out but if I check back in a few minutes it will be at 1.2GB bytes out. I have also had it regularly go to 18.45E which I believe is 18.45 Exabytes. This happens within minutes of the firewall having started so it is obviously not true as I only have a 900Mbps line...
Furthermore, when this happens it breaks the live traffic graph and the units are all wrong. I have confirmed that this bug happens with 26.1.9 and also with 26.1.10 now.
This was never an issue with the Intel card so I'm wondering if it is an issue with the driver? The VLAN Interface Statistics display without any issues.
How do I resolve this issue? I have checked the logs but I can't see any errors here.
#3
26.1, 26,4 Series / Re: Been driving me mad STAFF ...
Last post by cookiemonster - June 15, 2026, 11:02:33 PMI was going to ask about Network Interfaces: All (recommended) but that is set correct.
At this point I wonder if you have one of those obscure cases of VLANs mixing traffic with tagged and untagged. Can you check for that? What we're looking for is the setup, where your trunk to OPN has ONLY tagged traffic.
At this point I wonder if you have one of those obscure cases of VLANs mixing traffic with tagged and untagged. Can you check for that? What we're looking for is the setup, where your trunk to OPN has ONLY tagged traffic.
#4
26.1, 26,4 Series / Re: Kea + Unbound + Bind for l...
Last post by tkreagan - June 15, 2026, 09:25:12 PMHi all — I've been following this topic and wanted to share something I built that I think addresses exactly this problem.
**os-kea-ubnd-ddns** is an OPNsense plugin that bridges Kea DHCP → Unbound DNS directly, without Bind. It runs a lightweight RFC 2136 stub listener that receives DNS UPDATE packets from `kea-dhcp-ddns` and applies them to Unbound via `unbound-control` — so you get real-time hostname registration when a lease is issued - no zone files, no journal corruption, no `.jnl` cleanup.
**What it solves from this thread specifically:**
- No Bind required — Unbound stays the primary resolver, so blocklists and per-client analytics work normally
- No journal files or `rndc sync -clean` — Unbound `local_data` is ephemeral and gets rebuilt from Kea on restart
- IPv4 and IPv6 (A, AAAA, PTR) all handled — including dual-stack hosts where the same hostname has both an A and AAAA record
- The "RRset exists" race condition doesn't apply — the listener processes one UPDATE at a time and Unbound's local_data is not authoritative in the RFC 2136 sense
There's also a **Config Check** tab that reads your live Kea config and flags common mistakes (missing trailing dots on zone names, subnets with DDNS disabled, kea-dhcp-ddns listener state) — and a one-click **Configure All Subnets** button that pushes the correct DDNS settings to every subnet automatically.
Tested on OPNsense 26.1 with Kea DHCP4 and DHCP6. Current version is 0.96.
GitHub: https://github.com/tkreagan/os-kea-ubnd-ddns
Pre-built package on the releases page — `pkg add os-kea-ubnd-ddns-0.96.pkg`, no package repo needed.
Happy to answer questions here but GitHub issues might be easier.
**os-kea-ubnd-ddns** is an OPNsense plugin that bridges Kea DHCP → Unbound DNS directly, without Bind. It runs a lightweight RFC 2136 stub listener that receives DNS UPDATE packets from `kea-dhcp-ddns` and applies them to Unbound via `unbound-control` — so you get real-time hostname registration when a lease is issued - no zone files, no journal corruption, no `.jnl` cleanup.
**What it solves from this thread specifically:**
- No Bind required — Unbound stays the primary resolver, so blocklists and per-client analytics work normally
- No journal files or `rndc sync -clean` — Unbound `local_data` is ephemeral and gets rebuilt from Kea on restart
- IPv4 and IPv6 (A, AAAA, PTR) all handled — including dual-stack hosts where the same hostname has both an A and AAAA record
- The "RRset exists" race condition doesn't apply — the listener processes one UPDATE at a time and Unbound's local_data is not authoritative in the RFC 2136 sense
There's also a **Config Check** tab that reads your live Kea config and flags common mistakes (missing trailing dots on zone names, subnets with DDNS disabled, kea-dhcp-ddns listener state) — and a one-click **Configure All Subnets** button that pushes the correct DDNS settings to every subnet automatically.
Tested on OPNsense 26.1 with Kea DHCP4 and DHCP6. Current version is 0.96.
GitHub: https://github.com/tkreagan/os-kea-ubnd-ddns
Pre-built package on the releases page — `pkg add os-kea-ubnd-ddns-0.96.pkg`, no package repo needed.
Happy to answer questions here but GitHub issues might be easier.
#5
26.1, 26,4 Series / Re: Been driving me mad STAFF ...
Last post by Orionrise - June 15, 2026, 08:46:42 PMThanks. Here are the full Services → Unbound DNS → General settings (advanced mode on):
Enable Unbound: enabled
Listen Port: 53
Network Interfaces: All (recommended)
Enable DNSSEC Support: off
Enable DNS64 Support: off
Enable AAAA-only mode: off
Register ISC DHCP4 Leases: off
DHCP Domain Override: empty
Register DHCP Static Mappings: on
Do not register IPv6 Link-Local addresses: off
Do not register system A/AAAA records: off
TXT Comment Support: off
Flush DNS Cache during reload: on
Force SafeSearch: off
Local Zone Type: transparent
Recursion mode (no query forwarding). Access Lists allow 192.168.20.0/24 (STAFF). Listening socket confirmed on *:53 (udp4/tcp4). The firewall's own DNS Lookup tool resolves fine, and MGMT VLAN clients resolve through this same Unbound with no problem — only STAFF (VLAN 20) fails, and its queries never appear in the Unbound query log at all.
Enable Unbound: enabled
Listen Port: 53
Network Interfaces: All (recommended)
Enable DNSSEC Support: off
Enable DNS64 Support: off
Enable AAAA-only mode: off
Register ISC DHCP4 Leases: off
DHCP Domain Override: empty
Register DHCP Static Mappings: on
Do not register IPv6 Link-Local addresses: off
Do not register system A/AAAA records: off
TXT Comment Support: off
Flush DNS Cache during reload: on
Force SafeSearch: off
Local Zone Type: transparent
Recursion mode (no query forwarding). Access Lists allow 192.168.20.0/24 (STAFF). Listening socket confirmed on *:53 (udp4/tcp4). The firewall's own DNS Lookup tool resolves fine, and MGMT VLAN clients resolve through this same Unbound with no problem — only STAFF (VLAN 20) fails, and its queries never appear in the Unbound query log at all.
#6
26.1, 26,4 Series / Re: Been driving me mad STAFF ...
Last post by newsense - June 15, 2026, 08:24:45 PMNeed to see the Services-Unbound-General page
#7
26.1, 26,4 Series / Re: Been driving me mad STAFF ...
Last post by Orionrise - June 15, 2026, 07:47:46 PMThis is the only thing I have found after many days of fighting this. Follow-up — possible related lead (GitHub #8231)
While waiting I did some digging and came across OPNsense core issue #8231, which may be the same class of problem — I'd be grateful if anyone can confirm or rule it out.
In that report, traffic to one network on a physical interface silently stopped passing after a version/kernel change, while other VLANs on the same NIC continued to work, with the configuration provably correct. The reporter notes that inbound VLAN traffic was visible in OPNsense but tagged traffic originating from the firewall did not pass, with no rule blocking it — and that moving the VLAN to a different igc port behaved identically. They resolved it only by rolling the kernel back (running 24.7.9 / kernel 24.7.8).
That lines up closely with what I'm seeing:
queries arrive on the VLAN interface but the firewall never replies (no pf verdict, no Unbound log entry),
a second VLAN on the same igc0 parent works perfectly,
and a full delete/recreate of the VLAN interface made no difference.
Their trigger was tagged-vs-untagged on one NIC; mine is one tagged VLAN vs another on the same parent — but the underlying shape (a receive/transmit-path issue on igc that silently affects one network on a multi-VLAN interface, independent of config) seems to match.
Two questions for anyone who knows this area:
Is my symptom likely the same igc / kernel-level class as #8231, and is it present in the current 26.1 line?
The thread also mentions the netmap tunable (dev.netmap.admode) and "can't allocate llinfo" errors. I don't knowingly run an inline IPS or Sensei/Zenarmor, but is netmap on igc a plausible mechanism here, and is there a quick way to confirm whether it's intercepting on my STAFF interface?
Reference: github.com/opnsense/core/issues/8231
Happy to provide any further captures, pfctl output, or the full config. Thanks again.
While waiting I did some digging and came across OPNsense core issue #8231, which may be the same class of problem — I'd be grateful if anyone can confirm or rule it out.
In that report, traffic to one network on a physical interface silently stopped passing after a version/kernel change, while other VLANs on the same NIC continued to work, with the configuration provably correct. The reporter notes that inbound VLAN traffic was visible in OPNsense but tagged traffic originating from the firewall did not pass, with no rule blocking it — and that moving the VLAN to a different igc port behaved identically. They resolved it only by rolling the kernel back (running 24.7.9 / kernel 24.7.8).
That lines up closely with what I'm seeing:
queries arrive on the VLAN interface but the firewall never replies (no pf verdict, no Unbound log entry),
a second VLAN on the same igc0 parent works perfectly,
and a full delete/recreate of the VLAN interface made no difference.
Their trigger was tagged-vs-untagged on one NIC; mine is one tagged VLAN vs another on the same parent — but the underlying shape (a receive/transmit-path issue on igc that silently affects one network on a multi-VLAN interface, independent of config) seems to match.
Two questions for anyone who knows this area:
Is my symptom likely the same igc / kernel-level class as #8231, and is it present in the current 26.1 line?
The thread also mentions the netmap tunable (dev.netmap.admode) and "can't allocate llinfo" errors. I don't knowingly run an inline IPS or Sensei/Zenarmor, but is netmap on igc a plausible mechanism here, and is there a quick way to confirm whether it's intercepting on my STAFF interface?
Reference: github.com/opnsense/core/issues/8231
Happy to provide any further captures, pfctl output, or the full config. Thanks again.
#8
26.1, 26,4 Series / Been driving me mad STAFF VLAN...
Last post by Orionrise - June 15, 2026, 07:31:10 PMSummary
A client on a tagged VLAN (STAFF, VLAN 20) cannot resolve DNS via the firewall's own interface IP (192.168.20.1), but the same VLAN routes to the internet fine (TCP/443/80 works, ping 1.1.1.1 works). A packet capture proves the DNS query arrives at 192.168.20.1:53 on the VLAN interface, but the firewall never sends a reply — Unbound never logs the query, and pf logs no block or pass verdict for it. DNS works perfectly for a client on the MGMT VLAN (192.168.10.0/24) using the same Unbound instance.
Disabling the firewall entirely (Firewall > Settings > Advanced > Disable all packet filtering) makes STAFF DNS work — so it is pf/packet-path related, not Unbound itself.
I have eliminated a large number of causes (listed below) and would appreciate eyes from anyone who knows igc / VLAN receive-path behaviour.
Hardware / software
Appliance: Protectli VP2420 (Intel quad-port, igc driver)
OPNsense: 26.1 Community Edition
LAN trunk: igc0, carrying all VLANs (10–80) tagged to a UniFi USW-Pro-Max-16 switch
STAFF interface: vlan02, parent igc0, VLAN tag 20, static 192.168.20.1/24
Resolver: Unbound, recursion mode (forwarding disabled), listening on All interfaces, port 53, transparent local zone
DHCP: Kea, hands out 192.168.20.1 as gateway + DNS to STAFF clients
WAN: behind an ISP router that cannot bridge (double-NAT; OPNsense WAN is 192.168.1.119)
Firmware status: OPNsense 26.1 Community Edition (config confirms community flavour — no business subscription). Running the current 26.1 line; no firmware update was offered when last checked, so believed to be up to date on the latest 26.1.x point release.
Symptoms
STAFF client gets correct DHCP lease: IP 192.168.20.50, GW 192.168.20.1, DNS 192.168.20.1
STAFF client can ping 1.1.1.1 and reach internet hosts over TCP (443/80) — confirmed in state table, NAT'd out WAN correctly
STAFF client cannot resolve any DNS name via 192.168.20.1
MGMT client (192.168.10.51) resolves through the same Unbound with no issue
Reproduced on a second, different laptop with a built-in NIC (rules out the first client's USB-Ethernet dongle)
The decisive evidence (packet capture)
Packet capture on interface vlan02 [STAFF], UDP, port 53, host filter blank (both directions). After running nslookup on the STAFF client, the capture shows only outbound queries, never a single reply:
192.168.20.50.57604 > 192.168.20.1.53: [udp sum ok] 4+ A? google.com. (28)
192.168.20.50.57605 > 192.168.20.1.53: [udp sum ok] 5+ AAAA? google.com. (28)
... (many more, all client -> 192.168.20.1:53, all [udp sum ok])
There is not one 192.168.20.1.53 > 192.168.20.50 line in the entire capture. Queries arrive with valid checksums; the firewall answers nothing.
Searching the Unbound query log for 192.168.20.50 returns no results — Unbound never receives the query. Meanwhile MGMT (192.168.10.51) queries appear and are answered NOERROR in the same log.
The firewall live/plain log filtered on 192.168.20.50 shows only the DHCP pass (UDP 68->67); there is no pass and no block verdict for the port-53 traffic. Default block AND default pass logging are both enabled.
What I have already checked / eliminated
Firewall rules (STAFF tab): "Allow STAFF DNS" pass rule for dest 192.168.20.1:53, quick, at top of automation rules. Only block targets MGMT net, not RFC1918. Confirmed correct.
Floating rules: none defined.
Outbound NAT: Automatic mode, both auto rules are Interface=WAN only — do not apply to traffic destined to the firewall's own VLAN IP.
reply-to: "Disable reply-to on WAN rules" toggled ON, states reset — no change.
Normalization / scrub: all default, no custom scrub rules.
Unbound config: Enabled, Listen Port 53, Network Interfaces = All (recommended), DNSSEC off, transparent local zone, ACL explicitly allows 192.168.20.0/24. Full stop/start performed. Reboot performed.
Hardware offloading: disabled hardware checksum / TSO / LRO, and set VLAN Hardware Filtering = Disable, rebooted — no change.
DNS over TLS forwarders: removed (recursion only).
Dnsmasq: was on port 53053/LAN only, now stopped — not involved.
Listening sockets (netstat): unbound is bound to *:53 (udp4 and tcp4) — so a valid socket exists for 192.168.20.1:53.
ARP: STAFF client correctly resolves 192.168.20.1 to igc0/LAN trunk MAC; L2 adjacency confirmed.
Config-level verification: a saved config snapshot from before the recreate confirms the old vlan02 (STAFF) was defined identically to its working siblings — tag 20, pcp 0, same parent igc0, and a minimal clean interface block (just IP 192.168.20.1/24, enabled). No malformed entry, no stray gateway/MTU/flags. The fault is not in the config.
Switch: STAFF client learned on the correct access port (Port 5) in VLAN 20; firewall uplink trunk (Port 1) carries VLAN 20 tagged. UniFi port health for Port 5 reports Cables & Power, Network Loops, Broadcasts, and Traffic Path Health all "Excellent", anomaly score 0, zero errors/discards. MAC table shows the client correctly on VLAN 20. Switch is clean.
Same parent NIC for working vs broken VLAN: MGMT (vlan01, tag 10) and STAFF (vlan02, tag 20) are BOTH children of parent igc0. MGMT resolves fine, STAFF does not — same physical NIC, same trunk, same switch, same Unbound. The only difference between working and broken is the VLAN tag itself. (Note: UniFi cosmetically labels both networks' subnet as 192.168.1.0/24 and STAFF's native VLAN as "20 (undefined)"; MGMT shows the same cosmetic labels and works, so these are not causal.)
Client: single active adapter, single default route via 192.168.20.1, correct DNS server, Wi-Fi disabled. Reproduced on a second machine with a built-in NIC.
Disable Firewall test: with all packet filtering disabled, STAFF DNS works — confirming it is pf/packet-path, not Unbound.
Full VLAN interface recreate (the big one): I deleted the STAFF interface assignment, deleted the underlying vlan02 device entirely, recreated a fresh VLAN device (auto-named vlan09, parent igc0, tag 20, Best Effort priority), reassigned it as the STAFF interface (it re-took the opt2 identifier), re-added 192.168.20.1/24, and re-added an explicit "Allow STAFF DNS to gateway" pass rule (STAFF net -> STAFF address, port 53, TCP/UDP, ordered above the inter-VLAN block). The fault is completely unchanged on the brand-new device — STAFF DNS still fails identically. This rules out a corrupted or half-bound interface: the problem follows VLAN tag 20 on igc0 regardless of how cleanly the interface is rebuilt.
The question
A UDP/53 packet is captured arriving on vlan02 destined for the firewall's own IP (192.168.20.1), with a valid checksum and a valid listening socket (*:53), yet:
it is never delivered to Unbound (no query log entry),
the firewall never emits a reply,
pf logs no pass/block verdict for it,
the same Unbound answers another VLAN (MGMT) fine,
and disabling pf entirely makes it work.
What would cause inbound UDP-to-self on one tagged VLAN to be dropped between the NIC and the listening socket, without a pf verdict, while transit traffic and a SECOND VLAN on the very same parent NIC (igc0) work normally? Both MGMT (tag 10) and STAFF (tag 20) ride igc0; MGMT resolves, STAFF doesn't. I have already deleted and recreated the entire VLAN interface from scratch (fresh device, fresh assignment, fresh IP and rules) and the fault is identical on the new device — so this is not a corrupted interface. The problem follows VLAN tag 20 on igc0 specifically. Is this a known igc / VLAN hardware-filtering / netmap interaction, and what is the fix? Would changing the VLAN tag (e.g. moving STAFF off tag 20 to a different number) be a reasonable diagnostic to try?
Any pointers gratefully received — happy to provide pfctl output, full configs, or further captures.
A client on a tagged VLAN (STAFF, VLAN 20) cannot resolve DNS via the firewall's own interface IP (192.168.20.1), but the same VLAN routes to the internet fine (TCP/443/80 works, ping 1.1.1.1 works). A packet capture proves the DNS query arrives at 192.168.20.1:53 on the VLAN interface, but the firewall never sends a reply — Unbound never logs the query, and pf logs no block or pass verdict for it. DNS works perfectly for a client on the MGMT VLAN (192.168.10.0/24) using the same Unbound instance.
Disabling the firewall entirely (Firewall > Settings > Advanced > Disable all packet filtering) makes STAFF DNS work — so it is pf/packet-path related, not Unbound itself.
I have eliminated a large number of causes (listed below) and would appreciate eyes from anyone who knows igc / VLAN receive-path behaviour.
Hardware / software
Appliance: Protectli VP2420 (Intel quad-port, igc driver)
OPNsense: 26.1 Community Edition
LAN trunk: igc0, carrying all VLANs (10–80) tagged to a UniFi USW-Pro-Max-16 switch
STAFF interface: vlan02, parent igc0, VLAN tag 20, static 192.168.20.1/24
Resolver: Unbound, recursion mode (forwarding disabled), listening on All interfaces, port 53, transparent local zone
DHCP: Kea, hands out 192.168.20.1 as gateway + DNS to STAFF clients
WAN: behind an ISP router that cannot bridge (double-NAT; OPNsense WAN is 192.168.1.119)
Firmware status: OPNsense 26.1 Community Edition (config confirms community flavour — no business subscription). Running the current 26.1 line; no firmware update was offered when last checked, so believed to be up to date on the latest 26.1.x point release.
Symptoms
STAFF client gets correct DHCP lease: IP 192.168.20.50, GW 192.168.20.1, DNS 192.168.20.1
STAFF client can ping 1.1.1.1 and reach internet hosts over TCP (443/80) — confirmed in state table, NAT'd out WAN correctly
STAFF client cannot resolve any DNS name via 192.168.20.1
MGMT client (192.168.10.51) resolves through the same Unbound with no issue
Reproduced on a second, different laptop with a built-in NIC (rules out the first client's USB-Ethernet dongle)
The decisive evidence (packet capture)
Packet capture on interface vlan02 [STAFF], UDP, port 53, host filter blank (both directions). After running nslookup on the STAFF client, the capture shows only outbound queries, never a single reply:
192.168.20.50.57604 > 192.168.20.1.53: [udp sum ok] 4+ A? google.com. (28)
192.168.20.50.57605 > 192.168.20.1.53: [udp sum ok] 5+ AAAA? google.com. (28)
... (many more, all client -> 192.168.20.1:53, all [udp sum ok])
There is not one 192.168.20.1.53 > 192.168.20.50 line in the entire capture. Queries arrive with valid checksums; the firewall answers nothing.
Searching the Unbound query log for 192.168.20.50 returns no results — Unbound never receives the query. Meanwhile MGMT (192.168.10.51) queries appear and are answered NOERROR in the same log.
The firewall live/plain log filtered on 192.168.20.50 shows only the DHCP pass (UDP 68->67); there is no pass and no block verdict for the port-53 traffic. Default block AND default pass logging are both enabled.
What I have already checked / eliminated
Firewall rules (STAFF tab): "Allow STAFF DNS" pass rule for dest 192.168.20.1:53, quick, at top of automation rules. Only block targets MGMT net, not RFC1918. Confirmed correct.
Floating rules: none defined.
Outbound NAT: Automatic mode, both auto rules are Interface=WAN only — do not apply to traffic destined to the firewall's own VLAN IP.
reply-to: "Disable reply-to on WAN rules" toggled ON, states reset — no change.
Normalization / scrub: all default, no custom scrub rules.
Unbound config: Enabled, Listen Port 53, Network Interfaces = All (recommended), DNSSEC off, transparent local zone, ACL explicitly allows 192.168.20.0/24. Full stop/start performed. Reboot performed.
Hardware offloading: disabled hardware checksum / TSO / LRO, and set VLAN Hardware Filtering = Disable, rebooted — no change.
DNS over TLS forwarders: removed (recursion only).
Dnsmasq: was on port 53053/LAN only, now stopped — not involved.
Listening sockets (netstat): unbound is bound to *:53 (udp4 and tcp4) — so a valid socket exists for 192.168.20.1:53.
ARP: STAFF client correctly resolves 192.168.20.1 to igc0/LAN trunk MAC; L2 adjacency confirmed.
Config-level verification: a saved config snapshot from before the recreate confirms the old vlan02 (STAFF) was defined identically to its working siblings — tag 20, pcp 0, same parent igc0, and a minimal clean interface block (just IP 192.168.20.1/24, enabled). No malformed entry, no stray gateway/MTU/flags. The fault is not in the config.
Switch: STAFF client learned on the correct access port (Port 5) in VLAN 20; firewall uplink trunk (Port 1) carries VLAN 20 tagged. UniFi port health for Port 5 reports Cables & Power, Network Loops, Broadcasts, and Traffic Path Health all "Excellent", anomaly score 0, zero errors/discards. MAC table shows the client correctly on VLAN 20. Switch is clean.
Same parent NIC for working vs broken VLAN: MGMT (vlan01, tag 10) and STAFF (vlan02, tag 20) are BOTH children of parent igc0. MGMT resolves fine, STAFF does not — same physical NIC, same trunk, same switch, same Unbound. The only difference between working and broken is the VLAN tag itself. (Note: UniFi cosmetically labels both networks' subnet as 192.168.1.0/24 and STAFF's native VLAN as "20 (undefined)"; MGMT shows the same cosmetic labels and works, so these are not causal.)
Client: single active adapter, single default route via 192.168.20.1, correct DNS server, Wi-Fi disabled. Reproduced on a second machine with a built-in NIC.
Disable Firewall test: with all packet filtering disabled, STAFF DNS works — confirming it is pf/packet-path, not Unbound.
Full VLAN interface recreate (the big one): I deleted the STAFF interface assignment, deleted the underlying vlan02 device entirely, recreated a fresh VLAN device (auto-named vlan09, parent igc0, tag 20, Best Effort priority), reassigned it as the STAFF interface (it re-took the opt2 identifier), re-added 192.168.20.1/24, and re-added an explicit "Allow STAFF DNS to gateway" pass rule (STAFF net -> STAFF address, port 53, TCP/UDP, ordered above the inter-VLAN block). The fault is completely unchanged on the brand-new device — STAFF DNS still fails identically. This rules out a corrupted or half-bound interface: the problem follows VLAN tag 20 on igc0 regardless of how cleanly the interface is rebuilt.
The question
A UDP/53 packet is captured arriving on vlan02 destined for the firewall's own IP (192.168.20.1), with a valid checksum and a valid listening socket (*:53), yet:
it is never delivered to Unbound (no query log entry),
the firewall never emits a reply,
pf logs no pass/block verdict for it,
the same Unbound answers another VLAN (MGMT) fine,
and disabling pf entirely makes it work.
What would cause inbound UDP-to-self on one tagged VLAN to be dropped between the NIC and the listening socket, without a pf verdict, while transit traffic and a SECOND VLAN on the very same parent NIC (igc0) work normally? Both MGMT (tag 10) and STAFF (tag 20) ride igc0; MGMT resolves, STAFF doesn't. I have already deleted and recreated the entire VLAN interface from scratch (fresh device, fresh assignment, fresh IP and rules) and the fault is identical on the new device — so this is not a corrupted interface. The problem follows VLAN tag 20 on igc0 specifically. Is this a known igc / VLAN hardware-filtering / netmap interaction, and what is the fix? Would changing the VLAN tag (e.g. moving STAFF off tag 20 to a different number) be a reasonable diagnostic to try?
Any pointers gratefully received — happy to provide pfctl output, full configs, or further captures.
#9
26.1, 26,4 Series / Re: 26.1.9: Health graphs do n...
Last post by camellia - June 15, 2026, 07:25:37 PMI noticed that flat lines are not displayed in zoomed graph.
You cannot view this attachment.
It seems better to hide flat lines rather than displaying zero-value lines.
You cannot view this attachment.
It seems better to hide flat lines rather than displaying zero-value lines.
#10
