Messages

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.

This is what I'm going to try:

I plan to use part of my delegated prefix like a ULA range.
My ISP allocates a /56, so I have plenty of subnets to spare.

I'll keep using Track Interface for each interface, but on each one I'll add a Virtual IP (VIP) from the next subnet.

For example, on one interface I configure it with prefix ID 60, which gives me 2603:aaaa:bbbb:cc60::babe/64.
Then I create a VIP on the same interface with the address 2603:aaaa:bbbb:cc61::babe/64.

After restarting services, I can see in radvd.conf that it's now advertising both prefixes. On one of my test Linux devices, I can confirm it's getting addresses from both prefixes.

Next, I'll update DNS to use the 2603:aaaa:bbbb:cc61::/64 addresses for my hosts.

I'm not entirely sure how I'll test everything yet, but I'll see how it behaves.

Will this approach work?

The ipv6 mostly dhcp option 108 does work well for my network, since all of my clients do support it, and I have been using ipv6 for a very long time and understand it. My knowledge of NAT of any kind is not good since we always had real public ipv4 addresses where I worked.

ULA does not work well, in that really you are running an additional network stack, so dual stack to triple stack?

Opnsense implementation of ipv6 could definitely be improved. There is no reason to remove the GUA addresses on the interfaces when the WAN goes down. You dont know if you "own" the prefixes or not at that point. It seems the fix is to use static assignments but I dont "own" them either.

Mostly I was just wondering if I could change something in the gateway monitoring so it doesnt wipe out the configuration when the wan goes down.

But if the internal interfaces are configured as "track WAN", then there is no prefix once the WAN connection drops. So what should radvd advertise? I have not looked at the code yet, but I assume that it is not radvd stopping to advertise, but OPNsense actively removing the configured GUAs from the interfaces.

Can you confirm? I don't use "track".

I believe that opnsense actively removes the GUAs from the interfaces.

But if the internal interfaces are configured as "track WAN", then there is no prefix once the WAN connection drops. So what should radvd advertise? I have not looked at the code yet, but I assume that it is not radvd stopping to advertise, but OPNsense actively removing the configured GUAs from the interfaces.

Can you confirm? I don't use "track".

I use Track Interface to assign prefixes to my interfaces.

I understand the implications of using Track Interface with the way OPNsense implements it, but there's also a downside to using static assignments if the ISP ever changes the prefix — even if such changes are rare.

The expected behavior should be that if the ISP changes the delegated prefix, radvd automatically updates the prefix it advertises.

If the WAN interface goes down, radvd should continue advertising the existing prefix for internal traffic, while the routing table should handle the loss of external connectivity by returning "destination unreachable" for external sites.

If gateway monitoring is turned off, would that keep radvd from being reconfigured?