FMC connectivity log shows blank action and reason columns

[tato386]

I am seeing quite a large amount of connectivity events in the FMC with blank/empty fields for action and reason.  What does this mean?  

TIA,

[Marvin Rhoads]

Was this working previously? What version is your FMC?

Can you check Analysis > Unified Events (assuming you are at 7.2+) and see what it shows?

[tato386]

The unified events screen seems consistent with connectivity log.  Most events look normal with a value for action and reason but there seems to be quite a few that are blank for both.  I've attached more examples

[Marvin Rhoads]

That is certainly odd and not what we would expect. What version is your FMC?

I would suggest trying to simulate one of the observed connection events with packet-tracer and seeing what the verdict is there.

[tato386]

@Marvin Rhoads do you know if it's possible to search for null or blank fields in the connectivity logs?  I tried null, $null, {null} but none seem to work.

[Marvin Rhoads]

In Unified Events, try !N/A. That seems to work for me in FMC 7.6. (That same syntax does not work in Analysis of Connection Events.)

You could also exclude all of the other actions since there are only 4-5 possible ones (Allow, Block, Trust, Monitor, Fastpath off the top of my head)

[Jonatan Jonasson]

Are you logging only at the end of a connection, or both at the start and end, for the access-rule that's related to this traffic?
And when you're viewing the logs, are these the latest logs or are you viewing events back in time?

The reason I'm asking, I'm wondering if you could be hitting a scenario where initial packets have been allowed through based on an application allow rule, but not enough packets have been transmitted for the firewall to determine the application, and therefore determine if the session should be allowed or blocked, and if you're viewing in real time the session hasn't timed out yet. (Schrodinger's session?)

[tato386]

I noticed that the events with no action did not have data in URL column either.  I thought this odd since these events where being successfully decrypted with resign and this requires a FQDN for cert name.

I added a rule to not decrypt traffic to one particular destination IP that showed up quite a bit and the results are posted below.  As soon as decrypt was off both the action and URL began to show data.  I guess we're looking at a bug.

[MHM Cisco World]

same as what I think 
cisco make good table when you use log in end or start of connection 

[tato386]

TAC pointed out this bug https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvs50538 but it only references older software versions and I am at v7.4.2

[MHM Cisco World]

you use SSL policy so you need to change Log to be end of connection 
log can not know the IP and detail of packet if it encrypt 

so FTD need to decrypt the packet then list the info 

MHM

[tato386]

@MHM Cisco World yes, all my polices use "log at end" but this does not prevent the issue from occuring

[MHM Cisco World]

OK 

the default action of ssl policy is set with log ?

MHM

[tato386]

@MHM Cisco World , the events in question were not matching the default action, they were clearly matching a decrypt-resign rule that has always been enabled for log at end.  Nevertheless, I checked default action and enabled log at end.  I don't expect this to make a difference but who knows, stranger things have happened.  I will post back if this makes any difference.

[ckleopa]

Yes I believe this is something that could be caused by a Connection that has ended prior to getting fully evaluated by the firewall logic in the Access Control Rules. For example, if you are doing a Decrypt/Resign and the client ended the connection due to an invalid SSL certificate.

Feel free to open a TAC case around this for some more information around the screenshot/logs you have presented here.