How to Monitor Private Services from Outside Your Network

The Challenge

You have services running behind a firewall:

• Internal APIs
• Backend databases
• Admin dashboards
• Internal tools

They're not publicly accessible—by design. But you still need to know when they fail.

External monitoring services can't reach them. So how do you monitor from outside?

Solution Overview

Four main approaches:

Approach 1: Agent-Based Monitoring

Recommended for most teams.

Install a monitoring agent inside your network. The agent:

1. Runs inside your firewall
2. Checks internal services
3. Reports results outbound to monitoring service
4. No inbound connections needed

How It Works

[Private Network]                    [Internet]

  Internal Service                  Monitoring Dashboard
       ↓                                   ↑
  Monitoring Agent  ──outbound HTTPS──→  Cloud API

The agent initiates all connections. Your firewall allows outbound HTTPS (port 443), which is standard.

Implementation with Wakestack

1. Install the agent on a server inside your network:

curl -fsSL https://wakestack.co.uk/install.sh | sudo bash

2. The agent automatically monitors the host it's installed on
3. Configure internal service checks in the dashboard
4. Agent checks services and reports back

Benefits

• No firewall changes
• No exposed endpoints
• Agent handles authentication
• Works from any network location

Considerations

• Need a server to run the agent
• Agent must have network access to services
• Agent availability affects monitoring

Approach 2: Reverse Tunnel

Create a secure tunnel from inside your network to the monitoring service.

How It Works

[Private Network]                    [Internet]

  Internal Service                  Monitoring Service
       ↓                                   ↓
  Tunnel Client  ←──tunnel──→  Tunnel Server
       ↓                                   ↓
  (checks service)              (receives results)

The tunnel originates from inside your network (outbound connection), but allows the external service to reach back in.

Implementation with SSH Tunnel

# From inside your network
ssh -R 8080:internal-service:80 monitoring-server
 
# Now monitoring-server can reach internal-service via localhost:8080

Implementation with ngrok/Cloudflare Tunnel

For more robust tunnels:

# Cloudflare Tunnel
cloudflared tunnel --url http://internal-service:8080

This creates a public URL that routes to your internal service through an encrypted tunnel.

Benefits

• External service can reach internal endpoints
• Encrypted tunnel
• No permanent firewall changes

Considerations

• Tunnel must stay connected
• Adds latency
• Tunnel endpoint is accessible (secure it)

Approach 3: VPN/Private Network Connection

Connect your monitoring service to your private network via VPN.

How It Works

[Private Network]          [VPN]          [Monitoring]

  Internal Service  ←─VPN tunnel─→  Monitoring Probes

The monitoring service has a presence inside your network through VPN.

Implementation

1. Set up VPN server (OpenVPN, WireGuard) in your network
2. Configure monitoring service to connect via VPN
3. Monitoring probes can now reach internal services

Some enterprise monitoring services support this directly:

• Datadog Private Locations
• Grafana Private Probes
• Checkly Private Locations

Benefits

• Full access to internal network
• Enterprise-grade security
• No exposed endpoints

Considerations

• Complex setup
• VPN must stay connected
• Requires enterprise monitoring features

Approach 4: Health Endpoint Proxy

Expose only health check endpoints through a reverse proxy.

How It Works

[Private Network]                    [Internet]

  Internal Service                  Monitoring Service
       ↓                                   ↓
  Health Endpoint                   HTTP Check
       ↓                                   ↓
  Reverse Proxy  ←──HTTPS──→  External Request
  (nginx/Caddy)

Only /health endpoints are accessible externally.

Implementation with nginx

# Only proxy health endpoints
location /health/service-a {
    proxy_pass http://internal-service-a:8080/health;
 
    # Optional: IP whitelist
    allow 1.2.3.4;  # Monitoring service IP
    deny all;
}
 
location /health/service-b {
    proxy_pass http://internal-service-b:8080/health;
    allow 1.2.3.4;
    deny all;
}
 
# Block everything else
location / {
    return 404;
}

Add Authentication

location /health/ {
    auth_basic "Monitoring";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://internal-service:8080/health;
}

Or use header-based auth:

location /health/ {
    if ($http_x_monitoring_key != "your-secret-key") {
        return 403;
    }
    proxy_pass http://internal-service:8080/health;
}

Benefits

• Simple to implement
• Only health endpoints exposed
• Standard HTTP monitoring works

Considerations

• Some exposure (even if limited)
• Health endpoints must be safe to expose
• Requires firewall rules for proxy

Security Best Practices

For Any Approach

Minimize exposure: Only expose what's necessary for monitoring.

Use authentication: Even health endpoints should require auth when exposed.

Monitor the monitor: If your monitoring agent/tunnel fails, you should know.

Audit access: Log who/what accesses monitoring endpoints.

Health Endpoint Safety

Safe health endpoint response:

{
  "status": "healthy",
  "timestamp": "2024-01-15T10:30:00Z"
}

Unsafe health endpoint response (don't do this):

{
  "status": "healthy",
  "database": {
    "host": "db.internal.company.com",
    "version": "PostgreSQL 14.2",
    "connections": 45
  },
  "config": {
    "api_key": "sk-abc123..."
  }
}

Network Segmentation

Place monitoring infrastructure in a DMZ or separate network segment:

[Internet] → [DMZ: Monitoring Agent] → [Internal: Services]

The agent can reach internal services, but compromise of the agent doesn't give full internal access.

Choosing the Right Approach

Use Agent-Based Monitoring If:

• You want simplicity
• You have servers to install agents on
• You don't want to modify firewalls
• You're using a cloud monitoring service

Use Reverse Tunnel If:

• You need external probes to reach specific endpoints
• You can't install agents
• You want temporary access for debugging

Use VPN If:

• You have enterprise security requirements
• You need full network access for monitoring
• You're using enterprise monitoring tools

Use Health Endpoint Proxy If:

• You only need basic HTTP checks
• You're comfortable exposing limited endpoints
• You want maximum simplicity

Implementation Checklist

Before Starting

• Identify services that need monitoring
• Determine acceptable security trade-offs
• Choose monitoring approach

For Agent-Based

• Select server for agent installation
• Install and configure agent
• Verify agent can reach internal services
• Configure service checks
• Test alerting

For Tunnel/Proxy

• Set up tunnel or proxy
• Configure authentication
• Whitelist monitoring service IPs
• Test connectivity
• Monitor tunnel/proxy health

After Implementation

• Document the setup
• Set up alerts for monitoring infrastructure itself
• Regular security review

Summary

Monitoring private services from outside requires bridging network boundaries securely.

Best approaches:

1. Agent-based: Install agent inside, reports outbound (recommended)
2. Reverse tunnel: Outbound tunnel allows inbound monitoring
3. VPN: Monitoring joins your private network
4. Health proxy: Expose only health endpoints

Key principles:

• Prefer outbound connections (no firewall changes)
• Minimize exposure (only what's needed)
• Use authentication (even for health checks)
• Monitor your monitoring (know when it fails)

The goal is visibility without vulnerability. You can monitor private services while keeping them private.