Working on new features - user input and beta testers wanted

[friendly-bits]

Here's an update on this project.

I'm currently working on implementing a feature request by a user to have outbound geoblocking in geoip-shell. I'd like to hear from additional people who are interested in this feature. I'm interested to know how you would like to use it - whitelist or blacklist mode? Any particular requests for controlling this feature via the command-line interface?

Because this feature requires some pretty major changes in code, I'll probably release a few versions as beta and gradually iron out the inevitable regressions and bugs. If by any chance someone wants to help me with testing, this would be fantastic - please do let me know.

I realize that barely anyone reads announcements, so chances of receiving much useful input are not great, but I'm thinking that it doesn't hurt to try.

At this point the core (firewall backend-independent) functionality has been implemented, and the nftables library has been updated to support the feature. I haven't yet started to update the iptables library.

As with all other important geoip-shell features, this one will be integrated in the interactive setup flow to make configuration as easy as possible, in addition to being configurable via the command-line options.

Speaking of the command-line options, the -manage script has gained a new -D option, which stands for direction. This is how it is described in the 'usage' output (printed when calling the -manage script with the -h option):

'configure' action:
General syntax: configure [options] [-D <inbound|outbound|2way> <options>]
Example: 'geoip-shell configure -D inbound <options>' configures inbound traffic geoblocking.

To configure same options for inbound and outbound geoblocking, use:
  'geoip-shell configure -D 2way <options>'
To configure separately inbound and outbound geoblocking in one command, use the direction keyword twice. Example:
  'geoip-shell configure -D inbound <options> -D outbound <options>'
If direction (inbound|outbound|2way) is not specified, defaults to configuring inboud traffic geoblocking. Example:
  'geoip-shell configure <options>'

Options for 'configure -D [inbound|outbound|2way]'
  (affects geoblocking in the specified direction, or both ways with '2way', or inbound if direction not specified):

  -m <whitelist|blacklist|disable> : Geoblocking mode: whitelist, blacklist or disable.
        'disable' removes all previous config options for specified direction and disables geoblocking for it.

  -c <"country_codes"> : 2-letter country codes to include in whitelist/blacklist. If passing multiple country codes, use double quotes.

  -p <[tcp|udp]:[allow|block]:[all|<ports>]> :
        For given protocol (tcp/udp), use 'block' to geoblock traffic on specific ports or on all ports.
        or use 'allow' to geoblock all traffic except on specific ports.
        To specify ports for both tcp and udp in one command, use the '-p' option twice.

General options for the 'configure' action (affects geoblocking in both directions):

  -f <ipv4|ipv6|"ipv4 ipv6"> : Families (defaults to 'ipv4 ipv6'). Use double quotes for multiple families.

...
(more options follow, irrelevant to direction-specific geoblocking)

Here is a sample output of the (direction-specific part of) status command:

Comments on how this can be improved are welcome. If you like the way it's implemented right now, do let me know as well.

[pressrestart]

Count me in! It sounds great and very useful for worst-case scenarios in home networks (for example: if someone downloads a virus and that virus sends your data or downloads something from some russian server, it has nowhere to go :D )

[friendly-bits]

Generally I think this is mostly useful as a prevention measure. If one gets to a point where they are already hacked, they should be looking at disconnecting the equipment from the internet entirely, rather than geoblocking.

One particular use case is setting up outbound geoblocking for a local network where you basically make a blacklist of countries which you know for a fact that you won't need to connect to (or a more restrictive whitelist of countries you only need to connect to), and in case you get infected, this may prevent the malware from contacting its servers. Another interesting use case is a server which does not need to fetch any content, except from specific countries.

[pressrestart]

That’s a good point. For example, in my case, I generally only need access to my own country and the United States, with a few rare exceptions (like when I use services such as 1fichier, which I believe is hosted in France). However, I can see how others might need broader access, especially if they are running a server or playing online games where servers are scattered across different regions worldwide.

I understand that geoblocking is more of a prevention measure, but if the malware can’t serve its purpose because its blocked from contacting the server, are you really hacked?
It’s kind of like that philosophical question: "If a tree falls in a forest and no one is around to hear it, does it make a sound?"

[friendly-bits]

I just released v0.6.0 which support outbound geoblocking - testing is very welcome and any comments will be appreciated!

[pressrestart]

I have an additional inquiry: Would it be possible to consider implementing a whitelist mode that allows for specific URLs from countries outside of the whitelisted regions? For instance, I would like to whitelist the United States but require access to a single website based in Brazil. Thanks.

[friendly-bits]

