"Recent posts
#81
26.1 Series / Re: Upgrade to RC1 successful
Last post by meyergru - January 22, 2026, 08:29:05 PMThat would be my question as well, as I already hinted at... with the new logic, priorities would potentially change just depending on whether you add or remove interfaces...
#82
25.7, 25.10 Series / Re: GeoIP list no more correct...
Last post by meyergru - January 22, 2026, 08:27:14 PMSince this looks like a temporary issue only: Potentially, this could have been caused by a partial file upload / sync to some mirrors.
At least I think it may be that as the download server seems to be a Google Anycast IP. Depending on how the update is done, one even might get a partial file when an update is just ongoing. This may also explain why only some people experienced this.
At least I think it may be that as the download server seems to be a Google Anycast IP. Depending on how the update is done, one even might get a partial file when an update is just ongoing. This may also explain why only some people experienced this.
#83
26.1 Series / Re: Upgrade to RC1 successful
Last post by Patrick M. Hausen - January 22, 2026, 08:15:26 PMIf floating is now defined by "active on more than one interface" does that change the rule processing order?
I use block rules, floating, with only a single interface - WAN. I do this because I want them applied before NAT rules on WAN. This way I can use "pass" for inbound NAT but "floating before interface" still beats NAT in processing order.
I am worried if ticking more than one IF moves a rule to floating, that a floating rule with just a single IF ticked will be moved down to interface specific.
I hope I could explain the problem - if there is one at all.
I use block rules, floating, with only a single interface - WAN. I do this because I want them applied before NAT rules on WAN. This way I can use "pass" for inbound NAT but "floating before interface" still beats NAT in processing order.
I am worried if ticking more than one IF moves a rule to floating, that a floating rule with just a single IF ticked will be moved down to interface specific.
I hope I could explain the problem - if there is one at all.
#84
25.7, 25.10 Series / Re: IPv6 link-local route does...
Last post by matt335672 - January 22, 2026, 08:05:59 PMI've got a blackhole route manually added anyway - it's been there a few years.
WAN on the main router is DHCPv6 (PPPoE)
A bit more info - I just spent a couple of hours trying to reproduce this on a VM with two interfaces, and failed. I then started looking at the clean config on the VM, and my fairly crufty config on the primary router, saving configs as I went along.
I had a stale reservation in Kea for a GUA on the secondary router. Although the secondary router is not now using DHCPv6 for configuration, when I removed the reservation the routing problem went away.
Difference in the configs is:
However, I'm unable now to get the old config to fail. If I reload it, everything seems to be working OK. Either I've made a mistake in my notes, or there's something else going on.
I've tried adding a reservation to my test VM, but that doesn't fail either.
This probably isn't a very useful data point, I'm afraid, as I'm unable to get back to a non-working configuration now.
WAN on the main router is DHCPv6 (PPPoE)
A bit more info - I just spent a couple of hours trying to reproduce this on a VM with two interfaces, and failed. I then started looking at the clean config on the VM, and my fairly crufty config on the primary router, saving configs as I went along.
I had a stale reservation in Kea for a GUA on the secondary router. Although the secondary router is not now using DHCPv6 for configuration, when I removed the reservation the routing problem went away.
Difference in the configs is:
Code Select
@@ -1561,9 +1561,9 @@
<column_count>2</column_count>
</widgets>
<revision>
- <username>opnadmin@{prefix48}:49:323e:ff94:6713:d8b5</username>
- <description>/api/routes/routes/toggleroute/232ecc2c-722f-4390-84ec-285d8bb15f5d made changes</description>
- <time>1768837329.21</time>
+ <username>opnadmin@{prefix48}:49:27b7:e3d6:48bb:a479</username>
+ <description>/api/kea/dhcpv6/set made changes</description>
+ <time>1769099743.71</time>
</revision>
<OPNsense>
<Firewall>
@@ -2774,7 +2774,7 @@
</reservations>
<ha_peers/>
</dhcp4>
- <dhcp6 version="1.0.0" persisted_at="1768836386.51" description="Kea DHCPv6 configuration">
+ <dhcp6 version="1.0.0" persisted_at="1769099743.71" description="Kea DHCPv6 configuration">
<general>
<enabled>1</enabled>
<manual_config>0</manual_config>
@@ -2876,14 +2876,6 @@
</subnet6>
</subnets>
<reservations>
- <reservation uuid="2d620bbf-fe2f-4e43-b186-1a5e3f6f0048">
- <subnet>7c128662-0440-464c-a14d-844667d1cfa4</subnet>
- <ip_address>{prefix48}:4f::1fff</ip_address>
- <duid>00:01:00:01:26:dd:37:1c:52:54:00:68:30:cf</duid>
- <hostname>router2</hostname>
- <domain_search/>
- <description/>
- </reservation>
<reservation uuid="39055ba4-31b6-4409-a38b-df0a91fceecb">
<subnet>d0d43b13-dc16-4c61-9eaf-31417bcbfbe7</subnet>
<ip_address>{prefix48}:49::a</ip_address>
However, I'm unable now to get the old config to fail. If I reload it, everything seems to be working OK. Either I've made a mistake in my notes, or there's something else going on.
I've tried adding a reservation to my test VM, but that doesn't fail either.
This probably isn't a very useful data point, I'm afraid, as I'm unable to get back to a non-working configuration now.
#85
26.1 Series / Re: Upgrade to RC1 successful
Last post by franco - January 22, 2026, 08:04:53 PM> The thing with the manual rule is that with 25.7.11, you saw the associated firewall rule name there, so you would know which one it was. This gets lost immediately upon update, you do not have to use the migration assistant. That means I see that there is an associated rule:
Yes true but it's now disassociated (manual) and the display of the firewall rules is exactly the same as before and still has the same description. Functionally after the upgrade it's the same. It only starts behaving differently when modifications are being made to destination NAT rules.
We don't have a lot of leeway leaving this concept behind other than making this cut. I can make sure to add this to the migration notes.
Cheers,
Franco
Yes true but it's now disassociated (manual) and the display of the firewall rules is exactly the same as before and still has the same description. Functionally after the upgrade it's the same. It only starts behaving differently when modifications are being made to destination NAT rules.
We don't have a lot of leeway leaving this concept behind other than making this cut. I can make sure to add this to the migration notes.
Cheers,
Franco
#86
25.7, 25.10 Series / Re: GeoIP list no more correct...
Last post by IPinfo - January 22, 2026, 07:58:26 PMHi,
Not sure what we can do here. The data is consistent on our end. I checked the IP address count (broke down CIDRs) from the historical database. The volatility the community reported would be quite significant, and internally would be flagged.
Query (AI Generated)
```
SELECT
SUM(
CASE
-- Individual IPv4 (no slash)
WHEN NOT REGEXP_CONTAINS(network, r'/') THEN 1
-- IPv4 CIDR
WHEN SAFE_CAST(REGEXP_EXTRACT(network, r'/(\d+)$') AS INT64) BETWEEN 0 AND 32
THEN POW(2, 32 - SAFE_CAST(REGEXP_EXTRACT(network, r'/(\d+)$') AS INT64))
-- Anything malformed
ELSE 0
END
) AS bg_ips
FROM `ipinfo-158115`.bundle.lite_history
WHERE _PARTITIONTIME = TIMESTAMP '2026-01-22'
AND country_code = 'BE'
AND network LIKE '%.%';
```
Result:
```
18.1.2026 → 13,624,764.0
19.1.2026 → 13,624,744.0
20.1.2026 → 13,625,250.0
21.1.2026 → 13,628,029.0
22.1.2026 → 13,667,047.0
```
> We solved the issue by creating a new white liste in our appliance.
The entire operation should be automated. Unfortunately, this is a manual solution.
Let me know if there are any issues in the future. We provide data for Opnsense. Regardless of what plan you are on, data quality is our responsibility. Please flag this to our support team and share the IP addresses next time. But do check the IPs on our website first.
— Abdullah | DevRel, IPinfo
Not sure what we can do here. The data is consistent on our end. I checked the IP address count (broke down CIDRs) from the historical database. The volatility the community reported would be quite significant, and internally would be flagged.
Query (AI Generated)
```
SELECT
SUM(
CASE
-- Individual IPv4 (no slash)
WHEN NOT REGEXP_CONTAINS(network, r'/') THEN 1
-- IPv4 CIDR
WHEN SAFE_CAST(REGEXP_EXTRACT(network, r'/(\d+)$') AS INT64) BETWEEN 0 AND 32
THEN POW(2, 32 - SAFE_CAST(REGEXP_EXTRACT(network, r'/(\d+)$') AS INT64))
-- Anything malformed
ELSE 0
END
) AS bg_ips
FROM `ipinfo-158115`.bundle.lite_history
WHERE _PARTITIONTIME = TIMESTAMP '2026-01-22'
AND country_code = 'BE'
AND network LIKE '%.%';
```
Result:
```
18.1.2026 → 13,624,764.0
19.1.2026 → 13,624,744.0
20.1.2026 → 13,625,250.0
21.1.2026 → 13,628,029.0
22.1.2026 → 13,667,047.0
```
> We solved the issue by creating a new white liste in our appliance.
The entire operation should be automated. Unfortunately, this is a manual solution.
Let me know if there are any issues in the future. We provide data for Opnsense. Regardless of what plan you are on, data quality is our responsibility. Please flag this to our support team and share the IP addresses next time. But do check the IPs on our website first.
— Abdullah | DevRel, IPinfo
#87
25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...
Last post by LHoust - January 22, 2026, 07:24:59 PMQuote from: LHoust on January 22, 2026, 07:02:06 PMI tried hostwatch-1.0.6.pkg, although I am still experiencing HDD Thrashing...
Restored hostwatch 1.0.5 from 25.7.11_2 and therefore I will run with Automatic Discovery disabled for now...
"I ran iostat -w 1 da0 and the data is conclusive. While throughput is low (~0.15 MB/s), the tps (Transactions Per Second) is constantly spiking between 20 and 30 with Hostwatch 1.0.6.
For a mechanical HDD, this high frequency of tiny 6KB writes forces constant head seeking. This confirms the issue isn't the amount of data being logged, but the frequency of the SQLite commits. I'll be keeping discovery OFF until a version with Batch/Lazy Writing is released."
#88
25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...
Last post by LHoust - January 22, 2026, 07:02:06 PMI tried hostwatch-1.0.6.pkg, although I am still experiencing HDD Thrashing...
Restored hostwatch 1.0.5 from 25.7.11_2 and therefore I will run with Automatic Discovery disabled for now...
Restored hostwatch 1.0.5 from 25.7.11_2 and therefore I will run with Automatic Discovery disabled for now...
#89
Tutorials and FAQs / Re: [HOWTO] OPNSense monit ema...
Last post by RamSense - January 22, 2026, 06:58:38 PMThank you for sharing!
I've added your Achme alert also.
I've added your Achme alert also.
#90
25.7, 25.10 Series / Re: IPv6 link-local route does...
Last post by Maurice - January 22, 2026, 06:20:18 PM@franco That would be weird, since the automatic blackhole route and the static routes have different prefix lengths. Adding a /48 blackhole route should not remove existing routes for /60 subnets. But this should be easy to test by creating static routes for prefixes which aren't subnets of the delegated prefix.
@matt335672, what's your WAN configuration, static or DHCPv6?
And I reconsidered what I said about having observed this before. What I have indeed observed is some static routes sometimes not getting added to the routing table after a reboot. But I think these were static IPv4 routes on ptp interfaces, so probably a different issue.
Cheers
Maurice
@matt335672, what's your WAN configuration, static or DHCPv6?
And I reconsidered what I said about having observed this before. What I have indeed observed is some static routes sometimes not getting added to the routing table after a reboot. But I think these were static IPv4 routes on ptp interfaces, so probably a different issue.
Cheers
Maurice
