2.27 cu 171 increased CTInvalid drops

[ipcopmann]

In 2.27 cu 171 I have seen a massive increase of CTInvalid log entries, mostly to port 443 (Google etc.).
Logs have increased too such a degree that in Firewall log (Country), green0 is the highest logged ‘Country’.

As Peter M suggested, maybe being dropped unnecessarily as suspected by devs.

2.27 cu 164 Testing release - Hostile & CTInvalid logging

Running 2.27 cu 164 Testing release and have enabled Drop packets from and to hostile networks. I have the majority of countries blocked to my firewall (as don’t host any services), but am getting many DROP_HOSTILE logs from blocked countries and a few DROP_CTINVALID from blocked countries. Is it possible for you to move the hostile network checking and CT Invalid checking logic to after Location Block logic? This would reduce logging for countries that should be getting ignored by the Locati…

Secondly in web admin, perhaps “Firewall log (Country)” should be relabelled “Firewall log (Network)”.

This should be bundled with Trish’s bug report really.

Excessive Logging

for BLKLST_CIARMY uncheck the Log dropped packets [Screenshot 2022-11-01 at 10.13.12 PM] on this WebGUI page: https://ipfire.localdomain:444/cgi-bin/ipblocklist.cgi for the DROP_HOSTILE there is not a way to disable but it is a good idea!

Find it unlikely so many connections to port 443 invalid.
These are mostly from Wi-Fi clients on a BT Whole Home mesh on Green LAN.

[bonnietwin (Adolf Belka)]

@ipcopmann

Secondly in web admin, perhaps “Firewall log (Country)” should be relabelled “Firewall log (Network)”.

This is classifying all firewall hits by the country they came from. However any firewall hits that cam from one of the internal networks (green0, blue0 or orange0) are not coming in from red0 but should be shown in some way. Effectively green0, blue0 or orange0 are coming from your country but from your internal networks.

@ipcopmann

As Peter M suggested, maybe being dropped unnecessarily as suspected by devs.

You can of course turn off the logging for drop_ctinvalid if there is too much of it.

If you believe that they are being dropped incorrectly then please raise a bug on it, providing the logs for the drop_ctinvalid and the corresponding data from the connection tracking table that those dropped packets were coming from an already existing valid connection.