I recently set up OPNsense on an E3-1240L v3 with 8GB of DDR3 ECC Unbuffered memory. With my aliases and rules I am running about 3GB RAM used at any particular time. I made an alias for geoip and added the US and DE to it. I then made a firewall rule with a source invert allowing only traffic from these two countries to my network. I have tested that the block is working by connecting to a handful of other countries over VPN and attempting to access my network. The problem is I am seeing some hits in Fail2Ban from a few IPs that are from countries that are not supposed to be allowed such as CN and GB. The system with Fail2Ban sits behind the OPNsense box within my LAN so it should never see the hits if OPNsense is doing its job. I grep'd the maxmind csv files and the IP blocks the single IPs are coming from are reported correctly in line with their whois information.
Does anyone know why I would be getting some IPs through the firewall that should be blocked by the geo IP alias set?
I attached a compilation screenshot showing the traffic to my internal device, the lookup of the IP via whois and then matching it to maxmind. Then it shows how I have the geoip set configured in Aliases and the Firewall block. Any suggestions would be welcome.
Do any devs monitor these forums? Seems like this should be knowledge held by someone.
.
I wasn't quite sure how to look in the actual GeoIP Alias in OPNsense. The closest I could figure out was to grep the country code of the subnet from the csvs that OPNsense is using as a source. I mean, mostly it's all working as expected, meaning that it must be populating. I just get a few one off strange cases as shown in the screenshot once in awhile.
.
Ok so I just checked and the 180.160.0.0/12 subnet is NOT in the whitelist_by_country alias as would be expected since I am using it for a source invert block rule.
Also, thank you for the way to see the individual entries in an alias. I was looking for that a few days ago with no success.
Edit: Since this person deleted EVERY single response even ones with helpful information, the way to see these subnets in the alias is by going to Firewall --> Diagnostics --> pfTables.
.
No. Those are the 4 subnets that show up when I typed 180.160 in the search bar above right. None of them are the subnet in question.
It sems you edited this post so to quote the new message:
Quote from: chemlud on November 18, 2020, 03:16:11 PM
But as it is not in your list, it should be blocked...
You're right it should have been blocked but it wasn't.
Quote from: chemlud on November 18, 2020, 02:26:25 PM
Nobody is perfect... or maybe China Telecom pays for not being included? Who knows...
...
This Geoblocking thing has nothing to do with OPNsense developers, better to complain there... ;-)
In response to the issue being taken up with the block list provider: That would make sense if the subnet was not shown correctly as belonging to a country outside DE/US. But it is shown in the providers subnet list csv as belonging to a country outside my GeoIP selection AND OPNsense is not showing the subnet as being included in the geoIP countries I have selected.
...but OPNsense was still allowing that subnet through the firewall for some reason. Or more accurately, an IP in a subnet that OPNsense should have known to block based on my firewall rule.
I put the effort in to verify that what you outlined above was the not the scenario in this case and went to pains to show that in my first screenshot collection. This IS the fault of OPNsense.
Quote from: chemlud on November 18, 2020, 02:26:25 PM
...and although CN is on my GeoBlock Alias, this 180.163.220.0/24 is not in the Alias. Nobody is perfect... or maybe China Telecom pays for not being included? Who knows...
In fact, your example here is the same exact scenario as mine. The maxmind list shows the subnet you listed as being part of china:
$ grep -r "^180.160." ./*
./GeoLite2-Country-Blocks-IPv4.csv:180.160.0.0/12,1814991,1814991,,0,0
---------------------
./GeoLite2-Country-Locations-en.csv:1814991,en,AS,Asia,CN,China,0
----> 180.160.0.0/12 = 180.160.0.0 - 180.175.255.255
.
Quote from: chemlud on November 18, 2020, 03:35:14 PM
Actually the 180.163.220.3 is blocked here with my geoblock including CN. Did you check what is all included in the INVERT logics of your firewall rule?
My firewall rule only has a source invert block to my WAN IP address with the geoIP Alias that has DE, US included.
.
Quote from: chemlud on November 18, 2020, 03:44:11 PM
Ehm, the rule on WAN makes no sense, as you should not allow ANYTHING from WAN. You need to have the rule on LAN with DESTINATION to your whitelist and INVERT...
And you will be surprised that most of yout interwebs won't work with only hosts from US and DE allowed (and by the way malware offenders from the US are more likely than not...)
Maybe I am not understanding the logic but I don't think I have it set up that way. As I understand it, the screenshot below illustrates that ONLY DE, US IPs are allowed into my network and the rule is applied to packets hitting my WAN interface.
To address your edit regarding malware coming from the US: That's fine. I have other aliases that are updated periodically based on probe/attack traffic I see from places such as Digital Ocean and Linode. I specifically want to know why OPNsense is not doing its job here in these admittedly small number of cases.
...And my network connectivity is not hampered in any way by this rule. It is an inbound rule AFAIK.
.
Quote from: chemlud on November 18, 2020, 04:12:56 PM
OPNsense is a stateful firewall. You have to block/allow on LAN. Don't ALLOW ANYTHING on WAN.
I am really not following here. I know it is a stateful firewall and as far as I know the rule is only allowing sessions INITIATED from the outside TO my WAN address which is then forwarded to the appropriate place on my LAN by OPNsense after the request is received.
.
Quote from: chemlud on November 18, 2020, 04:20:54 PM
OMG.
Dude, I don't know if that response is necessary. This is an INBOUND rule we are talking about. I want to allow some inbound traffic and deny others.
Edit: As I understand it, all that WAN designation does is tell OPNsense to APPLY this rule to packets coming in to the first interface they would hit from the outside: The WAN interface.
Of those packets coming into the OUTSIDE (read: WAN) interface NOT initiated from inside my network, apply the rule that only IP subnets listed as being from DE or the US may proceed to be evaluated by the next rule in the list. If they are not listed as DE or US they will be denied.
If this is not correct, could you please tell me where the break in logic is? This has nothing to do with stateful sessions at this point. I am trying to block/allow HTTP/HTTPS traffic to my reverse proxy that sits inside my home LAN BEHIND the OPNsense box and its WAN interface and that traffic/those requests are initiated from the OUTSIDE of the OPNsense box.
Edit: Glad I started quoting all your responses for the sake of posterity ;)
I see now that you were mistaken this whole time and thought I was trying to block ALL traffic inbound and block outbound LAN traffic to everywhere but the US and DE. That would be a very bizarre thing to do and definitely not what I was trying to accomplish. Thanks for trying to give me a lesson on networking and stateful packet inspection though heh.
I don't know if this is the exact same issue I am having, but I'm seeing mail traffic hitting my mail server which should be blocked by my GeoIP alias i.e. anything not in the alias should be blocked.
When I check the IP using a general IP Location website I confirm that it's from a "blocked" country but when I check the Maxmind GeoLite2 files the subnet is not present. Checking the full database at Maxmind confirms the same, that the GeoLite2 data is simply missing the subnet so it doesn't get blocked.
Has anyone been able to replace Maxmind with anything else? I can see that IP2Location has my example subnet listed so it would block it, but I have no idea if we can use their data instead.
Quote from: Taomyn on November 26, 2020, 10:18:44 AM
...i.e. anything not in the alias should be blocked. ...
...when I check the Maxmind GeoLite2 files the subnet is not present. ...
The way you explained it, it sounds like it's working as expected. That you have an Alias with only say USA IPs in it and then an inverse source rule that if the source is not a USA IP address it is blocked. That IP from say Mexico would not be in the list for the USA in the maxmind db or your rule set. You may have meant something else but that is what I understood.
Quote from: Plaidy on November 27, 2020, 02:12:34 PM
The way you explained it, it sounds like it's working as expected. That you have an Alias with only say USA IPs in it and then an inverse source rule that if the source is not a USA IP address it is blocked. That IP from say Mexico would not be in the list for the USA in the maxmind db or your rule set. You may have meant something else but that is what I understood.
No I think I wrote it correct, I have an alias list with the US plus some EU countries so "US, CA, UK, DE, BE, FR" and as you say the rule is inversed on the source, so when an IP from RU or CN comes in it should be blocked - but it doesn't always. My server continues to receive the occasional hit from RU and other countries not on the list and when I check the IPs they're not under their respective country, so to me it's like they get included regardless.
I've been staring at the rule I use for this and I'm at that point where I'm not understanding what I am doing - overthinking the whole thing and giving me a headache.
So to step back, what's the best rule to use to block all inbound external traffic that is not in my alias of allowed countries, and on which firewall interface is the rule located? I.e. a working example please ;D
As an alternative to blocking, something else I've been unable to achieve is a rule that instead redirects the traffic to a specific device in my DMZ.
@Plaidy; Did you get it to work?
ps Thanks for your detailed posts and for quoting chemlud.
Quote from: erje on January 13, 2021, 12:05:41 PM
@Plaidy; Did you get it to work?
ps Thanks for your detailed posts and for quoting chemlud.
Sorry for not replying here. I guess I don't have notifications setup when people reply to posts here. I did get it to work, or rather I gathered enough information be satisfied I guess. Still no actual explanation as to why some addresses can get through. Are you having issues?