Dropped RST packets and fwrule 0

Currently running 9.705-3, with Firewall, Network Visibility, Wireless Protection, Remote access and WAF enabled, and I'm seeing the following in the logs: 

2020:12:29-14:07:53 home ulogd[5006]: id="2000" severity="info" sys="SecureNet" sub="packetfilter" name="Packet logged" action="log" fwrule="0" srcip="" dstip="my.internet.ip.addr" proto="6" length="40" tos="0x00" prec="0x00" ttl="56" srcport="49892" dstport="31552" tcpflags="RST" info="nf_ct_tcp: invalid RST "

2020:12:29-14:07:54 home ulogd[5006]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="2a:8a:1c:ec:62:72" dstmac="00:30:18:cd:76:18" srcip="" dstip="my.internet.ip.addr" proto="6" length="40" tos="0x00" prec="0x00" ttl="56" srcport="49892" dstport="31552" tcpflags="RST" 

In the live log, I see this:

the first one in the live log, in white, with no rule mentioned, this relates to the fwrule 0 log entry. What's fwrule 0? i can find a few mentions of it on here, but no answers to say what it is. I have a DNAT rule that *should* allow the packet to be passed on (the rule does work, as I have connections that hit it regularly). Unfortunately, the DNAT rule is set to not log, so I currently have no way of knowing if the connection ever existed. It is logging now, so that may help in future.

IPS is off, SYN flood and ICMP flood protection are enabled, UDP flood protection is not, anti-portscan is set to drop. Strict session handling is off, as is block invalid packets, both of which I imagine might cause some behaviour like this.

I guess I have two questions. What is fwrule 0, and why is my fully functional DNAT rule not passing the packet on? I am wondering if the two things are related.


[Edit: I have 4000 log entries for fwrule="0" just for today, nearly all 'logs', but some drops too. The traffic I am particularly interested in is torrent-related, and i'm looking into an issue related to connections to peers. of these 4000, 1000 are addressed to the correct port for my client. The info field for the torrent traffic says one of these:

"nf_ct_tcp: invalid packet ignored in state SYN_RECV "

"nf_ct_tcp: invalid packet ignored in state ESTABLISHED "

"nf_ct_tcp: invalid RST "

are those conntrack messages?

of the wider 4000, 1300 are outbound from devices with all outbound traffic permitted by rule - again, suggests conntrack]

added missing sentence (oops)
[edited by: Dave Curr at 3:29 PM (GMT -8) on 29 Dec 2020]
  • XG and UTM does the same with this invalid traffic, so this KB applies here as well: https://support.sophos.com/support/s/article/KB-000037984?language=en_US


  • first:

    Often the server send the RST (reset session) some time after the last real packet is exchanged.

    Mostly the firewall has removed the session from session table already (because of some TCP-timeout).

    So the dropped RST packets are created. ... ignore them ...


    i can't assign the messages currently...


    Sophos Solution Partner since 2003
    If a post solves your question click the 'Verify Answer' link.

  • As Dirk said, I wouldn't worry about RST packets being dropped out of the INPUT chain (60001), and you're right that that's conntrack in action. The fwrule="0" messages indicate that you've made additional selections in the 'Protocol Handling' section on the 'Advanced' tab of 'Firewall'.  That's explained in the KB that Toni linked to, but that might not be clear if you've not played with XG.

    Cheers - Bob

    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • That's a fair point, but if it doesn't match a conntrack rule, surely the NAT rule should pass it on. I can see no reason you'd *need* to pass it on, as if conntrack has no match, it serves no purpose. I'm certain these are not causing a problem, I'm just curious why it happens. 

  • No experience with XG besides installing it in a VM last week. Thanks for pointing out Toni's reply though, I totally missed it :-) and that does make sense.