Thread Info
  • State Suggested Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 3 subscribers
  • Views 11549 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

tcpflags="RST" packages getting dropped

bonne
Some external users are facing problems accessing our webmail server through our Sophos firewall. It seems as the more lagged network they are accessing from, this bigger the problem is.

The firewall is logging numorous of the following:

2015:07:07-11:36:50 astaro ulogd[20692]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" ***_cut_*** proto="6" length="40" tos="0x00" prec="0x00" ttl="49" srcport="16261" dstport="443" tcpflags="RST"

I have searched the forum, and I see others with the same issue (ever with quite older Sophos versions), but no solutions. Are any updated info available?

No users on our LAN are facing problems with accessing the webmail.

Regards, Lars.


This thread was automatically locked due to age.
  • 0
    I was thinking that fwrule="60001" sounded weird, as our fwrules in terms of the webadmin interface starte with 1. But accourding to https://www.sophos.com/de-de/support/knowledgebase/115029.aspx it is stated to be a NAT thing:

    "Most of the time, fwrule="60001" means that you need to configure a NAT rule (likely DNAT), or review the configuration of your existing NAT because the packet is not matching the intended rule. Check for Interface Binding, that the source and destination port are correct, that you are matching the correct procotol (TCP, UDP, Both), and that the IP addresses are correct"

    So once again I took a look at the logs again with this new knowledge:

    2015:07:07-11:36:49 astaro ulogd[20692]: id="2000" severity="info" sys="SecureNet" sub="packetfilter" name="Packet logged" action="log" fwrule="62004" initf="eth1" srcmac="00:24:98:5d:7f:c0" dstmac="00:1a:8c:17:3c:05" srcip="ClientIP" dstip="ServerPublicIP" proto="6" length="64" tos="0x00" prec="0x00" ttl="49" srcport="16261" dstport="443" tcpflags="SYN"
    2015:07:07-11:36:49 astaro ulogd[20692]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="27" initf="eth1" outitf="eth0" srcmac="00:24:98:5d:7f:c0" dstmac="00:1a:8c:17:3c:05" srcip="ClientIP" dstip="ServerNatIP" proto="6" length="64" tos="0x00" prec="0x00" ttl="48" srcport="16261" dstport="443" tcpflags="SYN"
    2015:07:07-11:36:50 astaro ulogd[20692]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="00:24:98:5d:7f:c0" dstmac="00:1a:8c:17:3c:05" srcip="ClientIP" dstip="ServerPublicIP" proto="6" length="40" tos="0x00" prec="0x00" ttl="49" srcport="16261" dstport="443" tcpflags="RST"

    (and then repeated dropped RST's)

    By this I guess that the TCP_RESET does not get D_NAT'ed like the "normal" packages. Is this a correct conclusion? And how to solve it?

    Regards, Lars.
  • 0 in reply to bonne
    Unfortunately no replies to this yet.

    As indicated here firewall - Why I see RST being dropped? - Network Engineering Stack Exchange there might be an explicit rule to block RST-packets. I can't find any in the ordinary ruleset, but can this be set another place? 

    Advanced Thread Protection is set to "DROP" - could this be it?

    Regards, Lars.
  • 0
    Hard to tell from your obfuscation, but are you trying to connect to your own External IP from an internal LAN client or is this just some client out on the internet connecting to a web server you host via DNAT?

    there might be an explicit rule to block RST-packets. I can't find any in the ordinary ruleset, but can this be set another place? 
    Not visible from firewall rules, but there is an explicit drop rule that is always evaluated last, if no matching allow rule exists.

    Advanced Thread Protection is set to "DROP" - could this be it?
    Possibly
  • 0 in reply to Scott_Klassen
    Hard to tell from your obfuscation, but are you trying to connect to your own External IP from an internal LAN client or is this just some client out on the internet connecting to a web server you host via DNAT?


    Sorry, I was not trying to be obscure - maybe it is because English is not my native language. I will try to be more specific below

    A user is trying to connect from WAN to the External IP (on of them) and this is then DNAT'ed to an internal webserver. In this case the RST packages are dropped and the user experience strange browser behaviour.

    Accessing the same server as the user did but from the same subnet as the server she was acccessing (thus not passing the firewall) with the users credentials works flawless.

    Not visible from firewall rules, but there is an explicit drop rule that is always evaluated last, if no matching allow rule exists.

    Ok - so there is a drop any-any hardcoded at the end?



    Regards, Lars.
  • 0
    I have seen some situations where "extra" RSTs are being sent after the session has already closed.  What you describe would be a symptom of this behavior.  Try to capture the traffic on the external interface and watch the TCP sessions to see if that is what is happening.  In the last example of this, it was an application bug that was fixed in a patch release.
  • +1
    These RST packets are being dropped because the connection tracker is no longer tracking the connection.  It has no idea where to send the packet and, were the server to receive the packet, it likely would have no idea what to do with the packet.

    My intuition (so possibly inaccurate) is telling me that the dropped RST packets are coincidental or are a result of the real problem.  Do you get any other hints from #1 in Rulz?  If there are no successful DNATs to the server, does the Host definition for the server violate #3?

    Cheers - Bob
  • 0
    Ok - so there is a drop any-any hardcoded at the end
    Yes sir Lars.