"Recent posts
#21
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
#22
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."
#23
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...
#24
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.
#25
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
#26
26.1 Series / Re: Upgrade to RC1 successful
Last post by meyergru - January 22, 2026, 06:19:49 PMAs you have found, the enabled flag was not exported correctly nor were the categories.
I now used:
And then re-exported the old settings. This time, the enabled and categories settings seemed correct in the CSV.
BTW: In the migration assistant list of steps, it says: "Deselect anti-lockout in advanced settings" - it should be "Enable anti-lockout in advanced settings".
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:
You cannot view this attachment.
Yet in the NAT rule, it does not identify which any more (before you would see the description "Allow DNS via IPv4" instead of "Manual"):
You cannot view this attachment.
I now used:
Code Select
opnsense-patch ba8194de
opnsense-patch 94081fd82f
opnsense-patch d1519593
configctl webgui restart
And then re-exported the old settings. This time, the enabled and categories settings seemed correct in the CSV.
BTW: In the migration assistant list of steps, it says: "Deselect anti-lockout in advanced settings" - it should be "Enable anti-lockout in advanced settings".
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:
You cannot view this attachment.
Yet in the NAT rule, it does not identify which any more (before you would see the description "Allow DNS via IPv4" instead of "Manual"):
You cannot view this attachment.
#27
25.7, 25.10 Series / Re: IPv6 erratically broken fr...
Last post by rmayr - January 22, 2026, 06:18:03 PMNo changes. In response to packet like these that I see from the Android device with
So a simple TCP start of connection (SYN flag) to port 443 on the default route. I can ping that target IP from another Linux laptop on the same LAN/SSID.
I get the firewall log entry (not for exactly this packet, because once the Android device / OPNsense combination get into this state, I don't really get many log entries for this source IP anymore):
With the (now even simplified) default rules on the OPNsense ruleset, I really, really don't understand why it would be blocked. Can there be any weird packet flags that cause the "state violation"? Or maybe this has to do with traffic shaping (simple QoS rules)? I am quite at a loss to understand this behavior.
As soon as the Android device starts using a new randomized client IPv6 address, traffic gets through again for a short while before the same happens with the new address.
Code Select
tcpdump -n -i igb2_vlan64 ether host fa:17:c7:f8:dd:85 and ip6 (that is the Android device randomized MAC address for this SSID):Code Select
18:00:19.946419 IP6 2a03:fa00:650:30:9a7c:9494:3859:2d9b.45934 > 2606:4700:10::6814:2f59.443: Flags [S], seq 3003767200, win 65535, options [mss 1432,sackOK,TS val 3205487265 ecr 0,nop,wscale 8], length 0So a simple TCP start of connection (SYN flag) to port 443 on the default route. I can ping that target IP from another Linux laptop on the same LAN/SSID.
I get the firewall log entry (not for exactly this packet, because once the Android device / OPNsense combination get into this state, I don't really get many log entries for this source IP anymore):
Code Select
LAN In 2026-01-22T17:46:21 TCP [2a03:fa00:650:30:9a7c:9494:3859:2d9b]:49736 [2a00:1450:4001:805::200a]:443 block Default deny / state violation ruleWith the (now even simplified) default rules on the OPNsense ruleset, I really, really don't understand why it would be blocked. Can there be any weird packet flags that cause the "state violation"? Or maybe this has to do with traffic shaping (simple QoS rules)? I am quite at a loss to understand this behavior.
As soon as the Android device starts using a new randomized client IPv6 address, traffic gets through again for a short while before the same happens with the new address.
#28
26.1 Series / Re: Upgrade to RC1 successful
Last post by franco - January 22, 2026, 05:19:17 PM> I tried to understand how the NAT rule linkage relates to new/old rules, but failed.
The old page added a separate "association rule" which is a bit of a broken firewall rule.
The new system will create a shadow rule in in "Register rule" mode somewhat resembling the old approach but without injecting a real firewall rule. Manual and pass are still the same.
Cheers,
Franco
The old page added a separate "association rule" which is a bit of a broken firewall rule.
The new system will create a shadow rule in in "Register rule" mode somewhat resembling the old approach but without injecting a real firewall rule. Manual and pass are still the same.
Cheers,
Franco
#29
25.7, 25.10 Series / Re: After updating Opnsense fr...
Last post by wide - January 22, 2026, 05:12:49 PMMost likely this was not related to 25.7.11_1 update but changes in IDS configuration I had done right after the update. Finally today I restored the Opnsense VM from the backup taken before 25.7.11_1 update and updated the VM then to latest 25.7.11_2 and now all good so far.
#30
High availability / Re: CARP OS-FRR timeout after ...
Last post by Monviech (Cedrik) - January 22, 2026, 05:05:46 PMHello, I think we found something.
https://github.com/opnsense/plugins/pull/5160
Can you try the following patch on the affected firewalls, it will only apply to the latest FRR version though (which means you have to be on 25.7.10 when you test).
# opnsense-patch https://github.com/opnsense/plugins/commit/d27619990739424db4e0aaa266c2392eeb7abe57
https://github.com/opnsense/plugins/pull/5160
Can you try the following patch on the affected firewalls, it will only apply to the latest FRR version though (which means you have to be on 25.7.10 when you test).
# opnsense-patch https://github.com/opnsense/plugins/commit/d27619990739424db4e0aaa266c2392eeb7abe57
