Configure firewall access for the agent
Allow outbound connections for the agent, installer, checks, software deployment and automations.
This reference lists the outbound destinations of the octoja agent: for the platform connection, the installer, monitoring checks, software deployment and automations that run on the device. Always allow the core destinations, plus the destinations in the sections for the features you use.
Integrations and checks that run on the octoja platform, such as Acronis Cyber Protect Cloud or Lywand Vulnerabilities, connect from the octoja platform. They need no additional outbound rule on the agent device. A firewall in front of the integration API must still allow octoja — see IP addresses and firewall rules.
Hostnames, not IP addresses: Most destinations sit behind CDNs with changing IP addresses. Create the entries as FQDN objects and ensure DNS resolution through your configured resolver. Entries starting with *. are wildcards for all subdomains, including multiple levels (for example ye1.c.lencr.org for *.lencr.org). If your firewall does not support wildcards or only matches one level, allow the individual subdomains from your firewall log.
Core destinations
Every managed device needs these destinations. All connections originate from the device; no inbound internet port forwarding is required.
cdn.octoja.com
repo.octoja.com
*.lencr.org
Add the hostname of your octoja instance to the list, for example your-instance.octoja.cloud. Custom check repositories also require their configured repository and download destinations.
Agent installation
Windows
Windows Quick Install downloads missing runtime prerequisites. All destinations use HTTPS on TCP 443.
aka.ms
download.visualstudio.microsoft.com
go.microsoft.com
download.microsoft.com
Linux
If libicu or jq is missing, the Linux installer installs it with apt-get, dnf or yum. The device must therefore reach its configured package sources, over HTTP (TCP 80) or HTTPS (TCP 443) depending on the source. Apt software deployment and Linux update scans and installations later use the same package sources. The default Debian and Ubuntu sources are:
deb.debian.org
security.debian.org
archive.ubuntu.com
security.ubuntu.com
ports.ubuntu.com
Only ARM devices running Ubuntu need ports.ubuntu.com. If the device uses its own mirrors or another distribution, allow the hosts from /etc/apt/sources.list, /etc/apt/sources.list.d/ or /etc/yum.repos.d/ instead.
Software deployment and updates
Package managers load metadata from fixed hosts, but often download the actual installers directly from the software vendor. The following lists cover the fixed hosts. If the firewall still blocks an installation, take the vendor host from the firewall log and add it.
WinGet
cdn.winget.microsoft.com
www.powershellgallery.com
cdn.powershellgallery.com
cdn.oneget.org
go.microsoft.com
aka.ms
api.github.com
github.com
raw.githubusercontent.com
objects.githubusercontent.com
release-assets.githubusercontent.com
Chocolatey
If Chocolatey is missing, octoja installs it through WinGet or through community.chocolatey.org/install.ps1. Packages from the community repository then download their installers from the respective vendor.
community.chocolatey.org
packages.chocolatey.org
Homebrew (macOS)
If Homebrew is missing, octoja first installs Apple's Command Line Tools and then clones Homebrew from GitHub. Casks download their installers from the respective vendor.
github.com
raw.githubusercontent.com
formulae.brew.sh
ghcr.io
pkg-containers.githubusercontent.com
swscan.apple.com
swcdn.apple.com
swdist.apple.com
swdownload.apple.com
Custom software packages
The agent obtains custom packages through your octoja instance and installs them with Chocolatey. If Chocolatey is missing, the device also needs the destinations from the Chocolatey section. The agent downloads the uploaded installer file itself through a time-limited link from octoja's object storage.
nbg1.your-objectstorage.com
Operating system updates
Update scans and installations use the operating system's update services. The scan can already run during inventory.
Windows Update (TCP 80 and 443):
*.update.microsoft.com
*.windowsupdate.com
*.delivery.mp.microsoft.com
*.prod.do.dsp.mp.microsoft.com
emdl.ws.microsoft.com
tsfe.trafficshaping.dsp.mp.microsoft.com
macOS software updates (TCP 443, partly TCP 80):
swscan.apple.com
swcdn.apple.com
swdist.apple.com
swdownload.apple.com
updates.cdn-apple.com
gdmf.apple.com
mesu.apple.com
xp.apple.com
For complete and current vendor requirements, see Microsoft on Windows Update, Apple on enterprise networks, PowerShell Gallery network endpoints and Chocolatey security.
Automations
These automation actions and templates download files directly on the device or connect from it.
agent.lywand.com
cloudgz.gravityzone.bitdefender.com
cloud.gravityzone.bitdefender.com
0.pool.ntp.org
1.pool.ntp.org
clients2.google.com
clients2.googleusercontent.com
edge.microsoft.com
msedgeextensions.f.tlu.dl.delivery.mp.microsoft.com
addons.mozilla.org
versioncheck.addons.mozilla.org
versioncheck-bg.addons.mozilla.org
The Bitdefender installer's further downloads and the ongoing communication of the installed Lywand and Bitdefender agents need their own rules for the vendor's cloud. You can find them in each vendor's documentation. See also Ensure Lywand agent and Set up the Bitdefender integration.
External services for monitoring checks
These connections originate from the device running the check. Allow an entry only if you use the corresponding check or option.
warranty.api.hp.com
apigtwb2c.us.dell.com
www.powershellgallery.com
cdn.powershellgallery.com
cdn.oneget.org
go.microsoft.com
pcsupport.lenovo.com
www.wortmann.de
endoflife.date
rdap.org
ws1.blitzortung.org
ws7.blitzortung.org
ws8.blitzortung.org
earthquake.usgs.gov
nominatim.openstreetmap.org
ipwho.is
api.deu.cloud.watchguard.com
pool.ntp.org
Without an API key, the HP Warranty check retrieves warranty data through HP's module. HP does not document the destination host of this lookup. If you need a completely fixed allowlist, use the check with an API key; see HP Warranty.
pool.ntp.org distributes requests across changing servers. If your firewall cannot allow UDP connections by FQDN, enter a fixed NTP server in the check or allow outbound UDP 123.
The DNS Blacklist (RBL) check makes no direct connections to the blacklist zones. It queries them as DNS lookups through the device's DNS resolver (default zones: zen.spamhaus.org, bl.spamcop.net, b.barracudacentral.org). DNS access (UDP/TCP 53) to that resolver is sufficient.
Destinations you configure
You set these destinations yourself. Take them from the respective configuration.
Opening a software catalogue from the software kiosk uses the user's browser: community.chocolatey.org, formulae.brew.sh, winget.run or packages.ubuntu.com. These catalogue links are separate from package installation downloads.
Verify the actual operation
- Apply the rules to the managed device's network and confirm it connects to octoja.
- Run a monitoring check and verify that a fresh result arrives. If the device is online but checks produce no results, inspect blocked requests to
repo.octoja.comand the check's own targets. - Test the software or update workflow you need separately; a working check does not verify those download paths.
- If a request fails, compare its timestamp and destination with the firewall/proxy log. Test in the agent's service context and, where relevant, the user context: a successful browser request alone is not sufficient.
Do not disable certificate validation or the entire web filter to make a test pass. For TLS inspection problems, see Windows installation troubleshooting. Send the failed operation, timestamp and relevant logs to support if the required destination is unclear; remove credentials before sharing them.
FAQ
The device is online, but live graphs, remote access or agent logs do not work – what should I check?
The device is online, but live graphs, remote access or agent logs do not work – what should I check?
Online status confirms the agent's connection, not your browser's connection. The browser you use to open octoja also needs an ongoing connection to your octoja instance. The two can be on different networks.
Check the firewall and proxy on your browser's network too:
- Allow HTTPS and WSS on TCP 443 to your octoja instance hostname, including the
/api/realtime/hubpath. WebSocket upgrades and established WebSocket connections must not be blocked or ended prematurely. - Compare the failed operation's timestamp with the firewall/proxy log. A page loading or a device being online does not confirm this connection.
If you cannot retrieve agent logs through octoja, collect them directly on the device – see Collect logs for a support case, section Offline device: collect logs manually. This also works for an online device.
Was this helpful?
Still need help? Ask the team