GeoIP list no more correct for Belgium.

[jfou1987]

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.

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.

[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

[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

[jfou1987]

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.

[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

[meyergru]

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.

[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