Netreo SaaS Service Engine Connectivity Preparation

Introduction

The purpose of this document is to give the technical personnel some basic guidelines on the connectivity requirements of Netreo to speed the implementation process. If you have any questions, please contact Netreo Support at support@netreo.com for an immediate response.

This document cannot be comprehensive, as custom configurations may add additional connectivity requirements that are unique to a customer’s environment. For additional documentation on firewall requirements see Deployment Specifications for more details on the protocols and polling methods.

The basic architecture used is that local information is collected through the use of one or more dedicated virtual appliances in the customer environment, known as service engines (SE). These service engines can be configured to collect polling/statistical data, NetFlow and traffic data, or syslog data. The exact configuration of a particular SE will dictate the connectivity requirements for it and how much bandwidth it will consume.

Global Firewall Requirements

Basic IP connectivity 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 will need connectivity to a DNS (internal) server as well as an NTP (external or internal) server so that Name/IP resolution is possible and so that Netreo’s clock can remain synced.

Outbound connectivity to the cloud management portal is required. This connectivity is used to sync on premise device telemetry and status with Netreo Cloud. This connectivity is also how the service engines receive software updates.

• TCP/443 outbound communication to connector.netreo.cloud.
  • This connection must be direct, without the use of a proxy.
• ICMP (echo, echo-reply, ttl exceeded) to all monitored devices from the SE.
• DNS: Port TCP/UDP/53 (originating from the SE to any/all internal DNS servers).
• NTP: Port UDP/123 (originating from the SE to any/all internal NTP servers).
• NOTE: if ICMP is not an option for particular devices, a Netreo SE can be configured to use any TCP port to determine device availability.
• For UI access to the SE (only required for troubleshooting and initial deployment) from internal management systems/users to destination TCP/443 on the SE.

Estimated Bandwidth Usage

We have estimated the bandwidth usage that can be expected inbound and outbound from cloud-connected service engines. Varying device types can attribute to more or less data being sent across, eg., Windows servers will typically use more data than standard SNMP network devices.

• Cloud to SE: ~56Kbps upload per SE.
• SE to Cloud: ~140-200 Kbps download per 1k managed devices per SE.

The use of traffic collection (NetFlow, etc) and logging (syslog, Windows event log) can potentially add significantly more upload data, which will vary based on the number of devices sending this information and the speed of the interfaces being monitored (in the case of traffic data).

Network Devices

(Routers, switches, UPS, load balancers, wireless, firewalls, etc.)

Netreo uses SNMP to collect data from these types of 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 also incorporates a device configuration manager used for backing up device configurations and tracking changes. Netreo will need privileged login credentials to these devices in order to use the configuration management features. See the “Configuration Management” section of this document for more information on this capability.

Firewall Implications:

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

Windows Servers

WMI, WinRM and PowerShell are protocols used 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.

Both of these require 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 service management and monitoring.

Firewall Implications:

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

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 SE will be required.

Firewall Implications:

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

Linux/Unix Servers 

For these devices Netreo uses SNMP and the Host Resources MIB. 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 Implications:

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

VMware vCenter 

To collect metrics for virtual resources in vCenter, Netreo uses the APIs VMware has made available for that purpose.

Firewall Implications:

• Destination Port TCP/443 on the vCenter to be managed, originating from the SE.

Syslog

Syslog is a protocol used to push messages on demand from the devices under management into Netreo. The biggest issue with syslog is that it can generate a large number of messages, obscuring important details with routine or trivial ones.

Netreo recommends configuring syslog on critical infrastructure devices, but that you configure those devices to limit the messages sent to warning level or higher.

Recommendations:

• Netreo will collect any syslog messages sent to it, but will not generate alerts for those messages unless you create syslog alert rules to do so.
• It's good practice to restrict the syslogs being sent to warning or more severe levels.
• Netreo recommends against sending syslogs from firewalls into Netreo, as it is not designed to be a dedicated high-volume log-processing tool.

Firewall Implications:

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

Configuration Management/Looking Glass

Netreo provides device configuration management (push/pull) as well as realtime 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, Netreo recommends the use of SSH, 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 SSHuser-documentation protocol, as it is insecure and obsolete.

Recommendations:

• Use SSH where supported by the device under management.
• Do not use Telnet or SSH1 unless no alternatives exist, as they are 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 SE.

Firewall Implications:

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

Synthetic Checks Sourced From SE 

Netreo supports synthetic application tests for web applications as well as for email servers, where the application will simulate user traffic to measure response time and functionality. Email checks may involve sending mail out to servers on the internet, or locally, and retrieving that mail from a local or remote server. Your exact configuration will dictate which firewall rules are required.

Firewall Implications:

• For email 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 SE.
  • 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 SE (other ports are possible depending on configuration).
• Web 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 SE.

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. Flow export technologies such as these cause the network devices (typically layer 3 devices like routers) to send "accounting level" information to Netreo (which includes source and destination address, port, protocol, and volume data) for reporting purposes, in order to provide deeper performance 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. Netreo automatically detects and processes duplicate flows to avoid creating incorrect traffic counts, but this is not always possible in complex network configurations (especially those involving NAT/PAT).

Firewall Implications:

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

Oracle SQL (Oracle, MySQL)

Netreo supports data collection from these systems with a combination of SNMP or WMI/WinRM (depending on host OS), in addition to direct connections to the SQL server. Connectivity from the SE to the SQL server on the applicable SQL port(s) is required for this monitoring.

Application-Specific Monitors

Netreo supports the use of custom application monitors which will 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 SE to the device being monitored).