After upgrading to core 151, I can observe the following behavior on two machines:
ALL location filter source countrys are zero, I think this is wrong?
After upgrading to core 151, I can observe the following behavior on two machines:
Hi,
well, since they rules involve the xt_geoip
module (you can tell that because of the string -m geoip
on the right), it is fine to apply those for any IP address except private ranges and interfaces not matching red0
.
Are you observing issues with that configuration?
Thanks, and best regards,
Peter MĂĽller
Hi Peter,
I can’t tell you, if there are any issues, system is working so far.
I was just wondering that no packets (bytes) are dropped by any geoip rule at all.
Normally the count for Russia and China incremented within seconds…
All,
After updating to core 151, I too can verify that my iptables:LocationBlock looks identical to what Marco posted above. There are no hits reported in iptables:LocationBlock to either RU or CN, but the firewall log is showing them. All external hits coming in from the red are being dropped per the default policy.
Pete
Hi,
ah, those are the zeroes you were referring to. I thought it was 0.0.0.0/0
.
Indeed, those countries are normally very busy. The Netherlands use to be as well, at least from the statistics I observe here.
@marco @neutron_head: I guess you both experience the same problem.
location version
)?Thanks, and best regards,
Peter MĂĽller
Sorry, my first post wasn’t precise enough. Yes, I meant the counts.
root@ipfire:~# location update
Downloaded new database from Wed, 28 Oct 2020 04:27:12 GMT
root@ipfire:~# location version
Wed, 28 Oct 2020 04:27:12 GMT
This might be related to what I reported in another thread about all countries being logged as dropped, even though all in location block list.
With the original GeoIP block and (if I remember correctly) with early implementations of the new location block, if a country blocked then no logs of dropped connections for that country.
Again in a related test, with the original GeoIP block, if a country was blocked it overrode any incoming firewall rule for connections from that country. Country had to be unblocked to allow rule to work.
With recent location related releases, a firewall rule works for a country that is blocked in the location block list.
It feels previously that the location was checked first and in block list then return/exit.
Whereas now feels like firewall rule checked first and if matched then implement and return/exit, instead of going on to location block check.
Maybe this is an intentional change of logic?
As regards seeing lots of dropped connections, no it doesn’t matter, but previously a less busy log did make it easier to see the wood from the trees as it were.
My test into a PPPoE Red connection by the way.
My connection is DSL via PPPoE. Location version is Tue, 27 Oct 2020 04:27:20 GMT. An enforced update of location returns:
Downloaded database is outdated. Trying next mirror…
Could not download a new database
Hope that helps.
Hi,
I see, thanks for confirming this. A bug has been filed and I am working on a fix.
https://bugzilla.ipfire.org/show_bug.cgi?id=12519
Thanks, and best regards,
Peter MĂĽller
Hi,
for the records, a patch fixing this is now available:
I expect it to be shipped with Core Update 153.
Thanks, and best regards,
Peter MĂĽller
Have applied patch on my PPPoE connected box (IPFire 2.25 (x86_64) - Core Update 152 Development Build: master/2d43d770).
Seems to be working
Thanks for your work on this. Appreciated
Patch is tested for a few day now on two machines and is working fine (as expected).
Thanks a lot, @pmueller
Also tested here - working fine