Network Ports & Firewall

Athena is designed to run inside your own network with a small, predictable set of ports. The server listens on two TCP ports — one for people (the Web UI and REST API) and one for agents — and every other network path is optional and only opens when you turn on the matching feature. This page is the single place to look when you write firewall rules.

Server listening ports#

The Athena server binds two ports directly (there is no separate reverse proxy to configure). Both are TLS by default. Their defaults come from the Server section of appsettings.json and can be changed there or via environment variables.

Open inbound TCP 8443 to the server from any network where administrators work, and inbound TCP 8444 from every network segment that hosts agents. The two ports are separate on purpose: the agent port speaks only HTTP/2 and requires a valid client certificate issued by Athena's own certificate authority, so it is not a general-purpose web endpoint.

What the agent needs open#

A managed host only needs to make one outbound connection: TCP 8444 to the server. The agent dials the server and keeps a long-lived connection open, over which the server pushes commands, deployments, scans and screen-share requests, and the agent returns results, inventory and heartbeats. That means:

• No inbound ports need to be opened on the agent for normal management.
• Agents behind NAT or a restrictive egress firewall work as long as they can reach the server's port 8444 outbound.
• A multi-homed agent makes the same outbound connection to each server it is enrolled with.

Two remote-support features can add extra paths to the agent — the RustDesk direct access port and the WebRTC screen-share relay — but both are optional and covered under remote support below.

Optional outbound paths from the server#

These connections are made by the server and only exist when you enable the matching integration. If you do not use a feature, its port stays closed and no rule is needed.

Remote support paths#

Athena's remote-desktop features are the only case where a port may need to be reachable on the agent or on a relay host. Both are off unless you turn them on.

WebRTC screen-share and the TURN relay#

The built-in technician screen-share uses WebRTC. In many networks the browser and the agent negotiate a direct peer-to-peer media path and no fixed port is required. For firewall-deterministic connectivity you can stand up a coturn TURN relay, which listens on a single UDP port that both sides connect to:

When a relay is configured, both the technician's browser and the agent must be able to reach the relay host on this port. See Screen-Share Relay (TURN) for the full setup, including one-click provisioning onto a Linux agent.

RustDesk direct access#

The optional RustDesk integration can be configured for direct IP access, in which case the RustDesk client on the managed host listens for direct connections:

Direct access is off by default. Leave it off — and this port closed — unless you specifically operate RustDesk in a direct-connection topology.

Firewall checklist#

For a typical deployment, the minimum ruleset is:

• Inbound TCP 8443 to the server from administrator networks (Web console + API).
• Inbound TCP 8444 to the server from every agent network (agent channel).

Then add only the optional rules for the features you use:

• Outbound TCP 5432 server → PostgreSQL host (external database only).
• Outbound TCP 636 server → domain controller (LDAP/AD login).
• Outbound UDP 514 server → SIEM (audit forwarding).
• Outbound HTTPS server → identity provider (Keycloak SSO).
• UDP 3478 to the relay host from browsers and agents (WebRTC TURN relay).
• TCP 21118 to agents (RustDesk direct IP access only).