Lots of default drops in firewall log

Question

My firewall log very much resembles that in the first post of this thread - https://community.sophos.com/utm-firewall/f/management-networking-logging-and-reporting/34526/firewall-log-full-of-default-drops-when-web-browsing#

Also reference this kb article - https://support.sophos.com/support/s/article/KB-000034235?language=en_US

I've read through both entirely but am confused on the solution.

Near the bottom Chris Hill points out these two lines to add to the iptable.filter

-A OUTPUT ! -o eth2 -p tcp --tcp-flags SYN,ACK,FIN ACK,FIN -j ACCEPT
-A OUTPUT ! -o eth2 -p tcp --tcp-flags SYN,RST RST -j ACCEPT

My confusion lies in why these are ACCEPTed and not DROPped? As documented in this post - https://community.sophos.com/utm-firewall/f/management-networking-logging-and-reporting/34526/firewall-log-full-of-default-drops-when-web-browsing/349259#349259 , the ! indicates this rule is valid for all non wan-interfaces. A sample log entry looks like this on my end.

2022:05:01-17:42:50 utm ulogd[26004]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth0.5" srcmac="96:6b:3b:12:34:56" srcip="142.250.64.228" dstip="10.10.5.110" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="43298" tcpflags="RST"

Log entry shows a source ip from the INTERNET but the source mac is from the LAN interface (vlan5 technically). How both be true? Or is this a good example of an invalid packet?

Given the packet identity (RST flag and on eth0.5), this satisfies the second rule above but the ACCEPT question still remains. Indeed this does work as the firewall log no longer contains a ton of these entries.

BAlfsonMaybe can shed some light on this? The KB article suggests this packet is coming from the internet.... But is it?

<<daze and confused>>

This thread was automatically locked due to age.

ChrisAtMaf · Accepted Answer

Hi Jay Jay , This is Chris Hill here posting from a different account since I've changed job. You need to think about this as a failure of the 'stateful' nature of the Sophos firewall. There are three basic 'chains' in iptables (along with others), INPUT, OUTPUT and FORWARD. INPUT and OUTPUT handle all traffic destined to or coming from the host itself; FORWARD handles all traffic which is 'passing through' the host using IP forwarding. Because the web filtering operates as a 'local' application on the host (even when in transparent mode), INPUT and OUTPUT are both relevant rules. Under most circumstances in order to make configuration simpler, modern 'stateful' firewalls have a rule near the top of the OUTPUT chain which allow any traffic 'established' or 'related' to an existing connection to get 'through' the OUTPUT rule. This means that instead of creating two rules for any given service e.g.: iptables -A INPUT iptables -A OUTPUT you can just create the rule on the INPUT side where the connection is first initiated: iptables -A INPUT and the ESTABLISHED, RELATED rule will handle the OUTPUT for you. This is the basic 'stateful' firewalling. BUT that ESTABLISHED, RELATED rule is *essential* for smooth operation. Try disabling it - you'll find that clients cannot initiate connections - the initial packet will be received, but the moment the server tries to respond, it's blocked via the OUTPUT rule. What's happening here is that the ESTABLISHED, RELATED rules aren't treating the final 'ACK, FIN' or 'RST' from the REMOTE SERVER to the INTERNAL CLIENT in an abnormally terminated connection as ESTABLISHED or RELATED - so they are instead dropped. These are valid packets which are required to be RFC compliant, as well as filling up the logs, so allowing them through is better than not, and saves a (tiny amount) of memory on your client's state table (each client on your network is waiting for 'ACK, FIN' or 'RST' to completely close the connection - it will get closed automatically after a while, but it has to wait for the timeout). The reason you're seeing a source IP from the INTERNET whereas the source MAC is the LAN interface is probably because the web filtering is operating in transparent mode. In other words, the Sophos box is 'pretending' to 'be' the remote IP address in its replies instead of 'being' itself - so on a Layer 3 level the IP is Internet-based, but on Layer 2 the MAC address is local. You are seeing this on the OUTPUT interface though because it's still a local service. Basically it's a side-effect of transparent filtering - if you were accessing the web filtering service using the 'non-transparent' port 8080, you'd have the local IP address to match the MAC as well.

Lots of default drops in firewall log

Top Replies