'Action: Allow' Blocks all Traffic, have to use 'Trust'

[ABaker94985]

We had an ASA fail but had a spare ASA 5508-X running 6.6.1 FTD on the shelf to use as a replacement. The firewall is able to hit the Smart License server, but we don't have Threat, Malware, or URL licenses available for this ASA, and none of these licenses are enabled. Snort blocked all connections that had 'Allow' as action in the ACP, though traffic started to flow when this was changed to 'Trust'. I can kind of understand this behavior with the licenses not being applied, but we've not encountered this at other remote locations. Does this behavior seem odd?

[Marius Gunnerud · Accepted solution]

Do you have IPS configured for the rules? or perhaps any other configuration that would send traffic to Snort?  If you have no licenses configured and traffic gets sent to Snort then it would make sense that it will get dropped even though Allow is configured.  Trust should not send traffic to Snort, but there are always exceptions to this rule.  If I were you, I would place these rules into the pre-filter policy, that is if this device will not have any licenses applied to it before an actual replacement device is put into production.

[Mohammed al Baqari · Accepted solution]

Hi,

Just adding to @Marius Gunnerud, if you don't have the license and you have
rules configured with snort features (TMC), the deployment will fail. You
can't deploy rules with features that have no license. So your case seems
to be odd and I don't think its a license issue.

But it seems to be that snort status is down which is causing this. Can you
go to expert mode and run pmtool status | grep snort. This will give more
indication.

**** please remember to rate useful posts