Firewall Connectivity Guide
  • 06 Sep 2023
  • 11 Minutes to read
  • Dark
    Light
  • PDF

Firewall Connectivity Guide

  • Dark
    Light
  • PDF

Article summary

The purpose of this document is to give the technical personnel some basic guidelines on the connectivity requirements of Netreo. It applies to all on-premise deployments of the Netreo software (whether as a Service Engine supporting a SaaS-based solution or as a fully-deployed stand-alone solution).

If you have any questions, please contact Netreo Support at support@netreo.com for an immediate response. 

While this guide will cover the vast majority of use-cases, custom configurations may add additional connectivity requirements that are unique to a customer’s environment. For additional information on firewall requirements, please see Firewall Requirements. For additional details on the protocols and polling methods used by Netreo, please see Deployment Specifications.

The basic architecture used is that local network information is collected through the use of one or more dedicated virtual appliances (VA) deployed within the customer environment. In a SaaS solution, data is collected by a streamlined version of the Netreo VA acting as a dedicated "Service Engine" (SE) and streamed outbound from the customer environment to Netreo's cloud servers. In a stand-alone solution, data is collected by a fully deployed Netreo VA, which acts as both a UI server (for interacting with the product) and a Service Engine. Dedicated Service Engines may be configured to collect polling/statistical data, NetFlow and traffic data, or syslog data - or any combination of these (a fully-deployed Netreo VA always collect all of this data). The exact configuration of a particular SE will dictate the connectivity requirements for it and how much bandwidth it will consume.

General Firewall Requirements

Basic IP connectivity from the Netreo VA to the managed devices is necessary to monitor the systems for availability in Netreo. This basic level of IP connectivity requires that Netreo be able to Ping (ICMP ECHO) the managed devices. In addition to Ping, Netreo requires connectivity to a DNS server(internal) as well as an NTP server (external or internal) so that name/IP resolution is possible and so that Netreo’s clock can remain synchronized.

For basic connectivity allow:

  • ICMP (echo, echo-reply, ttl exceeded) to all monitored devices from the Netreo VA.
    • NOTE: if ICMP is not an option for particular devices, Netreo can be configured to use any TCP port to determine device availability.
  • DNS: Port TCP/UDP/53 (originating from the Netreo VA to any/all internal DNS servers).
  • NTP: Port UDP/123 (originating from the Netreo VA to any/all internal NTP servers).
  • For UI access to a stand-alone deployment: from internal management systems/users to destination TCP/443 on the Netreo VA.
  • For UI access to a Service Engine (only required for troubleshooting and initial deployment): from internal management systems/users to destination TCP/443 on the Netreo VA.

For remote technical support and customization allow:

  • FQDN: charon.netreo.net
  • Port: TCP/443

In unusual cases, Netreo can be configured to use an alternate port instead by contacting our support team. Check the Systems Diagnostics page in Netreo for the configured port and protocol on your system if you have made this change.

(Application-aware firewalls will need this configured as SSL/TLS and OpenVPN.)

For automatic Netreo licensing allow:

  • FQDN: activation.netreo.net
  • Port: TCP/443

For software update support allow:

  • FQDN: updates.netreo.net
  • Port: TCP/80
  • Port: TCP/443

For geocoding information used by Netreo's Geographic Map allow outbound access from the Netreo VA to:

  • api.geonames.org
  • dev.virtualearth.net

Netreo Mobile and Cloud features

Netreo uses a wide variety of dynamic technologies to route and assign users to the best or closest cloud-hosted server, so it is not possible to restrict access to a group of IP addresses. Netreo recommends allowing outbound access for SSL/TLS or HTTPS on port 443. If your firewall allows you to restrict access by domain name, you can use the following destinations (all are port TCP/443):

  • *.api.netreo.com
  • *.rr.netreo.com

Alerting

Netreo sends various kinds of alert notifications that can be configured by the customer. Each of these alerts requires connectivity from the Netreo VA.

  • Email alerts require SMTP (which use the ports listed below) originating from the Netreo VA. An SMTP proxy can be configured if you do not wish to allow direct outbound SMTP access to outside servers (for example, directly alerting to gmail or to a cellular messaging system). However, the use of an SMTP relay can create a single point of failure for email-based alarms, and it is recommended that you configure alternative alerting mechanisms to handle these cases when using a relay. The following options are available when configuring Netreo's mail delivery system (Administration > Alerts > Mail Setup).
    • Direct SMTP uses port TCP/25 on the mail server.
    • Relay SMTP uses port TCP/25 on the mail server.
    • SMTP Authenticated Relay (Office 365) uses port TCP/587 on the mail server.
  • Mobile device push notifications: TCP/443 from the Netreo VA to api.netreo.com and *.api.netreo.com. The large number of potential end points used for redundancy and load balancing mean a specific list of IP addresses cannot be provided.
  • Webhooks (Slack, Teams, OpsGenie, ITSM ticket creation, etc.) typically require TCP/443 from the Netreo VA to the API endpoint address. Please consult the documentation for an individual service to confirm the destination required. 

