Numerous 'Could not associate packet to any connection.' messages in the firewall log

There seems to be an impulse to immediately dismiss posts about logging as due to new logging in v17 - this is folly.  The fact that the default logging config was made more verbose does not obviate the presence of any real issue.

With that in mind, the three reasons provided here coupled with the logs I and others are seeing suggest a potential issue with how the XG is processing and maintaining sessions.

deeptibhavsar said:

• In case appliance receives any packet, which does not have an already established connection. Hence no associated conntrack is found for that particular packet.
• The connection from the appliance has timed out, but client is still retrying by re-transmitting packets with old connection id.
• This invalid log reason, is not due to any error in appliance or configuration issue. Rather it occurs due to network packets received by appliance for which it has no related connection.

• What is the difference between the 1st and 3rd reasons?
• Reasons 1 & 3: Can you confirm that the source-IP should be from somewhere on the WAN side of the XG and nowhere else?
  • The reasoning here is that when a packet arrives at the LAN side, it either matches an existing session OR will be processed as a new session according to the rules setup for the XG's various subsystems.
  • Therefore, no packet arriving on the LAN side should ever generate the "Could not associate packet to any connection" log message.
• Reason #2: Can you confirm that the source-IP should be from somewhere on the LAN side of the XG and nowhere else?
  • The reasoning here is that clients are only on the LAN side so packets triggered by this reason must have arrived on the LAN side.
• Reasons 1 & 3: Why would connections from the client time out if the client still sees the session as active?
  • For example, with TCP - if the XG sees the session as inactive, then it will obviously drop packets related to the TCP session.  This will lead to both ends timing out the session in question.
  • Perhaps you are thinking these message are generated during the time where packets are dropped and the endpoints are still trying to determine the session state?  If so, then one would think we see similar log messages relating to both ends of the session and not just one end as we appear to observe now.
  • Either way, we still need to understand why the XG would see the session as inactive when the endpoints did not close the session.
• Reason #2: What is the "connection id" used by the clients in reason #2?

deeptibhavsar said:

Invalid traffic logging can be turned OFF, to avoid logging these packets frequently.

This could suggest a couple different things: (1) That the traffic being logged is invalid; OR (2) That the logging subsystem is not working properly so therefore, the logs are invalid and cannot be trusted.  Can you confirm which you mean?

Finally, in my specific case, I have hundreds of these messages all originating from IPs on the LAN side that all relate from validly configured Clientless Users.  These messages seem to  pop-up after I have been away from the client for some period of time.  I say this last piece becuase I am wondering if the XG is having some issues in maintaining session state and this then leads to the logs messages and issues being discussed herein.

 Thanks.

I just did a fresh install with RC1 so not much there but I did send you the information in the PM. Happy hunting!

Edit: Can you also check the webfilering log with red and green icons for allowed packets while you are logged in. More info here https://community.sophos.com/products/xg-firewall/sophos-xg-beta-programs/sfos-v170-beta/f/sfos-v170-beta-feedback/96852/v17-rc-1-log-viewer 

Hi,

Can we have your appliance access!

Regards,

Deepti

Thanks for the clarification. I know you can turn off invalid traffic logging and perhaps you should set that as off (default) but the log reason is incomplete. I don't mind the packet being logged as invalid, I want to know the reason why. 

No conntrack entry would be the obvious invalid packet but the others like time out FIN/RST packets should be marked as such. UTM9 also logs invalid packets if you turn on block invalid packets and is generally good practice to do so but nowhere near the numbers that XG generates. 

I can increase the timeout in XG to lower the FIN/RST logs since the timeouts are too aggressive but the invalid packets with no reason given are logged very frequently. Maybe the logging verbosity needs to be tuned down as I can't imagine my single computer behind my XG (beta) generating so many invalid packets. Additionally, its not the same packet being denied over and over. Its different IP addresses all the time and I have never seen that kind of volume of traffic blocked by any other firewall that I have tested. 

So much junk log isn't helpful for troubleshooting by the admin or support teams that will get calls about these logs. I know MR7 was logging the same packets, but too much logging is just as bad as no logging specially when the standard reply is that you can ignore those logs.

Hi,

Thank you for the feedback.

The logs 'Could not associate packet to any connection.', is generated in following case:

• In case appliance receives any packet, which does not have an already established connection. Hence no associated conntrack is found for that particular packet.
• The connection from the appliance has timed out, but client is still retrying by re-transmitting packets with old connection id.
• This invalid log reason, is not due to any error in appliance or configuration issue. Rather it occurs due to network packets received by appliance for which it has no related connection.

Invalid traffic logging can be turned OFF, to avoid logging these packets frequently.

Earlier this logging was disabled by default, which could be the reason of not noticing these logging.We have enabled "Invalid traffic" logging in SFOSv17 with factory default configuration.

Regards,

Deepti

Web filtering isn’t enabled in my setup.

I think the errors are related to the web components, e.g. http/s decryption AND web policies. You can try to disable these and check if the errors still occur.

Likewise, Didnt have IPS enabled, had the error message. Still have the message after IPS enabled too.

I don’t have IPS enabled, but still the errors show up.

Franc.

There are a lot of could not associate packet to any connection errors in MR7 also. I haven't tested MR8. Its logging related and they need to fix the verbosity along with the actual reason like FIN/RST or whatever the reason the packet was invalid.