Hi @pressrestart , somehow I didn't have the notification about this comment either and only saw it now. Sorry about the delayed reply. geoip-shell already has a feature called "trusted ip's" which you can use to bypass the geoblocking filter for certain ip addresses. Specified addresses are allowed in both directions: inbound and outbound. If you feel that a separate list of addresses for each direction is needed, I can see what I can do about this.

To enable this feature, use this command: geoip-shell configure -t <ip_addresses> (if specifying multiple addresses, put them in double quotes).

As to allowing URLs/domains, geoip-shell can not do this. geoip-shell is in its core an application configuring the firewall and firewall doesn't deal with URLs or domains - it only deals with ip addresses, subnets, ports etc.

[PeeK1e]

Actually i thought this feature was already baked in and was kind of confused why websites still were reachable, silly me 🤦
But i would also be looking forward to blocking specific countries outbound, just to prevent some users in my net to access countries known for spreading <things>.
If you do have the feature in beta, feel free to ping me. ill test it on my FW :)

[pressrestart]

Or instead of blocking a list of tons of countries, you could just whitelist US+ the country you live in.
It's much less work and 99.9% of the internet works just fine by just allowing those because almost every popular website/service is hosted there.
Of course this applies to home networks. If you run a server you might have extra needs.

[friendly-bits]

Hi @PeeK1e , somehow I didn't see the notification about your comment. Anyway, I just released v0.6.0 which supports outbound geoblocking. I'm not sure if the 'beta' word suits this version, as after a ton of testing and bugfixing, I feel that it's pretty solid at this point, but as coding goes, there probably are surprises which I'm unaware of :)

Please do let me know how it goes or if you feel that anything is missing or could be improved.

[pressrestart]

Thank you for the update. I have been using the latest build today and have a couple of inquiries:

1. I tested a torrent with over 2,000 seeders to check if my PC connected to any IPs outside the United States. During this test, I observed that some connections were made to IP addresses in Canada, although most were within the U.S.
   
   Could this potentially be a bug, or is it possible that qBittorrent is incorrectly displaying the country flag?
2. Would it be feasible to implement a feature in the future that allows users to whitelist specific websites without needing to whitelist an entire country? For instance, forum.openwrt.org is hosted in Germany, but I do not visit any other German websites.

Overall, the build is robust, and I have not encountered any issues. The setup is intuitive, and performance has been excellent.
Thank you for your dedication and hard work!

[friendly-bits]

Thank you for testing.

1. Could this potentially be a bug, or is it possible that qBittorrent is incorrectly displaying the country flag?

Both RIPE and ipdeny include the 2 ip addresses from your screenshot in the ip list for US. You can check this by yourself using the utility included with geoip-shell which is called check-ip-in-source. It doesn't get installed into the system and is not included in the OpenWrt package which I assume you are using, so you may need to download the complete geoip-shell distribution, extract it and then run check-ip-in-source from it:
sh check-ip-in-source.sh -i "149.50.218.147 149.88.97.116" -c us
(currently check-ip-in-source.sh doesn't work unless you run it from the geoip-shell distribution directory - this will be fixed in the next release)

I can not tell for sure whether the RIPE/ipdeny database is wrong (to my understanding, ipdeny uses the RIPE database, except they distribute it after some optimizations) or whether the database used by your bittorrent client is wrong. Geolocation databases are inherently not 100% reliable. While you get correct results in the vast majority of cases, in some cases country codes are identified incorrectly in the database. Per another user request, I will be looking into implementing support for a 3rd ip lists source: Maxmind, which (possibly) has data that is somewhat more precise. Anyway, this is certainly not a bug in geoip-shell.

2. Would it be feasible to implement a feature in the future that allows users to whitelist specific websites without needing to whitelist an entire country? For instance, forum.openwrt.org is hosted in Germany, but I do not visit any other German websites.

I replied to this question above but you probably didn't see that reply, so I'll repeat it here:

geoip-shell already has a feature called "trusted ip's" which you can use to bypass the geoblocking filter for certain ip addresses. Specified addresses are allowed in both directions: inbound and outbound. If you feel that a separate list of addresses for each direction is needed, I can see what I can do about this.

As to allowing URLs/domains, geoip-shell can not do this. geoip-shell is in its core an application configuring the firewall and firewall doesn't deal with URLs or domains - it only deals with ip addresses, subnets, ports etc.

[friendly-bits]

You could look up the ip addresses of domains you want to allow and add them to "trusted ips". The only issue is that ip address assignments may change over time. If you feel strongly about this feature, I may consider adding an option to configure a list of domains to allow (dns lookups will be performed to get their ip addresses) and implementing periodic dns lookups of these domains to update the ip addresses. This is not bullet-proof either because many domains (especially ones in use by big corporations) have multiple dns records associated with them, and only some of these records are available upon lookup. So this may help to allow domains for small organizations like openwrt.org but this won't work to robustly allow domains for something like google or cloudflare. (that said, the big corporations probably have servers in the US, so for the most part this wouldn't be an issue in your specific case)

