Been driving me mad STAFF VLAN client DNS to gateway: queries arrive at firewall

Started by Orionrise, June 15, 2026, 07:31:10 PM

Previous topic - Next topic
Solved — and it wasn't the igc driver after all.
Posting the resolution in case it helps anyone who finds this thread with the same signature (DNS to the gateway times out on one VLAN while external DNS and everything else works).
The root cause was my own firewall rules, not the hardware or the driver. My per-VLAN "block inter-VLAN" rule used the shared RFC1918 alias as its destination. Because RFC1918 includes the VLAN's own subnet, that block also matched the VLAN's gateway address — and in the live ruleset the "allow DNS to gateway" rule had ended up below the block. With quick/first-match evaluation, a DNS query to the gateway hit the RFC1918 block first and was silently dropped, so Unbound never saw it. DNS to 1.1.1.1 worked because 1.1.1.1 isn't in RFC1918 and matched a later pass rule. That's why it looked like a receive-path/driver issue — but DHCP, internet and the sibling VLAN all worked because none of them tripped that specific block.
What finally found it was reading the live generated ruleset over SSH rather than trusting the GUI order: pfctl -sr | grep -n vlan<id>. The block was clearly sitting ahead of the gateway-DNS allow there, even though the GUI looked fine (mixed classic + automation rules can display in a different order than they're generated).
Fix: I scoped the block to a bespoke per-VLAN alias that lists every internal subnet except that VLAN's own (so the gateway can never be caught by it), repointed the block rule at it, applied, and DNS to the gateway resolved immediately. Made this the standard on every VLAN so it's immune to rule-order drift.
Future note for anyone hitting this: if one VLAN can't reach its own gateway for DNS but everything else works, check whether your inter-VLAN block alias contains that VLAN's own subnet, and verify the real order with pfctl -sr, not just the GUI. Thanks to everyone who weighed in.