Threat data updates on devices cisco cloud configuration - failure

[haytham elsamadony]

Hi,

I have a 4 FTD FW ( 2 FP2130 & 2 FP 2110 ) managed by FMC v 6.5.0 

I  have 4 critical health monitor notification ( threat data updates on devices cisco cloud configuration - failure ) at each FW

I don`t know what the meaning of this notification and how I can fix

but every thing is good at FTD, I can add new rules and deploy without any problem, meaning this notification has no affect at my work but at the same time it`s critical … I can`t understand

So, any one can help me in it

Thanks

[manabans]

Beginning in Firepower release 6.4, you can configure your Firepower system to send supported events directly to the Cisco cloud from Firepower Threat Defense (FTD) devices.

Reference: https://www.cisco.com/c/en/us/td/docs/security/firepower/integrations/CTR/Firepower_and_Cisco_Threat_Response_Integration_Guide/send_events_to_the_cloud_directly.html

In case you are not using this feature, it can be disabled on FMC UI - System > Integration > Cloud Services > Cisco Cloud

[brian.emil.harris]

Disabling the feature doesn't resolve the underlying cause of the error - I don't want to disable this feature, I want my device suffering this error to not have the error.

Any suggestions on how to resolve?

This bug report:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvs82369/?rfs=iqvred

Describes manually editing a file string to match a string from another file, however, on my affected system, they already match.

This error is new as of a couple days ago on the affected system, but it specifically was just upgraded from 6.4.0.7 to 6.6.1 last week.  

I'd like to resolve before I upgrade more devices to 6.6.1

[dkio]

Did you get this resolved?  I just noticed one of my units started this recently as well.  And just like yours,  the two strings match and arn't blank.

I rebooted and all and it still shows as an issue.

[dkio]

I just noticed that after I logged in to the Cisco Cloud configuration - Secure X site - the device with the issue seemed to have gotten Unregistered.  The other devices that are good are still registered.

So I am currently seeing what is the safe way of re-registering that unregistered device.

[dkio]

For me it seems my Cisco Security Services Proxy v1 was shutdown. 

I am not sure if that caused a sync error or a time out.  Interesting only one of 4 devices showed unregistered if that was the issue.  I believe the VM has been off for a while.

Though the website did record messages from the internal devices today.  But the unregistered device got automatically re-registered after the VM was turned on and it's modules loaded.

All indicators on FMC and Secure-X are all green now.

[brian.emil.harris]

Have not resolved as of yet.  I have a WebEx scheduled with TAC tomorrow morning, as they haven't been able to find a solution over our email conversations.

I'm not using Secure-X or Cisco Security Services Proxy.

Sounds like you're using FTD virtual units?  Mine are physical appliances.

[dkio]

My FTD's are physical appliances.  The FTC is virtual ( I was about to vmotion it and noticed the error and wanted to fix it before I add to the confusion ).

Though if I am not mistaken the Cisco Cloud features if turned on is communicating with the Secure-X ( it is apart of the Cisco Cloud family) and since you are using 6.6.1, I believe the FTC and FTD's can communicate directly to the web without the CSSP in certain circumstances.  

So it could be a similar issue, just that it is communicating directly, check the Cisco Cloud status just for giggles.  Maybe you should turn off the Cisco Cloud feature for now if you aren't using it ( one less complexity for now ), and turn it on when you are going to use it since tokens expire and all and if you aren't maintaining it, it will fail at some point. ( I'm considering to turn it off if I find no value in it, one less complexity )

For me it is interesting the threat data updates were linked to my devices being registered to the cloud ( I guess licensing verification is tied in there some how ).

Anyway good luck tomorrow!

[FNet]

Hi.

Did you ever get a resolution to this?  I know its been a year but ... would appreciate if you recall root cause (if you ever got one). 

Thanks.

[Marvin Rhoads]

I've seen this intermittently on some deployments. It usually clears up by itself. The best fix is to engage TAC to investigate if it persists.

However, some people have reported success with the following work around:

Increase the 'IPREP_CONN_TIMEOUT' in /etc/sf/cloudagent.conf from 5 to 50 and then restart CloudAgent process. See the steps below:

expert
$ sudo su
# vi /etc/sf/cloudagent.conf
press "i" to enter insert mode
change the IPREP_CONN_TIMEOUT value from "5" to "50"
press "ESC" to go back to command mode and type :wq to save the file

to restart CloudAgent process
# pmtool restartbyid CloudAgent

[johnjpalu]

Edit: Mistakenly replied to the wrong thread.

[ida71]

I had this issue & working with TAC, turns out that an undocumented feature of the v7.1 upgrade is re-registration with Cisco Cloud.

I had a fudged access-list on my management interface restricting connectivity to my FMC & Management hosts, due to it being connected to the internet. Unregistered, it appeared to do strange things, with some VPN's being down etc. This caused traffic disruption which led to a TAC call where we worked out that the system uses its Physical Management interface to communicate with Cisco Cloud !

Just stupid, not having an actual functional ACL capability on the management interface to restrict access to only what's required. Or use the Outside interface to communicate with Cisco !

[ida71]

You can use the " configure ssh-access-list " with a comma separated list as in 1.1.1.1/32, 2.2.2.2./32, etc command to control SSH access, this is a standard Linux type restriction. There is also a HTTP access list option, but that does NOT work for FMC managed FTD's.

[imdoody]

So we had a problem like this, took a couple TAC engineers, but it ended up being a routing issue from the mgmt interface of the FTD (managed by FMC, Same network so mgmt worked no prob).
Hopefully this helps everyone. Not sure how the Management interface default route was never configured. But you can't do it in the Web GUI as far as I know.
I also did a ASA to FTD migration through the FMC. So maybe that was part of the issue.

SSH TO FTD

> expert

! show routing table in linux CLI
! Obviously 169.254.x.x would be a bad default gateway
admin@FIREWALL:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 169.254.1.1 0.0.0.0 UG 0 0 0 tap_nlp
10.10.228.0 0.0.0.0 255.255.255.0 U 0 0 0 manageme nt0
127.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
127.128.254.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.252.0.0 0.0.0.0 255.255.0.0 U 0 0 0 ctl_ha_t ap_nlp
169.253.0.0 0.0.0.0 255.255.0.0 U 0 0 0 ccl_ha_t ap_nlp
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun1
169.254.1.0 0.0.0.0 255.255.255.248 U 0 0 0 tap_nlp

admin@FIREWALL:~$ exit

> configure network ipv4 manual 10.10.228.100 255.255.255.0 10.10.228.1

>expert

admin@FWINTERNET1B:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.10.228.1 0.0.0.0 UG 0 0 0 tap_nlp
10.19.228.0 0.0.0.0 255.255.255.0 U 0 0 0 manageme nt0
127.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
127.128.254.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.252.0.0 0.0.0.0 255.255.0.0 U 0 0 0 ctl_ha_t ap_nlp
169.253.0.0 0.0.0.0 255.255.0.0 U 0 0 0 ccl_ha_t ap_nlp
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun1
169.254.1.0 0.0.0.0 255.255.255.248 U 0 0 0 tap_nlp

after about 15-20 minutes the FTD Communication to Cisco Cloud error resolved.

[imdoody]

On a side note, this was with the help of Cisco TAC.
Thank you Cisco TAC Engineers!