Hey everyone, hoping to tap into the collective wisdom here. We recently updated our perimeter firewall rules (moving to a more granular, zero-trust-ish model), and now a subset of our GravityZone agents are showing as "Not Communicating" in the console. The policies are applied, but the agents are offline from GravityZone's perspective.
I've been digging into logs, and it feels like a classic endpoint-to-service communication breakdown, but the specifics are tricky. From the agent side (`C:Program FilesBitdefenderBitdefender Endpoint Security ToolsLogs`), I'm seeing connection timeouts. Our network team insists the required domains/IPs are whitelisted.
Here's what we've verified is allowed, based on Bitdefender's documentation:
* `cloud.gravityzone.bitdefender.com`
* The main service IP ranges they publish
* Ports 443 (HTTPS) and 7074 (for some older comms?)
My main question is about the *quality* of that connection. Has anyone else hit this after a firewall change, even with the "official" allow list? Specifically:
* Are there any **specific API endpoints** or subdomains the agents call that are critical and might be missing from the high-level domain list? Something like `api.comm.gravityzone.bitdefender.com` or similar?
* Could it be related to **certificate pinning** or a specific TLS handshake that a newer firewall might be inspecting/interrupting?
* Any known issues with agents failing gracefully when they get a `403` or a timeout versus a clean `200` from the service?
I'm thinking of setting up a trace on one of the affected systems to see the exact outbound call failure, but if someone's already done the legwork, I'd be grateful! It's frustrating when the core security tool loses its comms channel.
Thanks in advance for any pointers or shared experiences!
ā chloe
Webhooks or bust.
Your network team's allow list is probably missing the dynamic update domains. The agents don't just talk to the main cloud domain.
Check for these subdomains:
* `update.bitdefender.com`
* `upgrade.bitdefender.com`
* `glcdn.bitdefender.com`
Also, the IP ranges they publish can change. You need to allow the entire published CIDR blocks, not just a few IPs from an old list. Port 7074 is for legacy agent communication; if you have any older agents, they'll fail without it.
Run a packet capture on an affected endpoint during a check-in window. Filter for `cloud.gravityzone.bitdefender.com` and look for RST packets or timeouts. That'll show you exactly what's being blocked.
Yep. The main domain alone won't cut it. You're likely missing the critical subdomains for the actual API endpoints.
When the agent checks in, it resolves something like `eps-{region}.cloud.gravityzone.bitdefender.com`. That's the real endpoint. If your firewall only allows the parent domain, that specific hostname can get dropped.
Packet capture is your friend here. Filter for DNS lookups to `cloud.gravityzone.bitdefender.com` first, then follow the TCP stream to the resolved subdomain. That's your missing allow rule.