Communication Matrix and Firewall Rules

pre-deployment

Communication Matrix and Firewall Rules

A single connectivity matrix and the firewall rules to go with it — everything a network or firewall team needs to open the right ports before Cloudmon is deployed.

Overview

Use this page as the Cloudmon network and firewall reference before deployment. The communication matrix below identifies the network paths required by Cloudmon components, while the firewall rule table provides the corresponding ports, protocols, and traffic directions.

ℹ️ Note: Which rules actually apply to your rollout depends on your deployment model (Single Network, Distributed, DMZ, or MSP) — see the dedicated Deployment Models article for that architecture guidance. The ports themselves don't change between models; only whether a given rule needs to cross a firewall does.

Principle of least privilege: nothing here should be treated as "open by default." Only permit the rules a feature you actually use requires — everything marked Feature-dependent stays closed until that feature is enabled.

Communication Matrix

Every flow Cloudmon uses, in one table. Find the row for the initiating host, follow it to the column for the destination, and the pill tells you the port, protocol, and requirement level. A dash means that pair never communicates directly.

This matrix is deployment-model agnostic. Apply only the flows required by the features you use; whether a flow needs a firewall rule depends on where the source and destination are placed in your deployment.

Firewall Rules

Core Cloudmon Connectivity

#	Source	Destination	Dest. Port	Protocol	Direction	Required?	Purpose
1	Controller	MongoDB Server	27017	TCP	Outbound	Required if remote	Controller connects to the MongoDB database
2	Admin / IT team browsers	Controller	443	TCP	Inbound	Required	HTTPS access to the Cloudmon web console
3	Linux Probe / Windows Probe	Controller	443	TCP	Outbound	Required	Probes report monitoring metrics back to the Controller
4	Agents (Linux / Windows)	Controller	443	TCP	Outbound	Optional	Agents report server metrics back to the Controller

Monitoring Connectivity

#	Source	Destination	Dest. Port	Protocol	Direction	Required?	Purpose
5	Linux Probe	vCenter / VMware hosts	443	TCP	Outbound	Feature-dependent	vCenter / VMware infrastructure monitoring
6	Linux Probe	Network nodes (availability)	N/A	ICMP	Outbound	Feature-dependent	Host availability using ping checks
7	Linux Probe	Internal service endpoints	Varies (custom)	TCP	Outbound	Feature-dependent	Host/service availability on customer-specified ports
8	Linux Probe	AWS endpoints (internet)	443	TCP	Outbound	Feature-dependent	AWS cloud resource monitoring
9	Linux Probe	Azure endpoints (internet)	443	TCP	Outbound	Feature-dependent	Azure cloud resource monitoring
10	Linux Probe	Websites (HTTP / HTTPS)	80 / 443	TCP	Outbound	Feature-dependent	Website availability and uptime monitoring1
11	Linux Probe	FTP Server	21	TCP	Outbound	Feature-dependent	FTP server availability and service monitoring
12	Linux Probe	DNS Server	53	UDP	Outbound	Feature-dependent	DNS resolution and service availability checks
13	Linux Probe	Web / SSL / REST API Endpoints	80 / 443 / Varies (custom)	TCP	Outbound	Feature-dependent	Website availability, SSL/TLS certificate monitoring, and REST API availability and response monitoring

Network Device Monitoring & Configuration Management

#	Source	Destination	Dest. Port	Protocol	Direction	Required?	Purpose
11	Linux Probe	SNMP devices (switches, routers)	161	UDP	Outbound	Feature-dependent	SNMP polling of network devices
12	Linux Probe	Network configuration backup target	22 / 23	TCP	Outbound	Feature-dependent	Configuration backup via SSH (22) or Telnet (23)

Syslog / SNMP Trap / NetFlow (Inbound to Probe)

#	Source	Destination	Dest. Port	Protocol	Direction	Required?	Purpose
13	Network devices (routers/switches)	Linux Probe	2055	UDP	Inbound	Feature-dependent	NetFlow data sent from network devices to the Probe
14	Network devices (routers/switches)	Linux Probe	514	UDP	Inbound	Feature-dependent	Syslog messages forwarded to the Probe
15	Network devices (routers/switches)	Linux Probe	162	UDP	Inbound	Feature-dependent	SNMP Trap messages sent to the Probe

Windows WMI

#	Source	Destination	Dest. Port	Protocol	Direction	Required?	Purpose
16	Windows Probe	WMI target devices	135 + dynamic (49152–65535)	TCP	Outbound	Feature-dependent	WMI monitoring of Windows servers/hosts

