FMC cannot connect AMP cloud

[Nashja]

I used FMC on VMWare version 6.2.3 (build 83) to control FTD 2110.  I have the Malware license and installed to FMC already.

I tried to turn on AMP for network but no luck, it could not connect to any Cloud (US, EU, APJC).

I already tried to troubleshooting as the following method;

- Changed DNS then connected to the internet that could surf internet normally. It can resolve the hostname "api.amp.sourcefire.com"

- Deleted and Changed AMP Cloud to US,EU and APJC but it could not connect to any Cloud.

- Allowed IP Address of FMC and FTD  to every Firewall rules to any any for both inbound and outbound that can connect to the internet normally.

Please help.

Thank you.

Nash.

[balaji.bandi]

SSH to FMC and get in to superuser mode

try below see if you have access to cloud ?

root@FMC62:/Volume/home/admin# telnet api.amp.sourcefire.com 443
Trying 52.73.183.156...
Connected to api.amp.sourcefire.com.
Escape character is '^]'.

[Nashja]

Hi BB,

Both of FMC & FTD can access api.amp.sourcefire.com

admin@FTD:~$ telnet api.amp.sourcefire.com 443
Trying 52.73.183.156...
Connected to api.amp.sourcefire.com.
Escape character is '^]'.

admin@FMC:~$ telnet api.amp.sourcefire.com 443
Trying 50.17.105.89...
Connected to api.amp.sourcefire.com.
Escape character is '^]'.

Do you have any idea?

Thank you.

Nash

[balaji.bandi]

i do not see any reason, may be reboot once and test it.

[djsample]

Not sure if this is still an issue for anyone but I thought I'd share what happened to my FMC after an upgrade with regard to AMP not connecting to the Cloud.

After an upgrade, in this case it was to 6.4.0, once complete I received the AMP Cannot Connect to Cloud issue.  I then took it to the interim update, the most recent at the time of this writing being 6.4.0.5 and the error still existed.  

After a little investigation I noticed it was the SSL Policy preventing this.  I created a rule to not encrypt anything from the FMC and that has resolved the issue.  A better fix may be to get the self signed root certificate on the appliance (although it is using itself as a CA, so why it does not trust its own CA is a little strange).  If I get more time I may investigate this further but just for clarity it is an issue with the FMC not the sensors.  

I hope this helps some of you!

[Nashja]

Hi djsample,

Thank you for the information.

How can you create "rule to not encrypt anything from the FMC" ?

Thank you.

Nash

[djsample]

Nash,

It is quite simple. 

Once logged on, if you have more than one core policy or SSL Policy you may want to verify what one is in use.  To do so:

Policies -- Access Control -- Access Control (yes it is named twice)

Click the edit icon, and when in the policy verify what SSL Policy is in place

Once you have made a note of this you can continue on to edit the correct SSL Policy.

Policies -- Access Control --SSL

Click edit on the correct SSL policy if you have more than one.  Note that it takes a little while to open the SSL Policy.

You need to create a rule that is above the rules that you have set for 'Decrypt and Resign' and the rule that you create must have the action 'Do Not Decrypt' and must come from the source IP of your FMC.  

Add Rule -- Name Your Rule -- Set Action as 'Do not Decrypt' ---Set the Source and Destination zones if you wish

Then select Networks and add the host IP of your FMC then set that as the Source.

Click Add

When out of the dialogue box click save and then deploy to your device.

You will most likely find that this will not immediately fix the issue as you will have to go to health monitor to run the service again.  I think this is under System -- Health -- Monitor and then you click 'run' if I recall. 

I hope this helps you.

[Herald Sison]

thanks for this sir but at first the error went away but after a few hours the same error came back again. For me this error pops out just right after i upgraded my Snort version from version 2 to version 3.

[djsample]

Are you using an FTD appliance as you may have two options, firstly you could look at creating a Fast Path rule for anything from the FMC, this will affectively bypass any higher level protocol inspection (think of it like a traditional ASA).  As you've stated after a Snort upgrade I therefore assume you're using version 7.x it could be a IPS policy getting in your way.  That brings me on to your second option, look at the logs on the FMC and filter from your management IP and see what is getting blocked.  Filter the logs to show just blocked traffic and you should be able to see what is getting blocked and apply a policy to rectify.

I hope this makes sense and helps in some way.  Please also ensure what you do fits with your organisations security policy. 

[Herald Sison]

HI Sir,

I have updated my Snort version 2 to the latest Snort version 3 last weekend and right after the upgrade i encountered errors below: 1) AMP error with "cannot connect to the cloud" pops out

2) downloading updates got error cannot connect to the cisco site

3) synchronizing the licenses and cannot connect to the smart software manager

4) some users are blocked from the internet and even accessing google.com was blocked

so after i encountered these problems above i have decided to revert my snort version back to Snort 2 and i am running currently Snort 2 right now.

so my questions are below:

1) is downloading updates from cisco site is different from synchronizing the licenses?

2) what are the things i should do before upgrading my Snort 2 to version 3?

3) what else do i need to do after upgrading my Snort to version 3?

4) I have decided to upgrade my Snort version because i encountered high snort memory usage and hoping that upgrading to Snort 3 would help the memory usage problem.

here are the details below: FTD 7.0.4 FMC1 7.0.4 FMC2 7.0.4

[Marvin Rhoads]

Did you verify the nslookup works from the FMC cli?

If so, have you checked the httpsd_error_log as described in this technote:

https://www.cisco.com/c/en/us/support/docs/security/sourcefire-fireamp-private-cloud-virtual-appliance/118290-technote-fireamp-00.html

?

[djsample]

Yes,



All of that was checked and verified. The root cause was resigning of SSL that is why the bypass for the FMC works.

[Marvin Rhoads]

Ah yes - AMP cloud does not allow man-in-the-middle certificate re-signing