Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

Why do I need udp/161 service to be running on the SolarWinds NPM/NTA server?

adamscottmaster2013

I had an argument with SolarWinds TAC support, and I am hoping experts in this forum can clarify it for me.

Scenario: I installed SolarWinds Orion Network Performing Monitor (NPM) & NetFlow Traffic Analyzer (NTA) on a Windows 2022 server, and I am going through the documentation on the port(s) requirements to be allowed on the server for both inbound and outbound based on this provided documentation: https://documentation.solarwinds.com/en/success_center/orionplatform/content/core-orion-requirements-sw1916.htm

In the documentation, it stated that UDP/161 must be running on the SolarWinds server in order to send & receive SNMP information:

161

UDP

SolarWinds Job Engine v2

SolarWinds Cortex

Bi-
directional

Send and receive SNMP
information

SNMP v1 and v2 are unencrypted. SNMP v3 uses AES and 3DES encryption.

The SolarWinds TAC engineer stated that SNMP udp/161 must be listening on the SolarWinds server in order for it to query Cisco network devices.

I told the TAC engineer that he is full of B.S. because I do NOT need udp/161 to be listening on the SolarWinds in order for the SolarWinds NPM to request SNMP query from Cisco Devices. In other words, I do not need snmp service udp/161 to be running on the SolarWinds server to do snmpget/snmpwalk with Cisco devices. Therefore, I do not need udp/161 inbound access from Cisco devices to SolarWinds server, I only need outbound snmp udp/161 access from SolarWinds to Cisco devices. The snmp return traffic is automatically allowed due to "stateful" inspection.

Who do you think is in the right? The SolarWinds TAC engineer or me?

TIA.

Find more posts tagged with

Comments

Deltona

Unless you are using a stateful firewall in between the SolarWinds server and your SNMP devices, then the return trafic will be blocked unless you have a rule/policy/access list to allow it.

adamscottmaster2013

"Unless you are using a stateful firewall in between the SolarWinds server and your SNMP devices, then the return trafic will be blocked unless you have a rule/policy/access list to allow it."

@Deltona: Not sure if you read the entire thread but this is what I put in the original thread: The snmp return traffic is automatically allowed due to "stateful" inspection.

cnorborg

Well, remember that UDP is a connectionless protocol. So, when SNMP sends a query out to a box, there is no two-way connections made, so no real stateful connection. Most stateful firewalls will do pseudo-statefull thing where they allow return traffic on the same UDP port as outbound traffic. However, you are much safer to explicitly allow your inbound UDP connections.

So, while the return traffic might be allowed through a firewall, there is no "connection" made between the Solarwinds server and the remote box. Instead, Solarwinds has to listen to port 161 to receive the return traffic for the queries it made. Now, the Solarwinds server IS your SNMP sender and receiver, so you don't need a separate service running for it. But, you can't block UDP/161 inbound on windows firewall for instance and have the returned queries come through on the "connection" because it doesn't exist like it would if it was a TCP connection.

Now, that being said, you mentioned NTA in the subject, so a little on that. NTA uses Netflow, usually on UDP port 2055. You can receive netflow on your Solarwinds server without having SNMP set up, however, the information you receive is rather disconnected and useless. Without SNMP up and running, NTA can't relate the Netflow data to a specific interface. So you get really weird results. So, while you can get Netflow data without managing the devices via SNMP, I highly recommend not trying to do this!!

adamscottmaster2013

@cnorborg - This statement is completely wrong: "Instead, Solarwinds has to listen to port 161 to receive the return traffic for the queries it made."

SolarWinds does not have to listen to udp/161 in order to receive return udp/161 traffic from Cisco devices.

SolarWinds NPM — Firewall — Cisco device

Now SolarWinds sends an SNMP request on udp/161 to the Cisco device. As long as outbound is allowed on the firewall to reach the Cisco device, the udp/161 return traffic is allowed to return back to the SolarWinds NPM due to the "stateful" connection nature of the firewall. We are NOT talking about basically layer-3 Cisco Access Control List (ACL). In the case of ACL, yes, you need explicit rule for return traffic to come back, but not when you have Palo Alto, Checkpoint, Cisco FTD firewalls, or Cisco CBAC (Context-Based Access Control).

That's just standard how of SNMP works.

As far as NetFlow NTA is concerns, udp/2055 is listening on the SolarWinds server and functions as NetFlow Collector Service, as confirmed with "netstat -an | findstr 2055", yes, you need inbound FW rule from Cisco devices that export Netflow to NTA.

I've discussed with ten different Cisco CCIE experts, and they all said that the SolarWinds documentation is just wrong.

superfly

Sorry but who really cares? If you don't believe the documentation then don't configure it that way. You are wasting a lot of energy on this when at the end of the day, YOU can choose what to configure.

You should really just move as there are much better things to be wasting your time on than this.

But I did find this which you may or may not find interesting. Really though, you should let it go.

stuartd

LOL - love this reply.

stuartd

I've discussed with ten different Cisco CCIE experts,

I've also stood in a room with 4 CCIE's who couldn't work out that an interface wasn't passing traffic because it was shutdown.

YMMV 😉

cnorborg

Yea, you might want to go look up how a stateful firewall handles UDP traffic since it is by design a stateless protocol. The firewalls create temporary pseudo-states, as I mentioned before, to allow the return traffic for a period of time. But, they do NOT track an actual state like they would with a TCP connection.

And SNMP works just like any other UDP traffic. A server sends out SNMP requests via this connectionless UDP protocol. And that same server has to listen on port 161 to hear the responses. Its not like a TCP connection where once the 3-way handshake is done there is an established connection it can listen to replies on, usually on a random high port. With most UDP traffic, and with standard implementations of SNMP for sure, the response comes back on the same port and the receiver of the traffic has to be listening on said port for incoming connections. And, as with all UDP traffic, there is no guarantee for delivery in either direction. With TCP once the connection is established, if a packet is missed or out of order, TCP will handle getting it retransmitted. With UDP, neither the outbound packet, or the response(s) are guaranteed to get where they want to be, nor will the UDP protocol do anything to correct anything. And I did say with this pseudo-state that statefull firewalls give UDP traffic, that you probably don't need the port open, but that its probably smart to go ahead and explicitly allow it.

Check out the requirements for NPM on what ports it needs, UDP 161 it requires it bidirectionally. Why would it require this port bidirectionally if it wasn't going to listen to it?

https://documentation.solarwinds.com/en/success_center/orionplatform/content/core-solarwinds-port-requirements.htm

Better yet, try running wireshark on your server and watch what goes on, I have. Any TCP connections, like SSH with NCM show the state information right in the packet. You will also see SNMP traffic going both ways, and no state information in any given packet.