Lots of default drops in firewall log

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 <server source port> <any client destination port>

iptables -A OUTPUT <any client source port> <server destination port>

you can just create the rule on the INPUT side where the connection is first initiated:

iptables -A INPUT <server source port> <any client destination port>

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.

ChrisAtMaf

I assume same lines should be added to the ip6table.filter?

I'm seeing similar RST type firewall log entries involving local and remote ipv6 addresses.

Edit: Actually looking at the firewall log, it's showing it as a default drop in the FORWARD chain.  So  this rule goes somewhere in the FORWARD section, above the 60002 LOGDROP?

2022:05:04-14:06:45 utm ulogd[5460]: id="2001" severity="info" sys="SecureNet" sub="packetfilter"
name="Packet dropped" action="drop" fwrule="60002" initf="eth2" outitf="eth0" srcmac="00:16:4d:d1:96:c4"
dstmac="c0:a0:xx:xx:xx:xx" proto="6" length="60" srcip="2600:1407:3c00:29::1721:1d05"
dstip="2600:1700:xx:xxx:xxx:xxx:a42b:9661" hlim="54" srcport="443" dstport="63201" tcpflags="RST"

ChrisAtMaf

While your other post is awaiting moderation, please see above.

Hey, hopefully you can see my post now! I'm not in a job where I've got access to a Sophos UTM any more, and don't have much relevant ip6tables experience, I'm afraid. It's weird that this is in the FORWARD chain but that could be a difference in the way transparent filtering works in IPv6, or in ip6tables itself. In general there is no reason I can think of why your firewall shouldn't send ACK, FIN and RST packets to your internal clients if you are pretty sure they are generated by the firewall itself (via a transparent interface if necessary). I'd be more careful if they might be coming from outside your network. I'm afraid it's difficult in my situation to judge what's happening here. If you're unsure then dropping the packets without logging is also perfectly reasonable and marginally safer.

After some thought, it does make sense.

Recall that client ipv6 addresses are directly routeable to the internet. There is no NAT.  UTM's function is to just pass those packets through without any processing (other than firewall perhaps).

The only webfiltering I have for ipv6 is url filtering enabled. Otherwise everything goes out over the wan's ipv6 address, not the clients. That is, it's the same address over and over and not the temporary ipv6 addr generated by SLAAC.

Since adding those lines to the FORWARD section in the same spot - above the last forward line with the logdrop those, such firewall entries no longer appear.

I should add, the dstip="2600:1700:xx:xxx:xxx:xxx:a42b:9661", above is the ipv6 of a local client.

Great. Sounds like you've got it working the way you need it to :)

Great. Sounds like you've got it working the way you need it to :)