Ports

Port 162: SNMP trap

Asynchronous alerts from devices to management systems.

Where you will see it: You will see this in scans, firewall rules, vulnerability reports, and service configs. Treat open ports as exposure points and verify the service is expected, hardened, and restricted.

What it is

UDP port 162 is used for SNMP traps and informs, which are unsolicited alert messages sent from devices to a management system. A port is a transport layer number used together with an IP address and a protocol such as TCP or UDP to direct traffic to the correct service on a host. A server process binds a socket to a port and listens, while a client typically chooses an ephemeral source port for outbound connections.

The combination of source and destination IP addresses, source and destination ports, and the transport protocol uniquely identifies a flow so the operating system can keep many conversations separate. Firewalls, NAT, and scanners talk about ports because the destination port is the stable rendezvous point that exposes a service to the network.

Instead of being polled, a device can push an event to the manager on destination port 162 when something happens such as link down, temperature alarms, or authentication failures. Because this is UDP, there is no connection setup, and reliability depends on the network and on whether informs with acknowledgements are used.

Operationally, traps are great for fast signal, but they are also easy to spoof if you accept them from anywhere, and they can create alert storms during outages. Understanding the port role makes it easier to debug monitoring gaps: if traps are missing, look for blocked UDP 162, misconfigured destinations, or overloaded collectors.

How it works in broad strokes

  1. A device detects an event and sends a trap message to the configured manager IP and port 162.
  2. The manager parses the OIDs and maps them to an alert or ticket.
  3. Some variants use inform messages that expect an acknowledgement, improving reliability.

Concrete example

A router interface goes down and immediately sends an SNMP trap to the NMS on 162, which creates an alert. If the trap never arrives, polling still shows the interface state change.

Why it matters

Traps are useful for fast detection, but they are also easy to spoof if you do not control where they come from. Misrouted traps can leak internal details, and missing traps can create blind spots if you rely on them too much.

Security angle

  • Allow traps only from known device IP ranges and prefer SNMPv3 where possible.
  • Combine traps with polling so you detect failures even if traps are lost.
  • Log and rate limit trap processing to avoid alert storms.

Common pitfalls

  • Accepting traps from any source, enabling spoofed alerts or noise flooding.
  • Assuming traps are reliable. UDP delivery can drop under congestion.
  • Not aligning trap configuration with monitoring and incident workflows.