How to Monitor Infrastructure Behind a Firewall or VPN
Private infrastructure is often exactly what you want to protect from the public internet. That creates a practical monitoring question: how do you verify health from an external service when the target is not publicly reachable? The short answer is that you either expose a narrow public check target on purpose, or you wait for a probe allowlist model that lets you open access only to approved monitoring sources.
What external monitoring can and cannot do
External monitoring only sees what your network exposes to the public internet. If a service is reachable only from a private network, site-to-site VPN, or internal address space, a public probe cannot contact it directly.
That does not mean monitoring is impossible. It means you need to define a safe public surface that proves the private system is healthy without publishing the entire private service itself.
Typical private infrastructure scenarios
Internal API behind a VPN
The API is not internet-facing, so a public probe cannot call it directly. A small public health endpoint can still verify whether the internal dependency chain is healthy.
Database on a private subnet
You usually should not expose the database just for monitoring. Instead, verify it through an application or gateway endpoint that can safely reach it internally.
Admin panel locked behind a firewall
The safer move is often to monitor the public reverse proxy or a dedicated status endpoint rather than opening the whole admin interface.
Future allowlisting needs
If you plan to restrict access by source IP, probe allowlisting will be a good fit once an official public probe IP list is available.
Practical approach today
Decide what actually needs to be externally verified
Start with the user-facing or business-critical behavior you care about, not with the internal component you happen to own.
Expose a narrow health endpoint
Create a minimal HTTPS endpoint that returns a simple success marker when the private dependency path is healthy.
Keep private services private
Do not open a database, internal API, or admin interface to the public internet solely because you want a monitor to touch it.
Use allowlisting when officially supported
If and when a public probe IP list is published, firewall rules can become more selective. Until then, design around a safe minimal public surface.
A practical monitoring design
For private infrastructure, the monitor usually targets a small public entry point rather than the private node itself:
Public probe -> HTTPS https://status.example.com/health/internal Health endpoint -> checks VPN path, internal API, or private DB Success marker -> returns "internal_ok" nsmon HTTPS check -> validates status code and body match
The public target stays narrow
You expose only the minimum needed for health validation, not the private system itself.
The private dependency is still tested
The endpoint can verify that the internal API, database, or service is actually reachable from the environment that matters.
HTTPS gives you richer validation
With expected status and body match, you can prove more than basic reachability.
This design is safer today
It works even before a formal public probe IP allowlist exists.
Why not just open the private service?
Because monitoring should not force you into a weaker security posture. If a service was meant to stay behind a firewall or inside a VPN, opening it broadly to the public internet just to run checks is usually the wrong tradeoff.
A thin public endpoint or reverse-proxy path is often the better answer. It gives you an external signal without turning internal infrastructure into a public attack surface.
Open the private service vs expose a narrow health endpoint
| Topic | Open the private service | Narrow public health endpoint |
|---|---|---|
| Security exposure | Higher. The real internal service becomes reachable from the internet. | Lower. Only a minimal validation path is public. |
| Monitoring signal | Direct, but often too risky for production. | Indirect, but usually strong enough and much safer. |
| Operational fit | Can conflict with existing firewall and VPN design. | Works with private infrastructure and public monitoring together. |
Database monitoring is a good example of this design tradeoff.
Databases should usually stay private. A small HTTPS endpoint that validates a real query is often better than exposing a raw database port to the internet.
Read the database monitoring guide βGood patterns in practice
Public health endpoint for a private API
The endpoint returns success only if it can reach the internal API through the required VPN or network path.
Reverse proxy health route
A reverse proxy can expose `/health/internal` while the application itself stays inaccessible from the public internet.
Selective source allowlisting later
Once official probe IP ranges are published, you can tighten firewall rules around known monitoring sources instead of using broader exposure.
Monitoring from the user-facing edge
Sometimes the best signal is the public edge that proves internal dependencies are still functioning behind it.
Important limitations
- β A fully private service cannot be checked directly from public probes unless you expose some path to it.
- β A health endpoint should remain minimal and should not leak internal topology or sensitive diagnostics.
- β Do not assume a public probe IP allowlist exists until it is officially published.
- β External monitoring should complement, not replace, your internal observability and logs.
Useful manual checks
curl -fsS https://status.example.com/health/internal A good way to validate what the public monitor will actually see.
curl -I https://status.example.com/health/internal Useful when you want to confirm the endpoint is exposed with the expected status code.
curl http://internal-api.service.local/health Run from an internal host when you need to confirm that the private dependency itself is healthy.
Frequently asked questions
Monitor private infrastructure without weakening your security model.
Use nsmon to validate narrow public health endpoints that prove your private services are still working, and be ready to tighten access further when selective probe allowlisting becomes available. Create a free account and design safer external monitoring.