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 11551 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.
Parents
  • 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.
Reply
  • 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.
Children
No Data