Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 17 replies
  • Subscribers 40 subscribers
  • Views 9564 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

Help with "Invalid Traffic" in logs

Alan Spark

Hi,

We have an XG 135 running SFOS 18.5.3 MR-3-Build408. There are two gateways, a primary and backup.

One of our users is encountering an intermittent timeout on a specific website when performing a specific action. I have been checking our firewall logs as well as our internal DNS logs but have yet to track it down.

However, there is one thing that caught my eye. Around the time of the failures I'm seeing 5 or 6 sequential entries in the log titled "Invalid Traffic" with the message being "Invalid Packet". These seem to be going to Google or Microsoft servers. This is likely coincidental as it occurs on other PCs too but I would like to rule it out if possible.

In general I'm seeing a mixture of "Invalid Packet" and "Could not associate packet to any connection." when I filter all traffic by "Log comp is Invalid traffic".

I would appreciate any comments.

Thanks,

Alan



This thread was automatically locked due to age.
  • 0 in reply to Alan Spark

    I am quite sure this is not an issue what so ever. It is simply a closing connection. So those packets are duplicated send and being logged as closing packets. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Ok, but I'm not so sure about the last scenario that I described as it definitely coincides with the errors that are being reported. Why are they being denied against "Default Workplace Policy"? Can we identify IPS policy 3?

  • 0 in reply to Alan Spark

    It is a destroyed connection. So the connection is getting closed and deleted. 

    fwid=5 Show us a screenshot of this FW Rule. But likely you are chasing something, which is not important. 

    When conntrack is closing/Destroying the connection, it is because somebody (Client or Server) is sending a RST packet. This means, the client or the server (likely the client in this scenario) is closing the connection. 

    Those packets are often times send multiple times. Therefore logged as invalid traffic. There is no issue in this process what so ever. Your issue is a application issue. Something the app is causing and is closing the connection. 

    There is a TCP Handshake. Which means the connection on a TCP Level is there. But the other levels (TLS for example) is closing the connection.

    You see this in this: packets=15 bytes=1698 

    15 Packets are send between those clients. The firewall is not simply closing the connection at this point. Instead the client or server is closing the connection for whatever reason after the talked to each other (in fact 15 packets, which could be TLS handshake or something in the application). 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Thanks for the comments, here is rule 5 as requested.

    I also took a screenshot of one of the examples that I've been examining in the firewall log where I have highlighted a Google IP (142.250.200.40) that is blocked several times between 16:59:44 and 16:59:48. The same URL is allowed but around 10 seconds later at 16:59:59 and this could coincide with the time that the user was eventually successful after multiple tries. It seems a bit long for an automatic retry.

  • 0 in reply to Alan Spark

    Just to be sure. What is the issue, you see on a client? What are your user say? 

    Because this is a perfectly fine behavior. If the app is closed, it will send basically more packets. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    The user is accessing a particular website and when they submit a form it sometimes times out but only on our internal network, i.e. going through the Sophos. We have confirmed that the application in question is using a variety of cloud services and this is why we are focussing on these errors. It is quite intermittent and eventually works after a refresh.

    I must be misinterpreting the logs if this is normal as the only success I see for this IP is 11 seconds after the last failure so I was assuming that they are different transactions.

  • 0 in reply to Alan Spark

    Try to start to check the Developer tools of the browser to get the actual data resets. Maybe you see the reason there. 

    __________________________________________________________________________________________________________________

Unfiltered HTML