Use this guide when a managed endpoint cannot enroll, repeatedly disconnects, or unexpectedly appears offline in remFREE.
Work from the endpoint outward.
Confirm the agent service is running
Start by verifying that the remFREE agent is installed and running.
If the agent service will not remain running, investigate that problem before treating it as a network issue.
Review the local remFREE agent logs for startup failures or configuration errors.
Confirm DNS resolution
The endpoint must be able to resolve:
rmm.remfree.com
On Linux, useful commands include:
dig rmm.remfree.com
or:
getent hosts rmm.remfree.com
On Windows PowerShell:
Resolve-DnsName rmm.remfree.com
If DNS resolution fails, correct that problem before continuing.
Confirm HTTPS connectivity
Verify that the endpoint can reach:
https://rmm.remfree.com
On Linux:
curl -I https://rmm.remfree.com
On Windows PowerShell:
Invoke-WebRequest https://rmm.remfree.com -Method Head
Failure here can indicate:
- DNS problems
- routing problems
- outbound firewall policy
- proxy requirements
- certificate validation problems
- TLS inspection issues
Confirm outbound TCP 443
remFREE uses encrypted outbound communication.
The endpoint must be able to establish outbound TCP 443 connections to the remFREE service.
Check secure WebSocket handling
Persistent agent communication uses:
wss://rmm.remfree.com/ws
Some firewalls and secure web gateways permit ordinary HTTPS requests but interfere with long-lived WebSocket connections.
If the endpoint can reach the website but will not remain online, verify support for:
- WebSocket protocol upgrades
- long-lived TLS sessions
- outbound TCP 443
- the remFREE hostname
Check proxy requirements
A browser successfully reaching remFREE does not prove that a background service can reach it.
Enterprise proxies may apply different rules to:
- interactive browser sessions
- Windows services
- Linux daemons
- authenticated users
- machine accounts
Confirm whether the remFREE agent's execution context has the required network path.
Check TLS inspection
TLS inspection can alter the trust chain seen by the endpoint.
Confirm that:
- the endpoint trusts the organization's inspection certificate
- the inspection platform supports WebSockets
- connections are not being reset by inspection policy
Confirm system time
Incorrect system time can cause authentication and certificate validation problems.
Verify that the endpoint clock is reasonably accurate.
Check the device identity
If the operating system was rebuilt or the previous device record was intentionally removed, the endpoint may need to be enrolled again.
Do not repeatedly enroll a healthy existing agent merely because a temporary network problem occurred.
Review the agent logs
The agent logs are usually the most useful final source of evidence.
Look for messages related to:
- DNS
- TLS
- authentication
- enrollment
- WebSocket connection
- connection resets
- job processing
When contacting remFREE support, include the relevant log excerpt and the approximate time the failure occurred.