Messages

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?

I use IPv4 for my (V)LAN communication and IPv6 for outbound connections only - I could use firewall rules for some selective inbound connections, but deliberately choose to use a reverse proxy for that. This way, I only have internal IPv4 services, which can be presented via IPv6 to the internet.

I'm the opposite — my network is IPv6-only from subnet to subnet, with external IPv4 access provided via NAT64. The only IPv4 subnet is the one used for legacy devices, which can reach the internet but not internal resources.

I've definitely considered using static IPv6 assignments on the interfaces, but I don't have any guarantee that my ISP won't change the delegated prefix in the future. I'd need some way to be notified if the prefix ever changes, since that would be difficult to debug otherwise. I'm also not sure how the ISP would react if I started using invalid upstream addresses after a prefix change.

In that case, OPNsense would continue routing what are now invalid IPv6 addresses toward the ISP, which technically violates the relevant RFCs.

I'm not sure why radvd is being configured to stop advertising the prefix when the WAN goes down. That behavior should really be handled at the routing table level, not by radvd itself. radvd should simply update its advertisements when the prefix changes, rather than stopping completely. OPNsense remains the router, even when it temporarily loses a WAN route.

I've had a working IPv6 setup for some time using radvd in an unmanaged configuration.

My local servers are set up as IPv6-only, and most of my local clients use IPv6 via DHCP option 108. This setup has been working very well since my ISP provides a stable prefix through DHCP-PD. I only have one subnet that still uses IPv4 for legacy IoT devices. All other clients correctly honor option 108 and do not receive an IPv4 address.

However, recently my ISP connection went down for about eight hours, and during that time radvd stopped advertising routes, even for internal access. As a result, I had no way to reach my local services.

This seems like a bug, since internal IPv6 routing should continue to work even when the WAN is temporarily down.

Is there a configuration option that will keep the delegated prefix active for local IPv6 traffic when the WAN interface is down? What exactly causes radvd to stop advertising routes—is it triggered by gateway monitoring or dpinger in some way? It's not easy to test without taking the entire network offline.

I'd prefer not to use ULA addresses, as I've found they don't work well and tend to be ignored by clients. I've considered switching to static prefixes since my delegated prefix is very stable, but how can I detect if the ISP ever changes it?