FrameFlow is an agentless monitoring system that uses multiple protocols for system monitoring. This article describes the ports that are used and provides guidelines to help with the configuration of firewall rules.

Agentless Monitoring

FrameFlow is an agentless monitoring system which means that you never need to install anything on the systems being monitored. We chose this model because agents are problematic in many ways. They circumvent network security, present management problems at upgrade time and can interfere with the operation of the systems they are designed to monitor.

Instead of using agents, FrameFlow contacts systems using standard network protocols such as HTTP, DCOM, WMI, SNMP and more. Since various protocols generally use their own custom set of ports, it's important to understand how these protocols work if it becomes necessary to do monitoring through a firewall or other security system.

Monitoring Through a Firewall - General Purpose Windows Monitoring

We generally do not recommend monitoring configurations where the monitoring system is separated from the monitored systems by a firewall however there are some cases where it is necessary and desirable. For general purpose monitoring where you plan to monitor not only system health but also event logs, file systems, performance counters and more, it is best to configure the firewall to whitelist the system where FrameFlow is installed. This provides a secure method to trust the FrameFlow system while ensuring protection for and from other systems. Simply opening up a port range is usually not practical due to the way Windows DCOM (Distributed COM) and Remote Procedure Call (RPC) requests work. More details about DCOM/RPC and their use of ports are provided below.

Monitoring Through Firewall - Windows System Health Monitoring

If your monitoring configuration is focused on system health monitoring using FrameFlow's System Health event monitor then there is an alternative you can consider. Instead of using the default protocol (performance counters) you can set the event monitor to use SNMP instead. SNMP requests go over UDP port 161 and so it is sufficient to allow this port across the firewall (limiting the source to the FrameFlow server is also recommended). You also will need configure Windows to add the SNMP components using the Server Manager in Windows Server 2008 and later, or using the Add/Remove Programs option in earlier versions of Windows.

Monitoring Through a Firewall - Linux Systems

All monitoring requests for Linux systems go over SSH port 22. Allowing this port across the firewall from the FrameFlow server is sufficient to allow all of the Linux/SSH event monitor to connect and collect monitoring data.

DCOM/RPC Port Ranges

For reasons that only Microsoft can explain, DCOM and RPC use a dynamic range of ports and this presents a challenge when configuring firewall rules. For Server 2008 and later the port range is 49152 to 65535. For earlier versions of Windows it is even larger, spanning 1024 to 65535. Each request can go over a different port that is assigned dynamically and on the fly. For more details, see this article Service overview and network port requirements for the Windows Server system on the Microsoft support site.

The good news is that it is possible to establish some control over the RPC port range. You can limit it to a range that you choose by following the steps in this article How to configure RPC dynamic port allocation to work with firewalls on the Microsoft site.


Instead of monitoring through a firewall, often better, safer and easier to place the monitoring system in the same network segment as the systems being monitored. The advantage is that all monitoring occurs in the same network security group and monitoring is generally more efficient because there are few hops required to obtain the necessary data. It's not uncommon to have two or more FrameFlow systems, each operating in its own network zone and monitoring the systems that are closest to it.