External / Internet Connectivity

#	Source	Destination	Dest. Port	Protocol	Direction	Required?	Purpose
17	Controller	smtp.office365.com	587	TCP	Outbound	Optional	SMTP email alerts (if no local SMTP server)
18	Controller	Internet — ip-api.com	443	TCP	Outbound	Optional	IP geolocation service
19	Controller	Internet — *.cloudmon.ai	443	TCP	Outbound	Required	Cloudmon site
20	Linux Probe	Internet — ip-api.com	443	TCP	Outbound	Optional	IP geolocation service for the Probe

Connectivity Validation

After the required firewall rules are implemented, validate each applicable communication path from the actual source host. A successful test confirms that the network path and destination port are reachable; application-level authentication or feature configuration may still need separate validation. Replace anything in <angle brackets> with the actual hostname/IP for your environment.

1. nc, curl, tcpdump, and snmpget/snmptrap commands assume standard Linux net-tools/net-snmp packages are installed on the Probe

2. Test-NetConnection and Test-WSMan are built into PowerShell on Windows.

Check	From	To	Command	Expected Result
Cloudmon console	Admin browser	`Controller:443/TCP`	`curl -Ik https://<controller>`	HTTPS connection succeeds.
Probe → Controller	Linux/Windows Probe	`Controller:443/TCP`	`nc -zv <controller> 443` (Linux) `Test-NetConnection <controller>` `-Port 443` (Windows)	Connection succeeds.
Controller → MongoDB	Controller	`MongoDB:27017/TCP`	`nc -zv <mongodb-host> 27017`	TCP connection succeeds when MongoDB is remote.
SNMP polling	Linux Probe	`Device:161/UDP`	`snmpget -v2c -c <community>` `<device-ip> sysDescr.0`	SNMP query succeeds if SNMP monitoring is enabled.
Syslog	Network device	`Linux Probe:514/UDP`	`tcpdump -ni any udp port 514` (run on Probe while device exports syslogs)	Syslog messages are received if Syslog collection is enabled.
SNMP Trap	Network device	`Linux Probe:162/UDP`	`snmptrap -v2c -c public` `<linux-probe-ip>:162 ''` `1.3.6.1.4.1.8072.2.3.0.1`	SNMP traps are received if trap collection is enabled.
NetFlow	Network device	`Linux Probe:2055/UDP`	`tcpdump -ni any udp port 2055` (run on Probe while device exports flows)	Flow records are received if NetFlow collection is enabled.
WMI	Windows Probe	`Windows target:135/TCP + dynamic ports`	`Test-NetConnection <target> -Port` `135` `Get-WmiObject -ComputerName` `<target> Win32_OperatingSystem`	WMI connection succeeds if WMI monitoring is enabled.
VMware	Linux Probe	`vCenter:443/TCP`	`curl -Ik https://<vcenter>`	HTTPS connection succeeds if VMware monitoring is enabled.
Hyper-V	Agent	`Hyper-V host:5985(6)/TCP`	`curl -I` `https://<hyperv-host>:5985/wsman`	WinRM connection succeeds if Hyper-V monitoring is enabled.
Nutanix	Linux Probe	`Prism:9440/TCP`	`curl -Ik https://<prism-ip>:9440`	HTTPS connection succeeds if Nutanix monitoring is enabled.
Cloud (AWS/Azure/ GCP/OCI)	Linux Probe	`Cloud API endpoint:443/TCP`	`curl -Iv` `https://<cloud-api-endpoint>`	HTTPS connection succeeds if the corresponding cloud integration is enabled.

Validation note:

1. Run only the checks applicable to the deployment and features in use.

2. For WMI, TCP port 135 and the configured Windows dynamic RPC port range must be reachable from the Windows Probe to the target.

3. For Windows Event Log collection, WinRM (TCP 5985 for HTTP, or 5986 for HTTPS) must be reachable from the Windows Probe to the target — this is a separate port range from WMI/RPC.

5. For inbound Syslog, SNMP Trap, and NetFlow, validate from the network device toward the Linux Probe.

Ready for Device Onboarding

Cloudmon is network-ready when the required connectivity paths for the selected deployment model and enabled features are permitted and successfully validated. Use the firewall rules above as the change-request reference, then perform the applicable connectivity checks to confirm reachability before proceeding with deployment or feature configuration.