Messages

You edit the subject line of your first post and write e.g. "[SOLVED]" in it.

Thanks, easy enough!

I fixed the problem, well, not a complete fix, but a fix nonetheless. I defined those VLANs I was working with awhile back, perhaps a year ago, and left them as-is, with default setups, just skeleton VLAN definitions. When I created new VLANs through the GUI, connectivity worked fine, no odd behavior. So I deleted those old VLAN definitions I had created awhile back, and created new VLANs from scratch. The new ones worked perfectly fine. No more problems. 

I have no idea what was causing the other, older VLANs to not pass traffic, even though the rules, DHCP, interface assignments all looked good. This can be closed as resolved, I just don't know how to resolve these threads or if it needs to be done by a moderator.

Logging is not enabled on every rule, only selectively. For the DNS path itself, the explicit VLAN20 DNS pass rules are matching, and packet captures show the DNS queries leaving VLAN20 and the replies arriving on VLAN40. I did not get a useful drop/state-mismatch-specific clue from pflog yet.I agree the nonzero state-mismatch counter may still be relevant.I have not yet tested ping from the firewall to the affected client, so that is a good suggestion and I'll check that next. Client->firewall ping was not useful because ICMP to the gateway was intentionally disabled on that VLAN during testing.

No explicit gateway is set on the involved VLAN20 (client)/VLAN40 (Services) DNS rules. The VLAN20 and VLAN40 interfaces are just the local routed interfaces (192.168.20.1/24 and 192.168.40.1/24). So this does not appear to be caused by a gateway being attached to the DNS pass rules.

I checked the live interface config on OPNsense. The client VLAN interface is 192.168.20.1/24 (255.255.255.0), which matches the intended subnet. So the client VLAN interface mask on OPNsense does not appear to be incorrect.

The client on the VLAN network is getting a valid IP/subnet mask/gateway/DNS server assignment as well. Appreciate the input so far.

The VLANs are intentionally separate routed /24 networks. The problem is not that the client can't identify its own subnet; the problem is that DNS replies are visible arriving on the services VLAN but are not visible leaving back toward the client VLAN.

[OPNsense 26.1.4 / FreeBSD 14.3]

I'm troubleshooting an internal DNS issue on OPNsense 26.1.4 / FreeBSD 14.3.
Setup

• one client VLAN
• one services VLAN
• internal DNS servers are on the services VLAN
• client VLAN has explicit allow rules to both DNS servers on TCP/UDP 53
• hardware offloading is disabled:
• checksum offload
• TSO
• LRO
• VLAN hardware filtering

Problem
A client on the client VLAN repeatedly sends DNS queries to two internal DNS servers. The DNS servers reply immediately, but the client keeps retrying the same queries as if it never receives the responses.
Packet capture results
I captured on:

• the client VLAN interface
• the services VLAN interface
• the parent LACP interface
• the individual LACP member interfaces

What I see:

• On the services VLAN interface, I see the full exchange:
• client -> DNS query
• DNS server -> client reply
• On the client VLAN interface, I only see:
• client -> DNS query
• I do not see the matching reply
• On the parent trunk interface, I see:
• VLAN-tagged DNS frames from the client MAC to the firewall MAC
• but I do not see matching VLAN-tagged reply frames from the firewall MAC back to the client MAC
• On the LACP member interfaces, this client's VLAN traffic consistently hashes to a single member (
  
  
  Code Select Expand
  igc4), and on that physical member I still only see the client's DNS requests, not the return replies

Rule/state details

Code Select Expand

pfctl -vvsr shows the DNS traffic is matching the intended explicit client VLAN DNS allow rules, specifically the VLAN interface rules for UDP/53 to each DNS server.

Code Select Expand

pfctl -vvss shows states being created for both directions of the flow.
So this does not appear to be:

• the wrong rule matching
• a forced gateway/policy route on the client VLAN rule
• a hardware offload artifact

Additional notes

• clearing the affected client's DNS states did not fix the problem
• Code Select Expand
  pfctl -si shows a nonzero
  
  
  Code Select Expand
  state-mismatch counter, though not a huge value

Question
Has anyone seen OPNsense / FreeBSD behave like this:

• correct VLAN DNS rule matches
• pf state exists
• reply packet is visible arriving from the services VLAN
• but the packet does not appear to be emitted back onto the client VLAN / parent trunk / physical LACP member carrying the flow

I'm trying to determine whether this points to:

• pf/state handling
• VLAN forwarding inside OPNsense
• LACP/VLAN interaction
• or a known packet capture visibility quirk

Worked like a charm. Thanks, franco!

Seems broken no matter which UI theme is chosen...it's broken in the standard "opnsense" theme is well. 

Hi, I have that problem too.

Always good to know I'm not the only one...must be a bug/glitch within the widget itself. The "Firewall States" widget is working fine, as well as the other ones. Rebooting OPNsense doesn't restore the Firewall widget's function.

Seeing this from the firewall widget post 25.1.4 update...otherwise everything else seems fine...



Using Vicuna theme...

After clearing cache, etc., in MS Edge, the drop-down issue with vicuna seems to be fixed.

Might be browser-related...I tend to use MS Edge/Chrome and only MS Edge appears to have this issue (vicuna works fine in Chrome). Can't select anything in the add-widget drop-down on MS Edge, when vicuna is used as the theme. I did recently update Vicuna, but the problem still persists within Edge. Other themes are working fine, as far as the Add-Widget drop-down is concerned.

When selecting "add widget" from the main dashboard with the vicuna theme, the widgets fall behind the "add widget" window so nothing can be selected. Changing the theme is a quick and easy workaround. Not sure if anyone else reported, definitely nitpicky.

So the web GUI within OPNsense only has input for up to 2 DNS servers. I have a tertiary DNS that I'd like to send out to all clients on my LAN but am unsure of how to go about it.

I found an older post that mentioned using hexadecimal numbers in "Additional Options" using "6" as the number and type "String", using a concatenated hex string for the 3 DNS IP's in the Value field, then leaving the DNS servers "blank" in the GUI. I've found that this doesn't work...after an ipconfig /renew on one of my Windows clients, the OPNsense router's IP is given out as the DNS server instead of the 3 IP's converted over to hex. Any additional suggestions? Thanks.