Thank you for reporting this.

Indeed, the location database currently returns "US":

[root@maverick ~]# location lookup 206.214.225.0
206.214.225.0:
  Network                 : 206.214.225.0/24
  Country                 : United States of America
  Autonomous System       : AS36492 - GOOGLEWIFI
[root@maverick ~]# location version
Wed, 10 Nov 2021 05:44:06 GMT

This is because ARIN and LACNIC does not make their full database public, hence we have limited coverage on suballocations with different country codes.

I have no problem with tagging this IP range as a "satellite provider", where the physical location can be virtually anywhere in the world. There are two questions left open for me:

1. What about AS36492 in general? All IP space announced by it seems to belong to satellite/wifi providers of some sort. Would it be fine to tag that AS in general?

2. Where did you obtain the quoted (Whois?) output? "whois 206.214.225.0" did not return "SpaceX Canada Corp." for me, and I'd like to know if it's just this /24 or a bigger range before creating an override.

Thanks for answering these questions. :-)

1) For my purposes, marking AS36492 as Satellite instead of US would be more specific / accurate.
Although a more granular result would be ideal.

2) The website below was mentioned in another post so I was using that to check.
https://stat.ripe.net/app/launchpad/
It looks like it is not the full /24 but a couple of /27 ranges where Maxmind and WHOIS correctly show 'CA'
206.214.225.96/27 (.96-127)
206.214.225.160/27 (.160-191)


The location database (Geo blocking IP ranges before further firewall processing) is a very good feature and improves security while greatly reducing noise.  However, it is not granular enough and there will always be incorrect/ambiguous address ranges and specific IPs in blocked countries that we want to pass.

Updating/correcting the database helps but is very labor intensive.  
A flexible solution would a 'local override' but I'm not sure if that is feasible (if the location database code is managed by IPFire or is third party code).
It would be very useful to have a local override for the location database.  That way admins instead of developers could make adjustments for their sites.

ie: an admin managed local file on the firewall that contains a small list of networks that are whitelisted and passed first as 'good locations' without further checking of the database.

For example, with the Satellite Starlink ranges above, if I wanted to location block US/Satellite but still allow the two CA networks that are incorrectly labeled as such then I would add them to the local override file.  The location database logic could first check the file for the IP and if found it would be allowed as ADMIN-OVERRIDE (some unique 2 CHAR Code) and no further checking would be done.
A local override would also allow specific IPs (that are correctly identified) in countries that are otherwise broadly blocked.

Thanks!

Thanks for your detailed answer. I'll reply to the specific comments inline.

> For my purposes, marking AS36492 as Satellite instead of US would be more specific / accurate.

The "sattelite" tag is an additional information; the country will still be preserved in the "location lookup" output, such as in this example:

[root@maverick ~]# location lookup 37.72.192.0
37.72.192.0:
  Network                 : 37.72.192.0/19
  Country                 : France
  Autonomous System       : AS29286 - SKYLOGIC S.P.A.
  Satellite Provider      : yes

> Although a more granular result would be ideal.

I poked a bit into these networks, and most if not all of them appear to be used for sattelite/public wifi purposes indeed. Some do not reveal much detail, but I guess it is okay to tag AS36492 as a whole. Will do so.

> It looks like it is not the full /24 but a couple of /27 ranges where Maxmind and WHOIS correctly show 'CA'

To keep the location database size within reasonably acceptable ranges, we decided not to be more specific than a /24 (v4) or a /48 (v6). The price of this is some inaccuracy, but otherwise, the database would simply become too big and too slow to process for firewall rules. Sorry.

> The location database (Geo blocking IP ranges before further firewall processing) is a very good feature and improves security while greatly reducing noise.

This is a common misunderstanding: The location filter _only_ intends to reduce noise (esp. useful on systems running on bad flash storage), not to improve security. True, an attacker needs to have access to an IP address within a certain country, but this is not a problem for advanced actors - sometimes, you even see them trying to enumerate which source country works best.

> However, it is not granular enough and there will always be incorrect/ambiguous address ranges and specific IPs in blocked countries that we want to pass.

Yes. We are planning to introduce AS-based firewall rules, since IPFire comes with ASN data at hand. These are much more granular than country-based rules, and come with a better accuracy.

> Updating/correcting the database helps but is very labor intensive.

Yes. This is an ongoing task - see #12421.

