Messages

I'm seeing the same with Cicada...also give vicuna a try, looks very similar to cicada and the services widget doesn't appear as grayed out...

I'm using the Dynamic DNS service in OPNsense 26.7 with No-IP. My WAN address can remain unchanged for months, so the service may go a long time without contacting No-IP after a successful update.

No-IP expects periodic updates even when the address hasn't changed. Otherwise, it may warn that a hostname is becoming inactive. Their software client updates much more frequently than necessary, but OPNsense currently doesn't appear to offer a configurable forced-refresh interval.

Could Dynamic DNS gain a per-account option such as:

Force update after: [5] days

Suggested behavior:

• Track the last successful provider update.
• If the address hasn't changed, force an update once the configured interval has elapsed.
• Reset the timer only after a successful response.
• Retry during the next normal check if the forced update fails.
• Allow the feature to be disabled by default.
• Ideally configure it per Dynamic DNS account, since provider requirements differ.
• This would preserve the current change-triggered behavior while ensuring providers such as No-IP receive an occasional confirmation. A configurable interval would also avoid unnecessarily contacting the provider daily.

As a workaround, I currently run a daily guard that checks the last successful update timestamp and invokes OPNsense's existing Force ddclient update action once it is five days old. This works correctly, including when No-IP returns nochg, so it seems like functionality that could fit naturally into the existing Dynamic DNS component.

Thanks for any consideration!

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.