Linux – Iptables rule for loopback

The ACCEPT target is a terminating target that allows packet to get through NetFilter. The REJECT is a terminating targetd that effectively disallows packet to get through and causes the ICMP response to be sent to the packet originator. The third rule in your sample most likely looks like this if you list the tables with 'iptables -v -L' command:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  639  304K ACCEPT     all  --  any    any     anywhere             anywhere             state RELATED,ESTABLISHED
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere            
  101  7798 ACCEPT     all  --  lo     any     anywhere             anywhere            

In the column in there is an interface the rule is matching on. For the third rule it is the lo interface, so this rule allows any traffic on loopback interface and this is correct, as otherwise you will not be able to access any local to the host services over TCP or UDP at localhost address.

The creation of the TCP RST packet is from your rule

-A INPUT -p tcp -j REJECT --reject-with tcp-reset

The default policy (ACCEPT in your case) only applies to packets that do not match any of the rules in your chain. If a packet matches the rule above with the REJECT target, it will not be subject to the default policy and will be REJECTed (and generate a TCP RST) rather than ACCEPTed.

This TCP RST will not match your rule:

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

because it is not RELATED to another established connection and it is not part of an ESTABLISHED connection. It will continue through your rules and match

-A OUTPUT -m limit -j LOG --log-prefix "UNKNOWN_OUTGOING: " --log-level 5

and end up in your log. If you do not want to log these RST packets, either adjust this rule to not match them or insert an earlier rule to match the RST packets and so something with them before they get here.

Something else I'm noticing is that the first packet you are logging is a SYN/ACK packet from a remote webserver, which looks like a response packet from the remote webserver to a SYN packet you would have earlier sent to begin the connection to the remote host on port 80. If you didn't send an initial SYN, I don't think the connection would match 'ESTABLISHED', but if you did send a SYN then I think the connection should mach 'ESTABLISHED'. This could be messing with which rule your RST ends up matching.