Messages

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?

Mine is working, and im using the same type of Link as Patrick.  There isnt much to see in the logs, but if its working (as mine is) you will see, once per day:

Code Select Expand

2025-10-13T07:39:12-07:00    Notice    firewall     geoip updated (files: 496 lines: 4550698)
vs, from the maxmind:

Code Select Expand

2025-10-08T07:34:02-07:00    Notice    firewall     geoip updated (files: 502 lines: 1294241)

I think I am going to use static interface assignments and figure out a way to monitor if the prefix changes.

You can e. g. create a ping test, setting the source address to a LAN interface address. The ping will fail when your ISP changes your prefix delegation.

I guess that would work if I kept one of the interfaces to track and then pinged a host in that interface. My Guest Wifi would be good for that.

Another way would be to look at the file where the ipv6 prefix is kept. For me that is /tmp/vtnet0_prefixv6 but I'm not sure monit is smart enough to do that.

@meyergru Agreed. From my experience, if #1 (IPv6-only with static GUAs) isn't viable, #2 (IPv6-only with dynamic GUAs + static ULAs) is the preferred option for advanced users. Having to deal with only one IP stack at a time makes so many things so much easier. I only fully realized this once I tried it.
On the other hand, #4 (Dual Stack with dynamic GUAs + static RFC1918) is still unrivaled for your average zero-configuration home network.

@Patrick M. Hausen Probably not an option for IsaacFL. ;-) For myself, this would be more than twice of what I pay with my current ISP - for the same bandwidth over the same fibre.

@IsaacFL I don't think that's a good idea. You'll still have to manually change the VIPs and DNS records when your PD changes. What's your concern with the other options we discussed?

I think you are right about it not being a great idea. I did test it and seems to work, but it is bringing more complexity, really almost like using ULA.

I think I am going to use static interface assignments and figure out a way to monitor if the prefix changes.

Last time I had the prefix change, I just did a search and replace on the old prefix to new prefix in the config.xml file and just restored the edited file.