Hi,
first, thank you for opening a new thread for this.
This is because packets will first go through the IPS before reaching the location block afterwards. Therefore, the IPS will inspect such packets, and log if any rule triggers, even if the source country is enabled in the location block.
(This, by the way, will change with Core Update 164 and the “drop hostile” functionality: If the latter is enabled, all packets from and to hostile networks will be dropped before they are processed by the IPS.)
At the moment, I can only guess why this is.
My suspicion would be a design flaw in the xt_geoip module the IPFire core developers spotted a few weeks ago: Even if the location database is updated on an IPFire installation, the changed data will never land in the kernel space via xt_geoip module until the system is rebooted.
This means the location data actually used by the kernel will diverge from the location data displayed in the GUI over time. The longer an IPFire installation is up, the bigger will this delta grew. 
For Core Update 164, I cannot offer a solution to this. However, as discussed in February’s telco, we will replace xt_geoip with ipset in Core Update 165, which solves this flaw. Also, ipset is less dangerous in terms of security - we have always had kind of a headache with xt_geoip in this regard…
Thanks, and best regards,
Peter Müller