When an install fails, a machine goes quiet, or you set up a new security rule

How to allow the GoTenix agent through your firewall and security software

Give your firewall, DNS filter, application control, EDR and antivirus the short list they need, and the GoTenix agent installs, checks in, updates and restarts on its own.

Browse
On this page

How to do it

  1. Find the two addresses your PCs use.

    The portal address is the one in your install link and the one you sign in to. It is used to download the installer, to read its setup details and to send the install report. The agent address is the one the agent uses from then on. It looks like your-name.agents.ezcyber.app, where your-name is one word that belongs to your account. On a PC that already has the agent, open C:\Program Files\GoTenix Agent\data\base_url to read it. If you cannot find it, use the two wildcard names in step 2. A custom portal domain does not change the agent address. Only the portal address changes.

  2. Allow these names on port 443, outbound.

    1. Your portal address, for example portal.yourcompany.com. Needed when you install. 2. your-name.agents.ezcyber.app, or *.agents.ezcyber.app to cover every account. 3. your-name.gotenix-agents.com, or *.gotenix-agents.com. From agent 1.8.0 on, the agent also trusts this second address, and your portal can move a machine to it. Use the same one-word name as in the first agent address. All three use HTTPS on TCP port 443. The live terminal and chat run on the same name and port as a WebSocket (wss), so a filter that blocks WebSocket upgrades will block them. The agent checks in about every 25 seconds, unless your policy sets a longer check-in interval (up to 5 minutes). Nothing is needed in the other direction.

  3. Let the traffic through without opening it.

    Add the same names to your TLS inspection bypass list, and send them direct, not through a proxy. After the agent joins, its requests carry the machine's own certificate, which the portal checks. A device that decrypts and re-signs the traffic ends that connection itself. The agent does not read the Windows or browser proxy setting for its agent address, so send that name direct, not through a proxy. The installer's calls to the portal address use Go's default client, which reads the HTTP_PROXY, HTTPS_PROXY and NO_PROXY settings of its own process, so that name can go through a proxy set that way. The agent also needs a correct PC clock. The installer's own message for this case says a TLS-inspecting firewall, a proxy that re-signs traffic, or a wrong clock will stop the secure connection. Do not put these names behind a CDN or reverse proxy that ends TLS. The agent addresses are DNS-only because such a service strips the machine's certificate.

  4. Allow the program in application control, for example ThreatLocker.

    Create the rule from the publisher first. The files list EZ IT Solutions LLC as the company, and Apps & features shows the same name as the publisher. The exact signer name is on the file itself: right-click it, choose Properties, then Digital Signatures. If your tool wants a path, allow C:\Program Files\GoTenix Agent\GoTenixAgent.exe and the folder C:\Program Files\GoTenix Agent\ below it. The service name is GoTenixAgent, and it runs as LocalSystem. The same file also runs inside each signed-in user's session as the tray icon and the support shortcut, so the rule must cover both.

  5. Allow scripts that the agent starts.

    When a tech runs a script, the agent starts powershell with -NoProfile -ExecutionPolicy Bypass -File and a file under C:\Program Files\GoTenix Agent\data\runs\. The agent puts these files there on purpose, because tools that block scripts in temp folders would stop them. The live terminal starts cmd.exe or powershell.exe. If your rules limit what a service may launch, allow these when they are started by GoTenixAgent.exe.

  6. Allow the program in EDR and antivirus, for example Microsoft Defender.

    Add an exclusion or a trusted-application rule for the GoTenix Agent folder and for GoTenixAgent.exe, and trust the signer. If your product guards services, let the Windows service manager start and stop the GoTenixAgent service. The agent keeps its identity, logs and script files in the data folder inside that install folder, so a folder rule covers them. The agent does not create scheduled tasks.

  7. Let updates replace the file.

    The agent downloads an update from its agent address, checks it with a signature and a hash, then writes GoTenixAgent.exe.update next to the program. It renames the running file to GoTenixAgent.exe.prev, renames the new file into place and restarts. When the new version checks in, it deletes the .prev file. If three starts pass without a good check-in, it puts the old file back and renames the new one to GoTenixAgent.exe.rejected. So the rule must let that folder create, rename and delete those files. A rule on one file hash fails after the first update.

  8. Start the service and check it.

    If a rule was added after the agent was blocked, open PowerShell as an administrator and run: Start-Service GoTenixAgent Then open RMM, then Devices, and look at the machine's Last check-in. The portal shows a machine as Offline when its last check-in is older than three check-in intervals, and never sooner than three minutes.

The pages behind each click

What you will have

  • Let the agent reach its two addresses over HTTPS on port 443, with nothing in the way that opens and re-signs the traffic.
  • Let application control, EDR and antivirus run the agent, update it and restart it, using the publisher or the install folder instead of a file hash.
  • Know what you will see if something still blocks it, and what to do first.

Why it works this way: How to allow the GoTenix agent through your firewall and security software

The agent starts every connection itself, so you do not need an inbound rule. It needs two things from your stack: a way out to its addresses, and permission to run, replace and restart one signed program.

Security tools often judge a program by its file hash. The agent replaces its own program file when it updates, so a rule that names only one hash stops working at the next update. A rule on the publisher or the folder keeps working.

Windows lists the agent as GoTenix Agent on a PC, whatever name your clients see in your portal. That is the name to look for in your security tool.

If it did not work: How to allow the GoTenix agent through your firewall and security software

  • The exe installer ends with code 16: Windows itself would not start the service, so a security tool blocked the program. Allow it by publisher (steps 4 and 6), then run Start-Service GoTenixAgent.
  • The install stops and msiexec returns 1603: the machine did not connect to the portal within 90 seconds. The reason can be the network, a refused install link or a blocked program. Event Viewer, Windows Logs, Application, source GoTenix Agent, event ID 1700 holds the reason. Open the Troubleshooting the RMM agent page for the steps.
  • Windows says Access is denied (error 5) when the service starts: a security tool is blocking the program. Allow it (steps 4 and 6), then run Start-Service GoTenixAgent.
  • The agent stays installed but never joins: check the clock, DNS and the TLS inspection bypass (steps 1 to 3).
  • An older PC still runs the agent under its old product name, in a service and a folder that do not say GoTenix: it needs a fresh install. Rules that name the old folder or file do not cover the new names.

Questions this page answers

What do I whitelist for the RMM agent?

Allow your portal address and your agent address (your-name.agents.ezcyber.app, and your-name.gotenix-agents.com, agent 1.8.0 and later) on port 443 outbound, and allow the signed program in C:\Program Files\GoTenix Agent by its publisher.

Does the RMM agent need an inbound firewall rule?

No, because the agent starts every connection itself and only needs to reach its addresses over HTTPS on port 443.

Will TLS inspection or a proxy break the RMM agent?

It can, because after the agent joins its requests carry the machine's own certificate, so add the agent names to the inspection bypass list and send them direct.

Why did a hash rule in my application control stop the agent after an update?

The agent replaces its own program file when it updates, so the hash changes, and a rule on the publisher or the install folder keeps working.

What is the service name to start after I allow the agent?

The service is GoTenixAgent, so run Start-Service GoTenixAgent in an administrator PowerShell.

Was this helpful?

Last validated 2026-10-11

Keep digging