Network Devices

(Routers, Switches, UPS, Load Balancers, Wireless, Firewalls, etc.)

Netreo uses SNMP to collect data from network devices. Your devices should be configured to respond to SNMP from the IP address of the Netreo appliance. Only read-only access is required. Netreo recommends SNMPv2c for best performance, though all versions of SNMP are supported. 

Netreo incorporates a device configuration manager used for backing up device configurations and tracking changes, and will need privileged login credentials to these devices in order to use the configuration management features. See the “Configuration Management” section in this document for more information on this capability.

Firewall Settings

  • SNMP: Port UDP/161 for polled data collection.
  • SNMP Traps: UDP/162 (originating from the device to the Netreo VA).
  • Special Cases:
    • Palo Alto Firewall: Hybrid SNMP UDP/161 and SSH TCP/22 for full instance monitoring.

Windows Servers

Netreo uses the WMI, WinRM and PowerShell protocols to collect data from Windows servers. WMI is enabled by default on all versions of Windows since 2003. WinRM is installed by default on Windows servers since 2008, but must be enabled manually in early versions. The primary difference is that WinRM uses a single port for data collection, which is much simpler to configure if the traffic has to traverse a firewall.

Either of these requires an account with local administrator privileges or DCOM permissions on the device to be managed. See Windows Device Monitoring and Management for more information on how to use non-administrator accounts to access Windows statistics.

This connectivity is also required for collecting Windows Event Logs and Windows service management and monitoring.

Firewall Rules

  • WMI: Destination port TCP/135 on the device to be managed, originating from the Netreo VA, and all high ports (1024-65535) bi-directionally.
  • WinRM: Destination port TCP/5985 or TCP/5986, originating from the Netreo VA.

For more information about WinRM ports, see Windows Device Monitoring and Management.

MS SQL

Most statistical data about the health and performance of MS SQL is collected via WMI or WinRM using the standard connectivity detailed for Windows Servers (above). 

However, Netreo also supports custom monitoring via SQL queries directly to the database. In these cases, connectivity to the SQL port(s) from the Netreo VA will be required.

Firewall Rules

  • WMI: Destination port TCP/135 on the device to be managed, originating from the Netreo VA, and all high ports (1024-65535) bi-directionally.
  • WinRM: Destination port TCP/5985 and TCP/5986, originating from the Netreo VA.
  • SQL:  
    • Default instance: Destination port TCP/1433, TCP/1434 and UDP/1434, originating from the Netreo VA.
    • Custom or named instances will require access to the destination port specified in the database, or to TCP/1024-65535 for dynamically named instances.

Linux/Unix Servers

For these devices Netreo uses SNMP and the Host Resources MIB to collect data from Linux/Unix servers. Most of these servers include a package called “net-snmp” to provide SNMP access for management systems. Make sure this package (or similar) is installed and the agent (snmpd) is running. 

