Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 4 subscribers
  • Views 1629 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

UTM Blocks reply packet

Pete01


Hi All,

I have a strange behaviour in the UTM packet filter.
We have an incoming connection which we have allowed as usual with this rule.

FW Rule:
Src: 172.24.nnn.nnn/16
DST: 10.0.bbb.bbb/24
TCP: 443

Incoming connections work, but the reply from 10.0.bbb.bbb:443 seems be to a new connection, as without allowing the 10.0.bbb.bbb:443 > 172.nnn.nnn.nnn:50243 the UTM blocks the reply.


08:07:03.081547 IP 172.nnn.nnn.nnn.50243 > 10.0.bbb.bbb.443: Flags [.], ack 28151, win 255, length 0
08:07:03.082191 IP 172.nnn.nnn.nnn.50243 > 10.0.bbb.bbb.443: Flags [P.], seq 61065:61356, ack 28151, win 255, length 291
08:07:03.082239 IP 172.nnn.nnn.nnn.50243 > 10.0.bbb.bbb.5080: Flags [P.], seq 61356:61719, ack 28151, win 255, length 363
08:07:03.082255 IP 10.0.bbb.bbb.5080 > 172.nnn.nnn.nnn.50243: Flags [.], ack 61719, win 1452, length 0
08:07:03.082597 IP 10.0.bbb.bbb.5080 > 172.nnn.nnn.nnn.50243: Flags [P.], seq 28151:28408, ack 61719, win 1452, length 257
08:07:03.082653 IP 10.0.bbb.bbb.5080 > 172.nnn.nnn.nnn.50243: Flags [P.], seq 28408:28415, ack 61719, win 1452, length 7


    Default DROP    TCP         10.0.bbb.bbb    :    443
    →    172.nnn.nnn.nnn    :    50243
         [RST]    len=40    ttl=63    tos=0x00    srcmac=7c:cccccccccc    dstmac=00

    Default DROP    TCP         10.0.bbb.bbb    :    443
    →    172.nnn.nnn.nnn    :    50243
         [RST]    len=40    ttl=63    tos=0x00    srcmac=7c:cccccccc    dstmac=00




Any Hint what’s going on there?

Greetings



This thread was automatically locked due to age.
  • 0

    Hi  

    Would you please share the screenshot of the DNAT rule? or the Firewall rule you've configured?

    Regards

    Jaydeep

  • 0

    Do you see any problems with the connection?
    The dropped packet is a "RST" Packet. This means "TCP session reset".
    This packet often  is send some time after session is timed out ...  If server and client don't close the TCP session properly.
    Normally everything works ... with these packets within FW-log.


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • 0

    Hi Pummel,

    without a network diagram it's difficult, my guess asymmetric routing between the peers?

    bye Josef

    BERGMANN engineering & consulting GmbH, Wien/Austria

  • 0

    Hallo Pummel,

    Herzlich willkommen hier in der Community !

    (Sorry, my German-speaking brain isn't creating thoughts at the moment. [:(])

    Alone among the logs, the Firewall Live Log presents abbreviated information in a format easier to read quickly.  Usually, you can't troubleshoot without looking at the corresponding line from the full Firewall log file.  Please post one line corresponding to those above.  If you prefer, obfuscate IPs like 84.XX.YY.121, 10.X.Y.100, 192.168.X.200 and 172.2X.Y.51.  That lets us see immediately which IPs are local and which are identical.

    Unless you experience a true lack of response, you normally can ignore drops of RST packets.

    MfG - Bob (Bitte auf Deutsch weiterhin.)

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi All,

    sorry for the late reply.

    We have reviewed the rule sets again and have not found any issue.

    But we found some older threads where others had the same issues which were related to the connection tracking table.

     

    Next plan is a announced fail over to the standby node to check if we have the same issues there.

     

    But here are more details:

    These issues are related to a IPSec IKE v1 Net2Net VPN between two Networks.

    There is no NAT involved, the Tunnel has a "Automatic Packet Filter" set to active.

    Our Side is a UTM the other side is a Cisco.

     

    Our side where we have these issues >>>>>>>>>>>>>>>>>www>>>>>>>>>>>>>>>>>>>> opposite

    10.0.xxx.nnn/24>>>>Public IP>>>>>>>>>>>WWW>>>>>>>>>>>>>>Public IP>>>>>>>>172.xxx.nnn.nnn/16

     

    All connections will come from 172.xxx.nnn.nnn hosts and will arrive here in the Network 10.0.xxx.nnn/24.

     

    Many Greetings

    Ulrich

     

     

     

  • 0 in reply to Pete01

    Hi Ulrich,

    As Josef said, it's normal to see RST packet drops - it's just part of the "chattiness" between TCP configurations programmed by different people.  If you aren't experiencing problems, then you can just ignore those lines in the log.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Unfiltered HTML