Downloads Failed

Usage and Config
1

Hello Guys. Looking for help and ideas.

I’ve been working well with HCL support (even Level 3) and no solution yet. Downloads are not getting to the external clients, by external I am meaning clients in the internet.

Here it is:

The setup is:
1 Root Server - Reachable internally, and externally from internet with an alias.
2 Top Level Relays. - Reachable only internally inside corporate network. (It’s actually 3 but I can say 2 because one of those three handle just a very few clients).
1 DMZ Relay - Reachable externally only (internet) reporting to the Top-Level Relays to support external(internet) clients along with the Root Server.

DMZ Relay and Root Server (by its alias) are configured as Fail Over Relays in all clients.

I discovered that patching or download actions are getting to the clients, but the issue seems to be for the external ones, those in the internet reporting to the DMZ relay or Root Server. In these clients when I send a patch, the file intended to be downloaded just don’t get to the clients, I can see the following in the client log:

DownloadsAvailable: false (action id 12345)

I have checked the file(s) to be downloaded in corresponding configured relays for the client(s) in the BES Relay\wwwrootbes\bfmirror\downloads\sha1 directory and I can see the file(s) there but the client log still throws the DownloadsAvailable: false

As soon as I connect the testing clients to the corporate network (VPN) then the downloads start and finished and ultimately the patch work, of course. This is not normal as external clients should and must be able to download files as they were before. I think that when connect to the VPN client do a relay selection again, but here is where I got lost it, downloads should be working that’s why we have the DMZ / internet facing relays available.

From the clients I can reach the relays checking with https://relay_name:52311/rd. I reach the corresponding, I mean, when not connected to corporate network I can reach the DMZ relay and the alias of the Root Server. When internally I can reach the Top Level Relays and the Root Server.

I ask please your help and or ideas to find the solution.
Thanks in advance.

2

DownloadsAvailable: false just means that the Client did not received yet a message from the Relay that the Download is available on the Relay. the message type is UDP - UDP “new information” message - https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0073040

To make sure that this is only a UDP issue - if you are restarting the BES Client on that machine do you receive a message that the Download is available?

If so, you will need to set Command Polling on those External Clients (You can set it once or you can think of a way, to set it when they are on network which don’t allow UDP and on other networks, unset it)- https://help.hcltechsw.com/bigfix/10.0/platform/Platform/Config/r_client_set.html?hl=list%2Csettings%2Cdetailed%2Cdescriptions#r_client_set__cnot

3

Hi @orbiton

No, if I restart the client the situation is the same, action waiting for the download but with the DownloadsAvailable: false. It’s only when I connect the client to the company network when the download works.
Actually, the Waiting for Downloads Action status stay there hours and eventually pass to status Download Failed.

4

Closing this. It was network/firewall blocks.
Thanks

1 Like
5

What ports or protocol were being blocked?

I have exactly the same problem. I can send actions that do not require a download and they complete, but the download fails when there is a download.

How can I prove that it is firewall blockage? We used to have Qradar which enabled me to prove that a firewall was the issue. Now the standard response from the network group is that it is not the firewall.

6

Hi. Didn’t see your comment before. The blocked content was based on files, the network tool was flagging files as security threats.

How to prove, in my case I always have the network engineer and myself capturing the network while I’m testing, in this case sending some packages or patches. There’s almost always something blocking in my experience, but they said, no we didn’t do anything, and well that’s another IT adventures story.