https://community.ipfire.org/t/firewall-source-location-rule-ignored/7977/4 Steps to reproduce this behaviour: 1. Create a firewall rule with either a country or entire RED as a source, IPFire's RED interface as a destination, and portforwarding being configured from TCP port 443 to 222. 2. Reload the firewall engine to apply the rule. 3. Try to connect to IPFire from a machine on the internet (in the correct country, if configured): Both port 443 and 222 are publicly reachable. However, based on the rule, one would expect to only port 443 being exposed. This appears to be a bug in the firewall engine, although it only appears to affect port forwardings to IPFire itself, so it is not as bad as it could be.
This is kind of how the firewall works here. It does the NAT first, and then evaluates any filter rules. At that point, it does not know whether a packet was NATed before or not. We could only fix this with a marker, but I am not sure if we can change packets at NAT time. Since this is however unexpected behaviour, I would consider this a security-sensitive problem.
This seems related to this bug. Core 169 Incoming port forwarding from various external ports on the firewall to port 22 on several internal servers had been working for some time. The location of these ports was set to the US. Suddenly, incoming traffic went to the servers on one particular firewall but no traffic was allowed out. Changing the selection from Location US to Standard Networks fixed the issue.