Hi,
thanks for your testing feedback.
Indeed, both the “hostile networks” stuff and the connection tracking happen before the location block. For the latter, this cannot be changed due to technical reasons, so you can at best disable logging of DROP_CTINVALID packets completely.
Actually, I have long suspected conntrack to sometimes drop packets it actually should not have dropped. But since we never logged them, I was unable of the extend of the problem (actually, I am not quite sure if it is a problem at all). In theory at least, such drops should not occur, so it is good to have them logged - which is also why we decide to log these by default, since we hope that makes debugging previously unexplained network errors easier.
Regarding the location block, I really think we need to clarify the wiki page for it, and explain better what it does and what it doesn’t.
Since you do not run any services on your IPFire machine, you might as well disable the location block completely - incoming packets will be dropped later anyways, so there is no security implication in enabling or disabling the location block.
Actually, the intended purpose of the location block was to reduce the amount of log messages on installations running on extremely cheap flash storage. However, this feature turned out to be misunderstood frequently, and I think a firewall should always log if it interfered with the traffic for transparency reasons. The location block precisely does the opposite.
To cut it short: The only solution I can offer is to disable the “drop hostile” filter, and create a firewall rule for outgoing traffic to the country code XD, dropping and logging it. That will have the same effect, since incoming traffic cannot cause any harm in your scenario.
Also, and for the records, I am really unhappy with the location block, and I think it would be good if we replaced it by a better and less misunderstanding-prone solution.
Thanks, and best regards,
Peter Müller
