Wrong Usercheck message for the wrong host/user!

[Rob_Bush]

Help!

Ever since upgrading to R80.10, I have been experiencing the most unusual issue.  In our SmartLog, I am getting entries shown for a source host/user that have the UserCheck block message of another source host/user.  It literally is as though it's two different log entries slammed together into one.  The easiest way to describe this is via the included screenshot.

I have opened up a ticket with Checkpoint and our local VAR but I am not getting any traction on this.  Hoping maybe the community here can help guide me in the right direction to resolving this?

In the attached log entry, please note the following:

[I've blocked out identifying information on the screenshot. Interesting information is highlighted in red.]

1)  The source IP address as seen by the firewall rule is 10.26.1.75 with a source user of "Peter".

2)  The UserCheck message as seen by the application rule is for a source IP of 10.63.72.57 with a source user of "Tammi".

Literally, this log entry is TOTALLY incorrect.  The user "Peter" does not receive ANY type of UserCheck block message at all.  They indicate no problems at all.  "Tammi" is receiving a block message.

It is as though the R80.10 environment has decided to take two completely different log entries, that are completely unrelated, and slam them together into one in-correct log entry.  This is happening ALL over my logs.  I can hardly even perform a search on a username any more because I get bogus log entries that I have to constantly filter out.

Anyone have any idea why this would be happening?  Also, this is being logged on our main SmartLog server that we use for searching logs AS WELL as the Mgr and HA-Mgr server.  This tells me it is not some type of corrupted database on our primary SmartLog server because there is no way that three separate logging servers would ALL log the data 100% identical if one of the servers had a corrupted database.

[PhoneBoy]

This sounds like a session consolidation issue of some sort.

If you can send the Check Point SR to me in a direct message, I'll see what's going on with it.

[Rob_Bush]

Thanks Dameon.  The original ticket is a bit goofy as the VAR didn't document the issue correctly.  We ended up cancelling the ticket with CP and the VAR was suppose to open up a new one with JUST this issue so that CP didn't try to work on a number of unrelated issues at the same time.  Sadly, that hasn't been done yet and I'm asking why.  The old ticket # was 1-9784215444