> A flexible solution would a 'local override' but I'm not sure if that is feasible (if the location database code is managed by IPFire or is third party code).
> It would be very useful to have a local override for the location database.  That way admins instead of developers could make adjustments for their sites.

I would oppose against this. Instead, we should encourage people to report faked/inaccurate information to us, so all users can benefit from them being fixed.

> A local override would also allow specific IPs (that are correctly identified) in countries that are otherwise broadly blocked.

Indeed, this is not the design intention of the location filter, it works too coarse for this task.

If the affected services are located behind IPFire, you can always extend the firewall rules already in place. For IPsec and OpenVPN, this is currently not possible via the GUI - please refer to #12025 for details.

https://patchwork.ipfire.org/project/location/patch/8ad52484-09a5-1b92-f457-3a7172216dca@ipfire.org/

(In reply to Peter Müller from comment #3)
> > It looks like it is not the full /24 but a couple of /27 ranges where Maxmind and WHOIS correctly show 'CA'
> 
> To keep the location database size within reasonably acceptable ranges, we
> decided not to be more specific than a /24 (v4) or a /48 (v6). The price of
> this is some inaccuracy, but otherwise, the database would simply become too
> big and too slow to process for firewall rules. Sorry.

In the future we might want to revisit this, but until we can do this, we will have to find ways to improve tooling to generate the database faster. After downloading all required information from our data sources, we take about 2 hours to just compile all data together that it becomes a small database. Adding more information will make this even slower.

(In reply to Paul Vondrasek from comment #2)
> Updating/correcting the database helps but is very labor intensive.  
> A flexible solution would a 'local override' but I'm not sure if that is
> feasible (if the location database code is managed by IPFire or is third
> party code).
> It would be very useful to have a local override for the location database. 
> That way admins instead of developers could make adjustments for their sites.

A strong NACK from me for that. There are two reasons:

The first one is technical: It will make database lookups slower. The compressed binary-tree in which the database is being stored is read-only and opening it and writing it again is too resource-intensive. Adding a second list that is being scanned probably won't be good for performance either.

The second reason is: This creates a lot of work for the admin. Each and everyone. Reporting anything upstream (i.e. us) has the benefit that everyone gets the change within a couple of hours. There should be an incentive to pool all our resources and make everyone benefit from any research that single people have done.

> For example, with the Satellite Starlink ranges above, if I wanted to
> location block US/Satellite but still allow the two CA networks that are
> incorrectly labeled as such then I would add them to the local override
> file.  The location database logic could first check the file for the IP and
> if found it would be allowed as ADMIN-OVERRIDE (some unique 2 CHAR Code) and
> no further checking would be done.

We would have never found out about this and most people would have seen this classified incorrectly for forever. Reporting it here is the better way.

https://git.ipfire.org/?p=location/location-database.git;a=commit;h=620c59f9e2a95187deba81aa575bf3bd3e21c69c

This is now active since 12 days. Setting status to MODIFIED.

@Paul: Are there any questions/issues left? If not, I'd close this one.

Thank you for your contribution.

Thanks for the detailed answers guys.
I see that what I am trying to achieve (access to DMZ services and VPNs for select addresses in Geo-Blocked countries) needs to be done outside of location block.
It is essentially the same issue as #12025.  I will do more research to see where to add custom iptables chains/rules ahead of location block to enable this.
I was unaware that VPNs were not subject to the location block (to me it would make more sense if they were - and then it would require these same custom rules to allow specific IPs).

(In reply to Paul Vondrasek from comment #8)
> Thanks for the detailed answers guys.
> I see that what I am trying to achieve (access to DMZ services and VPNs for
> select addresses in Geo-Blocked countries) needs to be done outside of
> location block.

Yes, the location block was more meant as a coarse filter.

> It is essentially the same issue as #12025.  I will do more research to see
> where to add custom iptables chains/rules ahead of location block to enable
> this.

Indeed. firewall.local is the place for such custom rules; please refer to https://wiki.ipfire.org/configuration/firewall/firewall-local for further information.

> I was unaware that VPNs were not subject to the location block (to me it
> would make more sense if they were - and then it would require these same
> custom rules to allow specific IPs).

They _are_ covered by the location block as well. But the location block does not support different countries for different services offered/forwarded by an IPFire installation. Sorry to disappoint.

I'd take the liberty to close this as being FIXED. If it isn't, please reopen.