My open sense is subscribed to Max Mind and updates on a regular interval, but the blocked countries are still able to make connections, rather frequently. Are there any workarounds that can elevate the detection ratio?
How do you even know?
- Are you still getting traffic by IPs that actually are in the Maxmind list? Then your firewall rules are probably incorrect.
- Are you seeing IPs that are from a specific country that you verified using another database that Maxmind does classify otherwise, then Maxmaind obviously is incorrect.
Only in the latter case could you use that other, better, database - that is, iff that is available in a useable form.
The latter. Maxmind misses lots of IPs in the countries that I block.
Hi there, I work at MaxMind. Our team is happy to take a look at any discrepancies or unexpected results. I'd recommend reaching out to our support team (https://support.maxmind.com/hc/en-us/requests/new) with the IPs you believe have an incorrect country designation and we can investigate.
You have net exposed services and want to use GeoIP blocking? Consider fronting it via Cloudflare or similar, then use their GeoIP blocking options.
Blocking by GeoIP is not a fruitful way to block real adversaries. If the target is say in US, adversaries will establish a jump point in the US, thereby making your GeoIP control a bit moot.
GeoIP blocking is a noise control, it's not an adversary control.
Quote from: BrandyWine on July 28, 2025, 08:40:18 PMGeoIP blocking is a noise control, it's not an adversary control.
Agree, yet bringing down the noise from e.g. Korean high schools (is that still a thing?) also helps with the load and with catching real threats.
What's the WAN side of the fw? Is it a modem, or a direct cooper/fiber connection?
If it's a modem, then having a modem that is configurable in some way is ideal, so you can dump blocking ACL's there, to keep that noise from touching your fw. If it's direct copper/fiber connection, then ask your ISP if there's a place you can add such ACL's.
Last resort, stick a basic router between ISP and your fw and put your blocking ACL's there. I forget what the fastest drop method is, is sending the noise to /dev/null a fast way? You might even find some GeoIP software to put on that basic router, this way it's more like what you are wanting,blocking by name and the list gets updated every 4 or 12 or 24hr, etc.
Bit bucket the noise, so the noise is not being processed by the fw iface.
Quote from: MaxMind-dev on July 28, 2025, 08:18:18 PMHi there, I work at MaxMind. Our team is happy to take a look at any discrepancies or unexpected results. I'd recommend reaching out to our support team (https://support.maxmind.com/hc/en-us/requests/new) with the IPs you believe have an incorrect country designation and we can investigate.
Thanks for the thought. Next time there is a misdetection, I'll cycle back. It's been happening rather regularly, about once per week, so not long to wait.
As to Cloudflare, I view them as extortion racket and treat them accordingly. They can go and do whatever.
Quote from: Jyling on July 29, 2025, 03:04:20 PMAs to Cloudflare, I view them as extortion racket and treat them accordingly. They can go and do whatever.
I think you missed the point.
Cloudflare (and many others) already does the GeoIP blocking (without issue), and, you stated you see an issue with your current solution. You're arguing why the better choice is a bad choice.
Maybe MaxMind-dev can ID the issue and provide solution for fix.
Quote from: MaxMind-dev on July 28, 2025, 08:18:18 PMHi there, I work at MaxMind. Our team is happy to take a look at any discrepancies or unexpected results. I'd recommend reaching out to our support team (https://support.maxmind.com/hc/en-us/requests/new) with the IPs you believe have an incorrect country designation and we can investigate.
Example: 173.249.20.0
Your DB places it in France, whereas it is situated in Germany.
MaxMind lookup online says the same, it gives back what's in ARIN, France.
Unless the toolset has IP detection bots all over, via self installed or partnered with ISP's, the exact entry location to the web will be hard to ID.
Does CONTABO run their own ISP service? If so are they backhauling clients into France before that dataflow hits the backbone?
If you have one of those IP's, what does traceroute (or tracert) look like?
Peering and such, France is surely in the mix.
https://iamroot.tech/asndatabase/?search=AS51167
Quote from: BrandyWine on August 01, 2025, 11:12:06 PMMaxMind lookup online says the same, it gives back what's in ARIN, France. [...]
ARIN? Where do you see that? I don't see it in Maxmind's lookup (unless I'm blind, which I am); I see ARIN pointing to RIPE (as expected), which has the RIR record, for Contabo GmbH in Munchen. Same with the origin AS (51167), which seems to be mostly connected through L3 (AS3356). As to where it's actually located...
It's weird, I am certain I did arin.net lookup and it said france, now it says germany. I should have done a screenshot.
This site (https://www.iplocation.net/ip-lookup) pulls the info from many geoip sites, some say France, some say Germany.
Also this about Contabo
Contabo has established a new data center known as "Hub Europe" in Lauterburg, located on the German-French border.
Their Hub Europe datacenter is new and it looks like they physically moved the stuff in Germany datacenter into Hub Europe recently. https://help.contabo.com/en/support/solutions/folders/103000633308/page/2?url_locale=en
Some info:
We're expanding our German quality and great prices! To better serve our European customers, we're building our brand-new Data Center in Lauterbourg
It looks like they migrated a bunch of Germany stuff to the new Hub Europe site, in France, so my guess is, geo IP saying France is correct.
https://www.ipaddress.com/ipv4/173.249.20.2
Maxmind places 165.231.227.0/24 in Rome, Italy, whereas it is situated in Saragoza, Spain.
Please allow MaxMind-dev to respond, instead of speculating.
The network 45.201.11.0/24 is in Berlin, Germany, but MaxMind places it in Thailand. The latter is blocked by my firewall alias, but they are still able to make connections. So, something is very, very wrong with both MaxMind and its GeoIP implementation in open sense. I cannot trust it after all of these breaches.
https://github.com/opnsense/core/issues/7779 ;)
That may address the issue of the accuracy but does not explain why an inaccurate location passed the block filter. According to MaxMind, the last subnet was in Thailand. I block that country. They made the connection. They should have been blocked.
I have never experienced that a geoblock IP was not blocked when I correctly set it. Are you by any chance trying fancy stuff with aliases like excluding something from the geoip list, like discussed here (https://forum.opnsense.org/index.php?topic=39584.0)?
That being said, the Maxmind geoip lite database that is normally used is not quite the same as what is presented here:
https://www.maxmind.com/en/geoip-demo
If you enter 45.201.11.0 as IP into that demo, you will be shown a network of 45.201.10.0/23, which is not actually separate in the downloaded Maxmind set, which gives:
45.201.0.0/21,1605651,934292,,0,0,
45.201.8.0/22,1605651,934292,,0,0,
45.201.12.0/24,798544,934292,,0,0,
45.201.13.0/24,2661886,934292,,0,0,
45.201.14.0/24,2623032,934292,,0,0,
...
However, 45.201.11.0 is still in Thailand, so if it is not blocked for you, something else must be wrong (see point 1 below).
On a side note, the linked issue 7779 (https://github.com/opnsense/core/issues/7779) also has a patch linked, that makes IPinfo.io available as an alternative provider for added accuracy (their database has almost 10 times more entries than Maxmind's). However, for the time being, there are two problems with this:
1. Your firewall alias table size will have to be increased significantly or you will get problem. I had to enlarge it to 50.000.000 entries, instead of the default ~1.000.000. Even with just Maxmind, the default size will probably not suffice.
2. When you do that, the hidden cron job that updates the aliases will take extremely long to run on a normal CPU (for me: ~15 seconds on an N100) . The actual table update that is called within the script seems to be a blocking operation, such that you will experience latency spikes of a range in hundreds of milliseconds (for me, it was 1.5s). This will delay packets, such that real-time traffic like VoIP will drop out every 60 seconds.
Franco said that this feature will therefore not find its entry into the next release 25.7.2 (https://github.com/opnsense/docs/pull/765).
Quote from: Jyling on August 14, 2025, 03:37:36 AMThe network 45.201.11.0/24 is in Berlin, Germany, but MaxMind places it in Thailand. The latter is blocked by my firewall alias, but they are still able to make connections. So, something is very, very wrong with both MaxMind and its GeoIP implementation in open sense. I cannot trust it after all of these breaches.
Where are you getting your GEO IP info from? What's telling you 45.201.11.0/24 is physically in Berlin?
Side example, CONTABO has registered block in Germany but they moved a datacenter to France, so it's more appropriate to GEO it in France, that's where the IP are.
Maxmind appears to be correct for 45.201.11.0/24:
Quote45.201.11.0 - 45.201.11.255 is an IP address range owned by 3xK Tech GmbH and located in Thailand
Registered blocks do not mean that's where they are physically located, etc.
What meyergru said, if you block Thailand and it wasn't blocked, then something else is the cause.
At least, the IP 45.201.11.0 is in Berlin, unless the laws of physics are out of order...
2025-08-17 10_31_25-45.201.11.0 IP Address Details - IPinfo.io – Mozilla Firefox.png
When you look at https://inventivehq.com/network-latency-calculator/, you will find that 0.38ms corresponds to a theoretical maximum distance of ~100km between the probe and the IP location, less is more likely.
Also, Maxmind's geoip lite did not discriminate the 3xK Tech ranges 45.201.10.0/24 and 45.201.11.0/24. because, as I showed, they list only 45.201.8.0/22, and there are ranges in it that do not belong to 3xK Tech. I guess that "geoip lite" does indeed indicate less resolution than their commercial offerings, as I also pointed out.
The actual IP is in MaxMind. I post the subnet. Speculations aside, it has to be blocked, but it passes.
Then please show the block rule in detail.
Quote from: franco on August 14, 2025, 12:29:16 PMhttps://github.com/opnsense/core/issues/7779 ;)
And it seems to be working nicely...
Yes, apart from the two mentioned problems (https://forum.opnsense.org/index.php?msg=244928)...
Quote from: meyergru on August 17, 2025, 10:37:54 AMAt least, the IP 45.201.11.0 is in Berlin, unless the laws of physics are out of order...
0.38ms is fast.
Global latency does appear DE is fastest to dst IP
https://tools.bunny.net/latency-test?query=45.201.11.2
9 of 10 geo location services show 45.201.11 in Bangkok.
https://www.iplocation.net/ip-lookup
If it's in Berlin then why are so many geo services getting it wrong?
Quote from: meyergru on August 17, 2025, 06:40:52 PMYes, apart from the two mentioned problems (https://forum.opnsense.org/index.php?msg=244928)...
They are not issues that affect my system. Lots of memory to spare and a decently quick CPU. I had an issue with Amazon web services being blocked, even though they were in Ireland and that is allowed. I had to put in a separate firewall entry to allow them. Changing to IPInfo has meant I no longer need that extra rule.
Quote from: Jyling on August 16, 2025, 04:32:40 PMThat may address the issue of the accuracy but does not explain why an inaccurate location passed the block filter. According to MaxMind, the last subnet was in Thailand. I block that country. They made the connection. They should have been blocked.
That's not what the initial text said. If you cannot be sure about accuracy how can you sure about inconsistent blocking?
Quote from: franco on August 20, 2025, 11:40:56 AMIf you cannot be sure about accuracy how can you sure about inconsistent blocking?
For instance, like I wrote 2ce already, the country that MaxMind places the IP in is enabled on the alias that is used in the block rule. I tested it and determined that it works, using my test addresses, but when it comes to actual production it sometimes allows the connection that is supposed to be blocked.
I have no way of knowing whether the IP could have changed its location in MaxMind DB between the moment in time when a hacker tries to break in and when I check MaxMind, which is one plausible excuse, but this happens sometimes.
> it sometimes allows the connection that is supposed to be blocked
This hinges on 3 factors:
1. current alias state
2. frequency of updates
3. particular IP in question
It's easy to test your theory if you adhere to these 3 constants, because I doulbt as long an 1. and 3. are known and good that it won't work, which only leaves 2 which means the database changes WRT to a particular address, but you can even test this over time easily.
Taking an IP address for 3 and determining it should have been blocked misses point 1. and 2.
Also, if a connection is allowed and not timed out it would likely also persist when it becomes available in the database (although it's suspicious you'd have a multi-day connection to an IP address, but that's a different issue).
Cheers,
Franco
It seldom takes us longer than 8 hours between an attack report and the check.
I doubt MaxMind updates in the mean time.
Quote from: Jyling on August 21, 2025, 03:24:37 AMI have no way of knowing whether the IP could have changed its location in MaxMind DB between the moment in time when a hacker tries to break in and when I check MaxMind,
There's always a way. ;)
1st, does the maxmind db live on the fw and it gets incremental updates? Seems plausible.
2nd, can we query that db from the cli? If so we can write a script for cron that looks for your problem IP and log the results to a file. cron every 1min and let that run for about 1wk (10,080 entries). Then analyze the log file.
3rd, what you get from the log file might explain issue as coming from maxmind, or, it's not a maxmind issue and you have to go digging elsewhere.
When the tool doesn't provide you exactly what you need, you have to go beyond the tool.
Quote from: ddg aiManually Querying MaxMind Database on OPNsense
Overview
Yes, you can manually query the MaxMind database on the OPNsense firewall. This involves setting up the database and using the appropriate client libraries to perform queries.
Steps to Set Up and Query
Install the MaxMind Database
Sign up for a MaxMind account and generate a license key.
Download the GeoIP database in MMDB or CSV format.
Configure OPNsense
Go to the OPNsense interface.
Navigate to Firewall > Aliases and select the GeoIP settings tab.
Enter the URL for the GeoIP database you downloaded.
Use Client Libraries
Install the MaxMind GeoIP client library for your programming environment (e.g., Python, PHP, etc.).
Configure the database reader to access the MaxMind database file.
Example Code Snippet
Here's a simple example in Python:
python
from geoip2.database import Reader
# Open the database
reader = Reader('/path/to/GeoLite2-City.mmdb')
# Query the database
response = reader.city('128.101.101.101')
print(response.country.iso_code)
Important Notes
Ensure the database file is accessible on your filesystem.
Use the correct method to query based on the database type (e.g., city or country).
Handle exceptions for failed lookups appropriately.
By following these steps, you can effectively query the MaxMind database on your OPNsense firewall.
I am Abdullah, the DevRel of IPinfo. I don't have anything to contribute here, but if you have any questions about our data, just ping me. I promised the Opnsense community that whenever there is a discussion about IP geolocation and our data, whether good or bad, I will be there to answer questions about our data. Thank you!
Quote from: BrandyWine on August 22, 2025, 12:17:40 AMThere's always a way. ;)
If you have a time machine. We can't go back in time.
Quote from: Jyling on August 24, 2025, 05:02:48 PMQuote from: BrandyWine on August 22, 2025, 12:17:40 AMThere's always a way. ;)
If you have a time machine. We can't go back in time.
Maybe wayback machine has it?
This thread has outlived itself.