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
    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.
Reply
  • 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.
Children