How to Monitor Internal Services Behind a Firewall

Your internal application is unavailable, but the public home page is green. This is unsurprising: the home page has never visited your VPN and has no strong opinions about the warehouse network.

Monitoring internal services begins with a location that can reach them. In RMON, an agent sends the actual monitoring request. Place that agent on a network whose access you want to verify, then arrange the separate connections needed to manage it and receive its results.

Choose the internal question first

An API inside a hosting network, a branch-office application and a private DNS resolver are different targets. Write a short sentence for each check: “The warehouse can open the inventory endpoint,” or “The branch resolver answers this record query.”

A probe next to the application tests local access. A probe in the branch tests the branch route. Both may be valuable, but one cannot stand in for the other. Give the agent a location name that remains useful in an alert.

Use a dedicated account for authenticated checks with only the access the request needs. Keep credentials in the appropriate authentication fields, not in check names, descriptions or runbook links.

Plan each required connection

A target can remain private while an agent checks it internally. This does not mean the agent has no other connectivity requirements. For RMON, distinguish these paths:

• Agent to target: the configured service port, DNS resolver or ICMP traffic needed by the check.
• RMON to agent host: SSH for installation and service actions, plus the configured HTTP management port, normally 5101.
• Agent to RMON: access to its configured assignment address so it can retrieve checks.
• Agent to result receiver: the configured result-delivery address and port, normally 5100.

These are connection directions, not a request to open every port publicly. Use private routing or a VPN where appropriate, restrict the allowed sources and account for return traffic. RMON agent management is not an outbound-only tunnel; do not plan a deployment on that assumption.

Agents also need DNS and access to the packages or images required for installation and updates. Notifications need their own provider connectivity. Use the complete network requirements when writing firewall rules.

Check DNS, containers and trust from the agent

Private names must resolve in the agent’s execution environment. Split DNS may intentionally direct internal and external clients to different addresses. Confirm that the result matches the route you intend to test.

Remember that 127.0.0.1 identifies the environment making the request. Inside an agent container it does not identify another host or automatically refer to the Docker host. Use the target’s reachable address and keep the expected hostname in HTTPS requests.

For a private HTTPS service, prepare the required CA trust and any client credentials using the HTTP check’s supported fields. Keep certificate verification enabled. The target’s client certificate is separate from credentials used when the agent delivers results to RMON.

For result delivery, RMON supports HTTP, HTTPS and HTTPS + mTLS. Prepare the receiver for the chosen mode, apply it with the agent’s installation or reconfiguration workflow, and verify fresh results. This setting protects that delivery connection; the agent management API remains HTTP on the restricted management network.

Install, assign and verify one internal check

1. Add the agent host in the intended group, save the SSH credentials and run Check SSH.
2. Install the agent using Agents → Add Agent, following the agent guide. Wait for the operation’s final status.
3. Create a check for a read-only internal endpoint. Select the agent explicitly and define the expected response.
4. Confirm a fresh result, then a subsequent result at the configured interval.
5. Assign a tested notification destination and exercise failure and recovery using a disposable target.

Start with one location while establishing the connections. Add another when you have a clear comparison to make. A successful SSH test verifies management access over SSH; it does not prove that assignments, target requests or result delivery work.

Use disagreement between locations as evidence

If the hosting-network agent succeeds while a branch agent fails, compare the branch’s DNS, routing, firewall and target authentication. If neither produces fresh results, investigate the monitoring paths before assuming the application has failed.

Keep conditions consistent when comparing locations. Two checks against different endpoints may be useful, but their disagreement does not isolate a network problem. The multi-location article explains how to design that comparison.

Keep the internal view useful and private

Review assignments after network changes, agent replacement and service moves. Track the certificate and credential lifecycles for both monitored targets and result delivery. Recheck incident delivery after notification credentials or outbound rules change.

RMON status pages are public. If you publish selected service states, use public-friendly names and review the page while signed out. Internal addresses and operational instructions belong in access-controlled documentation.

The useful outcome is specific: an internal request runs from the right place, its result arrives, and a failure reaches someone who can investigate. The service can keep its firewall; the monitoring just needs a carefully planned seat inside it.