How to monitor devices behind NAT — without opening any ports
If your servers, switches and printers sit behind a firewall, most monitoring tools can't see them — and the usual workarounds (port forwarding, a VPN, a DMZ) trade away the security the firewall was there to provide. There's a cleaner way: let the device reach out, instead of asking the internet to reach in.
Why outside monitors go blind behind a firewall
A NAT firewall exists to do one thing well: refuse unsolicited inbound connections. Everything on the office LAN shares a public IP, and nothing on the internet can open a session to an internal device unless you explicitly allow it. That's exactly the security property you want.
It's also why a classic "outside-in" monitor — one that polls your endpoints from the public internet — can only ever see your public-facing services. It can tell you the website answered. It cannot tell you that the domain controller's disk is 96% full, that a core switch dropped two ports, or that the UPS is running on battery. Those devices are behind NAT, and the firewall is doing its job by hiding them.
Outside-in poller vs. the firewall
Port forwarding, VPNs and DMZs — and their cost
Teams that need internal visibility usually reach for one of these, and each reopens some of the exposure the firewall was closing:
- Port forwarding punches a hole straight to an internal device — now that service is on the public internet, scanned and probed like everything else.
- A site-to-site VPN or remote probe works, but it's infrastructure to build, secure and maintain at every location — heavy for a small office and a real project for an MSP with dozens of client sites.
- A DMZ adds complexity and still doesn't reach the ordinary LAN devices you actually want to watch.
Agent-push: let the device reach out
The insight is simple. Firewalls block inbound connections, but they let internal devices make outbound ones — that's how the same office browses the web. So instead of the monitor calling in, a small agent inside the network calls out: it opens an outbound TLS connection to the monitoring backend and pushes metrics up that channel. The device always initiates, so the firewall sees ordinary outbound traffic and nothing inbound is ever opened.
Inside-out agent push
One more benefit falls out of this design: the agent can act as a site collector. Devices that can't run an agent — switches, routers, printers, UPS — are scraped locally over SNMP by the agent, which then pushes their health out over the same outbound connection. One install covers the whole site.
Monitoring a site behind NAT in four steps
- Get an enrollment tokenCreate a device in the Bayqus panel and copy its token.
- Run one install commandOn any always-on Linux or Windows machine at the site (one line; or one kubectl apply for a cluster).
- Point the collector at SNMP devicesThe agent scrapes switches, printers and UPS locally — no agent needed on those.
- Watch it appearHost and site devices come online in about 60 seconds, over outbound TLS, with no inbound port opened.
Compared with the tools you know
Outside-in tools each have their place — here's how the agent-push approach differs from the ones people ask about most.
Common questions
Do I need to open any firewall ports?
No. The agent makes an outbound TLS connection, so the device initiates the session and no inbound rule is added. Your firewall stays exactly as locked down as it is today.
Is this less secure than a VPN?
It avoids the main risks of the alternatives. There's no exposed inbound service (unlike port forwarding) and no always-on network bridge to maintain (unlike a site-to-site VPN). Traffic is a single authenticated, encrypted outbound channel.
How do I monitor devices that can't run an agent, like a printer or switch?
One agent on the site acts as a collector and polls those devices locally over SNMP, then pushes their metrics out with everything else. You don't install anything on the printer or switch.
Does this work for multiple remote sites?
Yes. Each site runs its own agent/collector that pushes outbound independently, which is why the approach scales cleanly for MSPs managing many client locations — no per-site VPN or remote-probe networking.
What if the internet connection at the site drops?
The backend detects the lost connection almost immediately (within seconds) and flags the site offline, so an outage is itself an alert rather than a blind spot.
See behind your firewall tonight
Install one agent, watch the whole site — servers, PCs and SNMP devices — with zero open ports. The first device is free.