Brightcloud connection error

[jprice2]

I have a PA-500 that is receiving the error of:

opaque: Failed to connect to Brightcloud update server service.brightcloud.com, initiated by 192.168.75.30

eventid: connection-failure

There seems to be no connectivity issues to URLs for the users. Just this sys log being generated. The updates are set to every morning at 3:00am and work perfectly fine. It's just during production hours that this message is received. I think it is due to limits in the device. When I looked at the traffic on the device there is no traffic dropped when the log occurs. When I looked at all the KBs they all talk about errors that occur in not getting the update at all. Does anyone know how I can set up the firewall to no longer receive this message, or should I just clear the URL Cache?

Thanks

[HULK]

Hello Jprices,

I'd like to suggest to check with BrightCloud about the issue and need to verify if an outage at BrightCloud today had. Could you please run below mentioned command while trying to download BrightCloud database.

> tail follow yes mp-log pan_bc_download.log

Also try to verify the reachability to the BrightCLoud server from PAN firewall.

[jprice2]

Thanks Hulk,

Unfortunately I did that and it showed the I have the most up to date BC download. I still see the issue being presented in the system logs and I can't notice a pattern in the traffic logs. Do you know how I can contact Brightcloud to see if they know about possible connectivity issues during production with PA-500's.

[sdolen]

I'm experiencing the same issue with my PA-2050s.  I recently upgraded them to 5.0.11 last week so I'm not sure if it's a coincidence or not.

[HULK]

Recently Brightcloud made a change in their  DNS system , now we get only one best IP for service.brightcloud.com.

Also the Error: Failed to connect to 'service.brightcloud.com' => The cause is unknown. We need packet capture.

[CarloGrossman]

I get this message frequently too.  I think it happens every day, yet all of the signatures and databases are up to date when I look at it.

[jprice2]

I am now receiving the same message with a different PA-500. Does anyone know if Palo Alto is having issues with lower models due to URL cache space?

[dyang]

Hi everyone,

For those of you that are receiving this error, can you please verify that you're only seeing this error in the logs but are not experiencing any issues with the daily database update or any other connectivity errors?  During the time that you see this error, are any of you seeing category "not-resolved" in the URL filtering logs?

Thanks,

Doris

[jprice2]

Doris,

Sorry I meant to mention. The update that is scheduled is working fine, without any issues. It is just during the day that I get this error messages. I have nothing in the URL filtering for "not-resolved".

Thanks,

Joseph

[CarloGrossman]

jprice2 wrote:

Doris,

Sorry I meant to mention. The update that is scheduled is working fine, without any issues. It is just during the day that I get this error messages. I have nothing in the URL filtering for "not-resolved".

Thanks,
Joseph

Same here.

[Jack_Howells]

Anyone have any updates to this? What was done to resolve this?

[Roby_Sreejith]

In ms.log can you see he report generatiobn or all other updates like wildfire,antivirus happening at same time which you scheduled for bright cloud. I suggest the scheduling of updates should not happen on same hour. make an interval of 10 to 15 min.

[Jack_Howells]

So I have an update for this post that has resolved my issue.

Running the following command showed a successful connection to the Brightcloud server:

debug device-server test url-update-server

Tailing the pan_bc_download.log saw successful connections also as the Brightcloud was able to update to the latest version.

However, running the command below showed a connection error and a lot of unknown requests to the Brightcloud.

debug device-server bc-url-db show-stats

I found a document that's related which solved the issue, which is below, however it asked me to carry out a reboot which may have resolved it also. The issue originated from switching the roles of the active/passive cluster. The ex-passive is the now active and that's when the issue started. Either way, the document below helped me find that there was a connection issue even though other commands suggested otherwise.

https://live.paloaltonetworks.com/t5/Management-Articles/Large-Amounts-of-Unknown-URL-Categories-in-...

Cheers

Jack