Hello, i'm on 25.10.1_2 business Version.
Today, a road warrior user told me he can't connect anymore to VPN server.
I tried on cellular with the same issue.
I found the problem. It's GeoIP. I only give access to Belgian IP (BE). When disabled, it works again.
The geoip database was updated about 15 minutes ago. In the alias IP list (diagnostic/alias) i cannot found any of my belgian (verified) IP adsresses.
I temporary add a whitelist for my user to let him work. But he's behind a dynamic IP internet connexion. I will add his new IP when change.
Does anyone know if the provider of the business GeoIP list has an issue today ?
Same here, we use geo ip on a lot of firewall rules and notice that ip's from the netherlands are blocked since this afternoon, while the netherlands has been configured to have access through geo ip. Changing this to any (so removing geo filtering) fixed it. So there is definitely something wrong with the geo ip database. we use the latest opnsense business.
What do you get if you query the MaxMind DB for these IPs, using their website: https://www.maxmind.com/en/geoip-web-services-demo .
If you not get the expected country back, the issue would have to be reported to MaxMind.
Maxmind or IPinfo? Anyway, this is not an opnsense issue :( It must be reported to the provider.
AFAIK, the business edition uses IPinfo per default, if not configured otherwise.
I've asked IPinfo to take a look. Also make sure the maximum table entries value is not too small.
Cheers,
Franco
Hi,
I work for IPinfo.
Please contact our support team at https://ipinfo.io/support. They will need the user's IP address to investigate the issue.
In your message, include the list of IP addresses, please.
— Abdullah | DevRel, IPinfo
We have the same problem with Belgian IPs. We're using the ipinfo database. The ip addresses show fine in the IPInfo database at ipinfo.io (and on Maxmind for that matter). They are also fine in the ipinfo_lite.csv database downloaded (9784 IPv4 ranges):
$ grep -E '^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}.*Belgium' ipinfo_lite.csv|wc -l
9784
However, the list is truncated to the first 64 lines in the Alias-file in /usr/local/share/GeoIP/alias
# wc /usr/local/share/GeoIP/alias/BE-IPv4
64 64 916 /usr/local/share/GeoIP/alias/BE-IPv4
Quote from: sopex8260 on January 20, 2026, 09:57:01 PMMaxmind or IPinfo? Anyway, this is not an opnsense issue :( It must be reported to the provider.
I already get in touch with Robert at Decisio about that specific issue.
I downloaded the Belgian white liste, it contains almost only IP V6.
Only some V4, but as the list is in alphanumerical order, i can see, nothing more after 5.x.x.x is listed ...
Take a look : https://uploadnow.io/f/Qzn9R5G (https://uploadnow.io/f/Qzn9R5G)
Quote from: franco on January 20, 2026, 10:06:41 PMI've asked IPinfo to take a look. Also make sure the maximum table entries value is not too small.
Cheers,
Franco
Of course, i'm only at 3%
Quote from: meyergru on January 20, 2026, 10:00:17 PMAFAIK, the business edition uses IPinfo per default, if not configured otherwise.
i noticed the numbers(addresses) decreased in total by about 10k. is this the reason why those numbers changed so much?
within the last month. maybe 2?
I neither use the business edition nor have I monitored the size of the Ipinfo database over time. I use it with the community edition and for me, it works:
# wc /usr/local/share/GeoIP/alias/BE-IPv?
9736 9736 158563 /usr/local/share/GeoIP/alias/BE-IPv4
24323 24323 566429 /usr/local/share/GeoIP/alias/BE-IPv6
34059 34059 724992 total
# fgrep ,BE, ipinfo_lite.csv | wc
34059 64340 2112133
Seems like there is some kind of extraction process from the Ipinfo CSV that failed to generate all entries, maybe because of a subtle syntax error in the CSV. For example, I find this line inside the CSV:
2a14:3d02::/35,Belgium,BE,Europe,EU,AS57234,"LLC ""IT NETWORKS CHAT""",ichatua.com.ua
Note the multiple quotes. Also, there are missing ASNs in some lines. So maybe this is a parsing error within OpnSense code, but probably in the business edition only?
Do these steps, first execute:
/usr/local/opnsense/scripts/filter/download_geoip.py
Then go to "Firewall - Aliases" and create a new alias that contains Belgium.
After saving and apply, go to "Firewall - Diagnostics - Aliases" and check the contents of the alias you just created.
As expected (but with the community edition):
2026-01-21 12_49_39-Aliases _ Diagnostics _ Firewall _ OPNsense.mgsoft — Mozilla Firefox.png
Thanks! The current ipinfo file processes fine and fixes the aliases. I suspect there either was a severely truncated file online yesterday afternoon for a short while, or it contained something that crashed the script that extracts them.
I also noticed that the IPv6 files were not updated yesterday, which would be consistent with some kind of truncated file that only contained IPv4 until 5.something.
File sizes before re-download:
-rw-r----- 1 root wheel 288 Jan 20 13:41 BA-IPv4
-rw-r----- 1 root wheel 27668 Jan 19 13:40 BA-IPv6
-rw-r----- 1 root wheel 14 Jan 20 13:41 BB-IPv4
-rw-r----- 1 root wheel 13532 Jan 19 13:40 BB-IPv6
-rw-r----- 1 root wheel 14 Jan 20 13:41 BD-IPv4
-rw-r----- 1 root wheel 116040 Jan 19 13:40 BD-IPv6
-rw-r----- 1 root wheel 916 Jan 20 13:41 BE-IPv4
-rw-r----- 1 root wheel 565784 Jan 19 13:40 BE-IPv6
-rw-r----- 1 root wheel 14 Jan 20 13:41 BF-IPv4
-rw-r----- 1 root wheel 23354 Jan 19 13:40 BF-IPv6
-rw-r----- 1 root wheel 1233 Jan 20 13:41 BG-IPv4
-rw-r----- 1 root wheel 122141 Jan 19 13:40 BG-IPv6
File sizes after re-download:
-rw-r----- 1 root wheel 8492 Jan 21 12:49 BA-IPv4
-rw-r----- 1 root wheel 27668 Jan 21 12:49 BA-IPv6
-rw-r----- 1 root wheel 4531 Jan 21 12:49 BB-IPv4
-rw-r----- 1 root wheel 13532 Jan 21 12:49 BB-IPv6
-rw-r----- 1 root wheel 65683 Jan 21 12:49 BD-IPv4
-rw-r----- 1 root wheel 114769 Jan 21 12:49 BD-IPv6
-rw-r----- 1 root wheel 158563 Jan 21 12:49 BE-IPv4
-rw-r----- 1 root wheel 566429 Jan 21 12:49 BE-IPv6
-rw-r----- 1 root wheel 5637 Jan 21 12:49 BF-IPv4
-rw-r----- 1 root wheel 23354 Jan 21 12:49 BF-IPv6
-rw-r----- 1 root wheel 118374 Jan 21 12:49 BG-IPv4
-rw-r----- 1 root wheel 122103 Jan 21 12:49 BG-IPv6
Quote from: Monviech (Cedrik) on January 21, 2026, 12:45:01 PMThen go to "Firewall - Aliases" and create a new alias that contains Belgium.
After saving and apply, go to "Firewall - Diagnostics - Aliases" and check the contents of the alias you just created.
I just did it, and the problem was solved ! Thank you for your help.
I thing robvdw was right, there was an issue at ipinfo yesterday.
Hi,
I am following up here. I saw one ticket related to this thread in our support portal.
The data on our website is available directly in IPinfo Lite and in all our geolocation databases.
Since the user shared their home IP address, I cannot publicly go through the discovery process here. But we have been geolocating that IP address in Brussels since 2023.
First, check our website:
- ipinfo.io/<ip>
- Then you can also check our IPinfo Lite API service which enitrely built on top of the IPinfo Lite database: api.ipinfo.io/lookup/<ip>?token=<token>
Each row represents a block unaggregatable of the CIDR representation of IP address data.
https://community.ipinfo.io/t/understanding-range-aggregation-in-ipinfos-ip-databases/6528
Please, if you can share some IPs that I can look into to verify, that will be incredible. I am always happy to help.
— Abdullah | DevRel, IPinfo
Our CSV database is RFC 4180 complaint and can be read using standard CSV parsing methods. We also provide NDJSON and Parquet formats. All formats are available to everyone for free.
If the ASN value is missing, it means the IP range is not announced in BGP tables and is not publicly accessible.
https://community.ipinfo.io/t/why-some-ip-addresses-dont-have-asn-data/7195
— Abdullah | DevRel, IPinfo
Hello Abdullah,
As others explained, it was concerning a bunch of IP address. And in my case, testing a lot of Belgian (verified) IP address from different providers.
I don't know if it was OPNsense parsing method or the CSV file corrupted. But there was a serious issue.
File was not complete. As i said, for exemple in Belgium, ip range was limited to the 5.x.x.x
We solved the issue by creating a new white liste in our appliance.
Hi,
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
Since 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.
Hi meyergru,
Thank you for your thoughts and feedback. What you have raised could be an alarming concern for us. But I can assure you this is not the case.
> Potentially, this could have been caused by a partial file upload / sync to some mirrors.
> one even might get a partial file when an update is just ongoing.
I don't think it's possible. The data is downloaded as a compressed, gzipped file. If the data were corrupted in some way, the data couldn't have been parsed. We don't deliver any data in plaintext, so partially downloading and parsing it into an ingestible dataset isn't possible.
Also, I don't believe our data delivery strategy leverages caching or mirroring in a way that could lead to data inconsistencies. Everyone downloads what's in storage the moment we upload it. There could be some Cloudflare nuances, but still, even if you download yesterday's data, I can see that the Belgium IP address data is consistent for 18-22 January.
Another issue is that we do support checksums and have a dedicated endpoint for that. But because none of our data is uncompressed and always comes in binary format, data corruption or data integrity issues are going to be quite impossible. But checksums do exist as a secondary validation point.
---
I am trying to think what could be wrong. I really need to present a case to engineering with IP addresses to support the concerns.
The best path forward would be in the future:
1. Identify the IP addresses that are concerning.
2. Check our website. Our website data is based on our datasets. In fact, our datasets are first produced, and then the website data is deployed. Using our datasets ensures you have the latest data.
3. If there are any inconsistencies or concerns, post in our community (https://community.ipinfo.io/) if they are public IPs or to support (https://ipinfo.io/support) if it is your own home IP address.
— Abdullah | DevRel, IPinfo
Hello Abdullah,
during the debuging process, to look after what happens, i checked all the IP i used to test the inbound access thru GeoIP.
There was an Orange 5G, Proximus 5G, Proximus home VDSL, Colt pro VDSL and Proximus explore pro Fiber.
All that IP where in your database (thru the website) and correctly BE flagged.
But as i said, the txt file present in the OPNsense repository (there was also an MD5 file, so i'm aware there is an integrity verification) contains only a few amount of V4 IP, but a bunch of V6.
Here's again the copy of the mentioned file : https://uploadnow.io/f/Qzn9R5G (https://uploadnow.io/f/Qzn9R5G)
I used the python script to force again downloading, and the file was still the same.
I don't know why when i created a new list in the OPNsense aliases, the content tuned ok.
Hi,
My apologies for the delayed response. I quickly checked the file you shared, and I think there could be a data parsing issue of some sort or some kind of error that happened after the CSV was uncompressed.
It is not our data issue or something on our end. In the file, the total number of IPv4 addresses (expanded from the CIDR) is 45,075. It should be about 13.5 million.
I wish I could provide additional insights, but I am extremely confident it is not something on our end. A data level issue of this scale would be incredibly significant. I did not see any support tickets on our system.
If there are any issues in the future, check our website then let me know. We are always happy to help.
— Abdullah | DevRel, IPinfo