[pressrestart]

Thanks so much for getting back to me and for the detailed response! Sorry for the late reply. For my first question, it’s not a big deal, but if you do release an update with an alternative database, I'd be happy to test it out 😀
About the 'trusted IPs' feature, I really like the idea. I know it might be a lot of work and you've already done so much, so maybe it’s best to see if others are interested before going ahead?
Thanks again for all your hard work! I'll keep using it and let you know if I run into any issues.

[friendly-bits]

About the 'trusted IPs' feature, I really like the idea

It's not just an idea, it's already implemented :)

Just read the documentation.

[pressrestart]

Great! And sorry about that, I should've read the entire documentation before.
I think I might have found something, could you test it on your end?
In my case, if I turn geoip-shell off and then I turn it back on, geoip-shell doesn't work unless I reinstall it from scratch.
This is what I get when i run geoip-shell status after turning it back on

root@pfSense:~# geoip-shell status

geoip-shell status:

geoip-shell v0.6.0

Firewall backend: nftables
Ip lists source: ipdeny
Geoblocking rules applied to network interfaces: wan

Trusted ip's:
ipv4: 104.20.77.38

nftables sets optimization policy: memory

Cron system service: ✔
Update cron job: ✔
Update schedule: '15 4 * * *'
Last successful update: Nov-11-2024 00:55:34
Persistence: ✔
Automatic backup of ip lists: Off

inbound geoblocking:
  Mode: whitelist
  Country codes: US ✔
  Ip families: ipv4 ipv6 ✔

  Protocols:
  tcp: Geoblocking all destination ports
  udp: Geoblocking all destination ports

  Geoblocking firewall chain: enabled ✔
  whitelist blocking rule: ✔

outbound geoblocking:
  Mode: whitelist
  Country codes: US ✔
  Ip families: ipv4 ipv6 ✔

  Protocols:
  tcp: Geoblocking all destination ports
  udp: Geoblocking all destination ports

  Geoblocking firewall chain: enabled ✔
  whitelist blocking rule: ✔

No problems detected.

Despite whitelisting only US, I can still access websites like yandex.ru, government.ru (russian websites) and oglobo.globo.com (brazilian website).
I've tried rebooting and disabling other services/addons to make sure there are no clonficts somewhere else causing this but it only started blocking those countries properly after a fresh reinstall+redo the config.
But maybe it's just something with my setup.
Whenever you have time please let me know if you can reproduce this on your end.
Thanks.

EDIT: I changed the source to RIPE to test if maybe that fixed it but no luck. Keep in mind this only occurs when I turn geoip off and then back on. I also tried geoip-shell restore.

EDIT2: I'm also having issues with the uninstall commands. I tried both and I get these errors:

root@pfSense:~# geoip-shell-uninstall.sh
-ash: geoip-shell-uninstall.sh: not found

root@pfSense:~# opkg uninstall geoip-shell
opkg: unknown sub-command uninstall

I installed it by downloading the ipk from github but I wanted to try the opkg command just in case. I ended up uninstalling it via Luci with no issues.
That being said, after a fresh reinstall all is working. Whitelisting openwrt.org worked and now I will do some more tests with torrents.

EDIT3: Testing with torrents, I think there's an issue with trusted_ips (not entirely sure, I need to test more)
When I add a trusted_ip, I can see and download from other countries outside US.
This is qbittorrent with geoip-shell with no trusted-ips

And this when I add openwrt.org IP as trusted IP

I will keep testing tomorrow, I will remove all other packages completely to make sure these are not issues with my setup. Don't want to make you waste time!
Thanks again for everything.

[pressrestart]

Ok, after disabling every other addon and reinstalling geoip-shell, I can only reproduce the issue with the uninstall commands. Everything else seems sorted out. Turning geoip-shell on and off works fine.
qBittorrent connects to Netherlands and Canada IPs but its only like 5 o 10% of the peers, everything else is US. I know it's not something related to geoip-shell but just wanted to put that out there to clear up any confusion that my latest post may have caused. Thanks!

[friendly-bits]

Thank you again for testing. I made a mistake in the readme. The correct command to uninstall the Openwrt package is opkg remove geoip-shell.

If you encounter any problems with geoblocking, it would be helpful if you attached the output of:

nft -t list table inet geoip-shell
geoip-shell status