Security & deployment

The agent never accepts a connection: outbound-only, explained for your firewall team

The firewall change request comes back from the client’s security team with one question in the comments: which inbound ports does the agent need on each server? The technician writing the answer has done this before for a large RMM vendor and remembers the list: a listener on every host for remote control, an RDP gateway for desktops, a VPN concentrator for the laptops that travel. This time the answer fits on one line, and the reviewer does not believe it. The ticket bounces twice before they accept that the answer is none. Every inbound rule on an endpoint is a rule a questionnaire will ask about and a firewall team will maintain for years. Guardian Plus starts from one design decision that removes all of them.

What does the agent need from the network?

Outbound HTTPS on port 443 to the management server, and the ability to validate that server’s certificate. Nothing else. Every managed endpoint dials out over TLS and keeps one authenticated socket open. Nothing listens.

Outbound HTTPS on port 443A valid server certificate it can verifyNothing else

The certificate requirement is the one that bites. Intercepting proxies that re-sign TLS are the usual cause of a client that will not connect, because the agent insists on validating the server certificate by design. Tell the network team before the first install and the first install works.

How does everything fit through one socket?

Browser terminal, remote desktop, monitoring data and commands all ride that one outbound connection. There is no firewall rule to add on the endpoint, no port to forward, no VPN to maintain and no RDP gateway to defend. The client keeps a persistent WebSocket with a ten-second heartbeat, reconnects with exponential backoff, detects sleep and wake, and keeps working locally if the server is briefly unreachable.

The terminal on the far end is a genuine PTY, not a command runner, and the remote desktop covers Windows, macOS and Linux with multi-monitor and consent prompts. Every session is audit-logged: operator, host, mode, start and stop. Credentials for the target can come from Guardian Vault, resolved server-side and injected into the session, so the technician connects without ever being shown the password. That is a separate post: connect without the password.

What the old change request asked for
What this one says
An inbound rule per endpoint for remote control
None on any managed endpoint
An RDP gateway on the internet for desktops
Desktop rides the agent’s outbound socket
A VPN for the laptops that travel
Laptops dial out over 443 from anywhere
An SSH key ring to distribute and revoke
A PTY through the socket; sessions logged
A monitoring listener on every host
One outbound TLS socket, heartbeat every 10 s

What runs on the endpoint?

A native service installed from a signed package, one per platform, each bundling its own runtime so there is nothing to install first. Windows, server and desktop, 64-bit. macOS on Intel and Apple Silicon, monitoring around the clock whether or not anyone is logged in. Linux on Ubuntu 22 and 24, Rocky 9 and 10, CentOS Stream 9 and SUSE 16. The agent authenticates to the plane with its own key, held in its config file with owner-only permissions, and it is designed to sit quietly on production machines. The firewall team does not need to know any of that to approve the request, but the desktop team will ask.

Where does a port actually open?

Three places, each optional and scoped to a machine you choose. None of them is on a managed endpoint by default, and none of them is reachable from the internet unless you make it so.

A collector (an agent promoted to reach devices that cannot run one: switches, firewalls, printers, appliances) binds a local port to proxy for them.

A trap receiver you designate listens for SNMP traps from your network devices.

Remote desktop on macOS and Linux uses the operating system’s own screen-sharing service on loopback, relayed out over the agent’s existing connection. It never leaves the machine except through the socket.

Where does the management plane sit?

That is the firewall team’s real question, and there are three documented answers. One trusted network, when the management plane and the endpoints already share a boundary. Roaming workforce: endpoints anywhere, the console behind your perimeter, no endpoint ever exposed to the internet. Isolated management network: the monitoring plane on a private network with exactly one inbound rule, and you can close even that at the cost of up to an hour before a revoked session stops working. The decision between them is its own post, three network postures.

Is the session end-to-end encrypted?

Here is the limitation, stated plainly, because a questionnaire will ask. Terminal and desktop sessions are relayed through the platform. They are TLS-protected end to end, but they are not end-to-end encrypted in the cryptographic sense: the management plane terminates TLS and relays. That is what makes server-side credential injection and session audit possible, and it is why we publish a threat model for the plane rather than a badge. Two smaller prerequisites for the honest list: remote desktop on macOS requires the Screen Recording permission, and on Windows it requires admin rights.

What this costs you

Every inbound rule is a line in every questionnaire you answer, a rule reviewed at every audit, and a change request when the endpoint moves. A VPN is an account reconciled every time someone joins or leaves, once a month at least. An RDP gateway is an internet-facing service to patch on someone else’s schedule. Removing all three does not show up as minutes per technician per day; it shows up as the change request that is approved on the first pass, and the questionnaire section that is one sentence long.


The postures, in full

Written for the person who answers the firewall change request, not the person who signs the order.