Hello,
Since upgrading from 164 to 166 over the weekend my Location block has stopped working correctly (or how I expect it to work anyway).
I make use of a mail relay service. The EU service is hosted in AWS in Germany from what I gather.
If I disable the location block… from DE and NL but block everyone else….
Incoming mails do not come through. I see a hit on the red firewall (DNAT) but the traffic is not forwarded to my mail server (checking the relay service its self, it says it could not be delivered connection is denied):
Checking the Firewall Log Country Germany:
Doing a location lookup on the ipfire machine:
In Location Block, If I now allow US
The internal forward rule is triggered. And I receive my mail….
Just testing some more. With my system Country Location allowing connections from the US and DE ie working situation. From a AWS server in the US I am able to connect to the incoming red email port from the US.
If on my firewall email rule I only allow Source Location DE - Germany. My Emails continue to come through. I double checked, that with this rule in place the port scanner from the US reported the port blocked. Yet the email is working. Odd right? Why does the US have to be allowed in the country block list in order for connections from DE to forward emails?
For the given IP Address 52.58.7.81 we can do a full location lookup.
CityFrankfurt am Main (1% confidence)
SubdivisionHesse (HE) (1% confidence)
CountryGermany (DE) (99% confidence)
Postalcode60313 (1% confidence)
ContinentEurope (EU)
Time zoneEurope/Berlin
But
Registered and represented country
Details about the country in which the ISP has registered the IP address 52.58.7.81. Furthermore, if available, the represented country. For instance, the country represented by an overseas military base or embassy.
Registered countryUnited States (US)
Represented countryNot Provided
So, the registered country seem to be the associated country in the location block …confusing
Ah, ok interesting.
So the IP is in Germany.
IPFire Location Blocking says the IP is in Germany.
But IPFire blocks it because the company using that IP is a US company? How does it know and should IPFire not put a US flag next to the IP and not a German one?
Surely thats a bug of some sort? All cloud providers would be affected? They are (mostly) all US companies.And its a pretty new change in IPFire, it only started happening with my upgrade from 164 to 166 this weekend.
The firewall engine has received various improvements for better performance, faster ruleset reloads, and easier code for developers:
The backend for the Location Filter, dropping traffic from hostile network, and more is now using ipset which is built into the Linux kernel instead the formerly used external kernel module called xt_geoip. This is important work which will allow us integrating new firewall features easier.
first, sorry for the late reply - ${dayjob} keeps my days quite packed currently…
This bug was caused by an optimisation in libloc, which caused suballocated networks not being properly processed with the correct country anymore. It has been fixed meanwhile, and upcoming Core Update 167 will contain this fix, automatically reloading the firewall engine to apply it.
For the sake of completeness: Core Update 167 will be released next week, unforeseen incidents not taken into account.
Apologies for this issue not being spotted before a productive release.
Updated today to 167 and the issue is fixed. I no longer see the odd behaviour concerning the location blocking and Location Blocking is working as expected again.