Messages

I opened a bug in GitHub

 Firewall: Rules [new] - Unable to Filter Out Floating rules #10313

[applied to that particular interface]

Yes, the interface views show all floating rules applied to that particular interface, now. A good move, IMHO.

Well I think it's very confusing and inconsistent.

Groups that the interface is a member of are not shown. Confusingly it appears that the float rules occur before the interface rules, when in reality, the Group rules apply after float but before the interfaces.

It was better to use the inspect button, to show all the rules applied to interface in the order they apply, including automatic, float, group and finally the interface.

My filtered Rules (ie WAN, LAN, etc) now always shows the Floating rules also. Is this on purpose or a bug? The group rules only show with inspect button so not consistent?

I prefer to be able to focus on the interface rules I am working on and then check via inspect for Float, and Group rules.

I have the latest OPNsense 26.1.8_5-amd64

Created issue #9966
https://github.com/opnsense/core/issues/9966

I noticed this prior to today's update also.

When I view the firewall rules on my Wireguard Interface, and I select Inspect, I do not see any rules that are in the Wireguard Group. I can see the Automatic rules and the Floating rules.

I can see that the Wireguard group rules are being processed and in the correct order, via Firewall: Diagnostics: Statistics: Rules. It is just not showing in "Inspect"

I don't remember if the old rules did or not. I only have one Wireguard instance so I just moved the group rules to the Interface.

Just an observation.

I've noticed that Interfaces: Neighbors: Discovery is working well in the latest 26.1.2 release.

I briefly tested the feature when it first debuted in January, and I've noticed that those original entries are still present in my Discovered Hosts. Because I am almost entirely IPv6 locally—and thanks to IPv6 Privacy Extensions—my list has ballooned to nearly 700 entries on a relatively small network.

Does the hostwatch database have a mechanism to automatically age out/purge stale entries? Or is manual maintenance required to keep the list from growing indefinitely?

If you try a random IPv6, the Query Forwarding will not kick in. I actually tried a specific IPv6 within a delegated prefix. Then I pinged from that prefix and looked at the live firewall logs. Before I had the query forward, there was a reverse name, after, there was none - but still immediate.

You must get the ip6.arpa domain right, filling up the zeros and not set "forward first".

I tried it again and I'm pretty sure I have the query forwarding setup correctly. I have used it before when I was testing dnsmasq, so I know how to use it.

When I said random address, I mean an address from my prefix. ie I will copy a deprecated address from my Mac, and then do a "dig -x" of that address from a linux client or from opnsense command line. I get a noticeable delay, seconds before I get a response.

Also, in Reporting: Unbound DNS Details tab when I first bring it up, takes a very long time, with the littler spinner until it times out on all of my source addresses (all ipv6).

Putting the local zone static entry in the custom.conf makes all of those actions instant.

It is probably noticeable more for me, since all of my clients are using ipv6.

Have you tried creating a "Query Forwarding" entry with the same reverse domain and 127.0.0.1 / 53 as the Server IP / Port? Works like a charm for me. I think this may even deliver the correct names if you used DHCPv6, but IDK.

I did try this but it did not seem to work for me.  With the Query Forwarding I would dig -x random ipv6 in my prefix, and get:

Code Select Expand

;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: timed out
with query times around 1600ms

I am only using unbound for dns (not dnsmasq) and KEA dhcpv4.

I'm not sure whether this qualifies as a tip or a question, since I couldn't find a way to do this through the web interface.

While debugging an issue with the new firewall logs, I noticed that reverse lookups of my local IPv6 addresses were taking between 800 and 1500 ms each. The reason is that, because my clients use privacy extensions, each lookup (almost never cached) causes Unbound to query my ISP — which owns the address space and hosts the corresponding PTR records.

To address this, I created a file named 1-custom.conf in /usr/local/etc/unbound.opnsense.d with the following content:

Code Select Expand

server:
    # Authoritative reverse zone for my /56
    local-zone: "d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa." static
This tells Unbound that this prefix is part of my local network, preventing it from trying to resolve those reverse lookups externally.

I couldn't find a way to configure this via the web interface, but it seems like a useful feature to have. My ISP assigns a /56, and it has been stable; however, if your ISP frequently changes your prefix, you could apply the same approach to their /48 or even /32 aggregate. In most cases, you won't get meaningful reverse lookups from your ISP for those addresses anyway.

I've been testing this out and had a question about the malware IP list.

Why doesn't it use CIDR notation? The list contains over 500,000 individual IP addresses, and I can see entire /24 ranges represented as separate entries — even including the broadcast addresses. That seems inefficient for the firewall, especially since the premise of Q-Feeds is supposed to involve preprocessing and aggregation.

This approach also makes it practically impossible to scale into IPv6, where the smallest subnet is a /64. It feels like a dead-end implementation.

Opened git issue #9310

I will raise a git issue later today. Just wanted to see if anybody else has seen this in which case it might be my own configuration issue.

it seems to work given time. it takes about 2 minutes on mine to fill them in. I would assume the hostnames are cached but still takes over 2 minutes if I click Live View then lookup hosts. Even if I had just looked at them.

The "Lookup hostnames" option in Live View no longer seems to show previously resolved hostnames. As new log entries come in they show hostnames but prior entries do not.

Before, I could click the Refresh button in Live View and hostnames would appear for existing log entries. Now, it looks like hostname lookups only apply to new entries as they come in — older entries stay blank.

Am I missing something, or has this behavior changed?