Firewall Rules

  • SNMP: Destination port UDP/161 on the device to be managed, originating from the Netreo VA, for polled data collection
  • SNMP Traps: Destination port UDP/162, originating from the device to the Netreo VA.
  • Special Cases:
    • SSH-based Linux polling: Destination port TCP/22 from the Netreo VA. (Note: SSH-based Linux polling is not recommended unless no alternatives exist.

Special Case: Linux SSH Device Type Configuration

Warning: Netreo supports using SSH to poll Linux. However, we don't recommend this process. Although it's fully functional, it creates a higher system load on both parties, the Netreo and the system being monitored.

To get started, download the "Linux via SSH" device type from the cloud library. Ensure that the monitored system is set to that type and the account's credentials are configured (e.g., username, password). It must have read permissions to the /proc filesystem and execute the disk files (df) and grep commands and ethtool utility. 

VMware vCenter

Netreo uses the APIs provided by VMware to collect metrics for virtual resources in vCenter.

Firewall Rules

  • Destination port TCP/443 on the vCenter to be managed, originating from the Netreo VA.

Cloud Resources (AWS, Azure, GCP)

Netreo uses the APIs provided by the various cloud services to collect metrics for, and automatically discover, resources within those cloud services. This requires outbound access from the Netreo VA to the relevant cloud API endpoints, typically on TCP/443. Please consult your cloud provider documentation for their current list of API endpoints.

Firewall Rules

  • Destination port TCP/443 (or another specified port) on the cloud provider API to be managed, originating from the Netreo VA.

Syslog

Netreo collects all syslog messages broadcast to it. The biggest issue with syslog is that it can generate a large number of messages, obscuring important details with routine or trivial ones. Netreo does recommend configuring syslog on critical infrastructure devices, but that you configure those devices to limit the messages sent to warning level or higher.

Recommendations

  • Create syslog alert rules in device templates to generate alerts for syslog messages.
  • Limit syslog messages being sent to Netreo to warning level or higher.
  • In general, do not send syslog messages from firewalls to Netreo, as it is not designed to be a dedicated high-volume log-processing tool.

Firewall Rules

  • Syslog uses destination port UDP/514, originating from the device to the Netreo VA.

Configuration Management/Looking Glass

Netreo provides device configuration management (push/pull) as well as real-time command execution (Looking Glass and active response) to devices.

Netreo can use either SSH or Telnet to connect to CLI devices for these features. Where possible, the use of SSH is recommended since it includes encryption functionality. Telnet is insecure and should only be used if the device under management does not support SSHv2. Netreo does not support the SSHv1 protocol, as it is insecure and obsolete.

Recommendations

  • Use SSH where supported by the device under management.
  • Do not use Telnet unless no alternatives exist, as it is insecure.
  • If your environment uses a centralized login manager, such as Radius or TACACS for authentication, use a dedicated Netreo account to manage access.
  • If you are using filters or access lists to restrict CLI access be sure to include the specific IP address of the Netreo VA.

Firewall Rules

  • SSH requires destination port TCP/22 on the device to be managed, originating from the Netreo VA.
  • Telnet requires destination port TCP/23 on the device to be managed, originating from the Netreo VA.

Synthetic Checks

Netreo includes functionality for synthetic testing of web and email applications. Synthetic tests simulate user traffic in an application to measure response time and functionality. Email checks may involve sending mail out to local servers or servers on the internet, and retrieving that mail from a local or remote server. Your exact configuration dictates the firewall rules required. Both web and email checks may be initiated directly from the Netreo VA, or via a series of “remote reflectors” that Netreo maintains in data centers around the world.

Firewall Rules:

  • Web application synthetic checks require destination port TCP/443 (or less commonly, TCP/80, or other custom web application ports)  on the devices to be monitored, originating from the Netreo VA
  • For email application synthetic checks:
    • Sending requires SMTP, which uses destination port TCP/25, TCP/587 or TCP/465 on the mail server (depending on your mail server configuration), originating from the Netreo VA
    • Receiving requires IMAP or POP, which uses a destination port based on your configuration. The most common ports are TCP/993 (IMAP) or TCP/995 (POP3)  on the mail server, originating from the Netreo VA (other ports are possible depending on configuration).
  • Synthetic checks using remote reflectors will also need TCP/443 access to rr.netreo.com and *.rr.netreo.com. The large number of potential end points used for redundancy and load balancing mean a specific list of IP addresses cannot be provided.

NetFlow/sFlow/IPFIX

Netreo supports NetFlow (version 5 or 9), sFlow, cFlow and IPFIX export from devices for traffic and protocol analysis and volume information.

When configuring flow technologies such as these, the goal is to configure the fewest number of exporters possible while still ensuring that Netreo can collect data on all the required traffic. While Netreo automatically detects and processes duplicate flows to avoid creating incorrect traffic counts, this is not always possible in complex network configurations (especially those involving NAT/PAT).

Firewall Rules

  • NetFlow, cFlow and IPFIX should to be sent to destination port UDP/2055 on the Netreo VA.
  • sFlow should be sent to destination port UDP/2056 on the Netreo VA.

Oracle SQL (Oracle, MySQL)

Netreo supports data collection from SQL and MySQL systems using a combination of SNMP or WMI/WinRM (depending on host OS) and direct connections to the SQL server. Connectivity from the Netreo VA to the SQL server on the applicable SQL port(s) is required.

Application-specific Monitoring

Netreo supports the use of custom application monitors which can check the status and availability of applications by simulating user traffic or executing custom commands. These applications vary widely and the exact connectivity requirements may vary (e.g., to monitor a custom application running on port 12345, that port must be enabled from the Netreo VA to the device being monitored). 

Typical use of application-specific monitors include DNS, HTTPS, FTP, SMB, print queues and custom applications unique to the customer environment.


Was this article helpful?