Messages

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

Hi,

I work for IPinfo. We have rate limits, but I am not 100% sure if this is affecting your ability to download our database. I am really not sure what we can do here. If you can download the database directly, you should be able to download it via OPNsense as well. Also, you mentioned you switched IP addresses, which should also reset your rate limit.

— Abdullah | DevRel, IPinfo

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

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

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

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

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

I work for IPinfo. It looks like the issue is resolved. Ping me if there is anything else you want us to look into. Thanks!

— Abdullah | DevRel, IPinfo

Thank you very much. Keep me informed of any additional issues.

— Abdullah | DevRel, IPinfo

I just did a fresh installation and now see the same errors:

Code Select Expand

geoip update failed : File is not a zip file
geoip update failed : You have reached your 10 downloads per day limit for ipinfo_lite.csv.gz from x.x.x.x. Please reach out to increase your limit via support@ipinfo.io. [http_code: 429]

Hi,

I hope you are doing well. I am Abdullah, the DevRel of IPinfo.

Can you please reach out to our support team? They will investigate and report back. The issue should have been resolved as we engineered the migration several days ago and have not seen any issues.

— Abdullah | DevRel, IPinfo

Thank you very much, everyone, for your kindness and patience. To confirm again:

- The engineering team performed the rollback, and we are now aware of the issue.
- @Kayakero's review helped us to pinpoint the issue.
- This was not related to rate limits. Due to multiple retries to the API endpoint we returned 429 rate limit error.
- We will proceed with the migration to the new cloud storage system; however, at this moment, we do not think Opnsense needs to patch anything. We will make the adjustments on our end.

If there is any issue, please reach out to us on our community: https://community.ipinfo.io/

Opnsense is a major supporter of our IPinfo Lite service, so we owe it to the Opnsense community to handle data issues related to us in our community.

— Abdullah | DevRel, IPinfo

Hi,

We were slowly migrating to a different cloud storage service over a period of time. We have rolled back the system migration entirely.

We have been doing incremental migration throughout the process, and thanks to the post and the only message we received on the support portal, we discovered reliance on the URI header metadata. This was not a hard transition, which has been rolled back, and further investigation will be conducted in the next few days.

During this transition, thanks to this post, we found out that the Content-Disposition header was no longer included in the final download response. This header was optional, but OpnSense relies on it to detect the filename or file type. We have been doing the slow rollout for several weeks, and this was the first issue we received.

The file itself has not changed; it's still a .csv.gz gzip file, but because the header is missing, some scripts may incorrectly treat it as a ZIP instead of a GZIP file. We have rolled back our entire deployment to our previous storage service.

We will investigate closely in the coming days. Thank you for understanding.

— Abdullah | DevRel, IPinfo

the only thing I can assume is that ipinfo removed the "Content-Disposition" header ( it's hosted in cloudflare it doesn't make sense ).

Let us investigate this issue. I have escalated this to engineering.

— Abdullah | DevRel, IPinfo

Hi,

I am Abdullah, the DevRel of IPinfo. I will try my best to help you here.

Our file format will never change to anything else without a significant amount of communication. Please understand that a file format change without alerting our user base is a catastrophic change that we will never make. So, I suspect this is some error message being interpreted as zip file or something.

I am not clear about the implementation of how the database is downloaded, but we do have a checksums API endpoint that you should use to verify the download.

Reference: https://ipinfo.io/developers/database-download

The download process requires you to go through a redirect path because the data is stored in a cloud storage bucket.

Reference: https://ipinfo.io/developers/ipinfo-lite-database (See the code section)

The API provides unlimited usage, but the data downloads are subject to rate limits. It permits 10 downloads per unique IP address multiplied by unique access token. This means that to reach the rate limit, you probably downloaded it 10 times using the token you are using from the same IP address.

Reference: https://community.ipinfo.io/t/announcement-we-are-adding-rate-limits-to-data-downloads/358

You have shared your API access token: `f2cbc8898bc30a` which according to our database is a not an active or assigned token.

---

Please let me know if this problem persists. We will be happy to take a look. Our community forum is available here: https://community.ipinfo.io/

— Abdullah | DevRel, IPinfo

Opnsense primarily uses IPinfo's data, and I work for IPinfo. I am obligated to help the community in any way possible.

The other users have already provided great guidance. Please check your IP address at ipinfo.io/me. If there is an issue, reach out to our support team. They will instruct you on how to fix your location. However, if the sites you access do not use our data, providing accurately located data to you will not help much.

— Abdullah | DevRel, IPinfo