The short answer
A network port is a 16-bit number (0 to 65535) that lets a single IP address run many services at once: the IP address gets the packet to the right machine, and the port gets it to the right program on that machine. Ports fall into three ranges defined by IANA: well-known (0-1023) for standard services like HTTP, DNS, and SSH; registered (1024-49151) for vendor and application services; and dynamic or ephemeral (49152-65535), which the operating system assigns on the fly to the client side of every outbound connection. Critically, every port also belongs to a transport protocol, and TCP 80 and UDP 80 are two completely separate ports. TCP is connection-oriented and reliable, using a three-way handshake with ordering and retransmission, which is why the web, email, file transfer, and remote desktop ride on it. UDP is connectionless and lightweight with no handshake or delivery guarantee, which is why DNS lookups, DHCP, VoIP audio, SNMP, and video streaming prefer it, since for those a late packet is worse than a lost one.
For low-voltage and field IT work, the short list you actually reach for is small: 80 and 443 for device web interfaces, 22 for SSH, 3389 for RDP, 554 for RTSP camera streams, 5060 for SIP phone signaling, 53 for DNS, 67 and 68 for DHCP, and 161 and 162 for SNMP monitoring. IP-camera and DVR/NVR gear then layers vendor-specific ports on top, such as Hikvision's 8000 SDK/service port, Dahua's 37777, and ONVIF device discovery on UDP 3702. VoIP splits its work in two: signaling on 5060, and the actual audio on RTP across a wide range of negotiated UDP ports. Two rules save the most time on site. First, defaults are conventions, not laws; any port can be reassigned, so always verify the device's real configuration rather than trusting the number in a manual. Second, most 'it won't connect' calls are a firewall or port-forward rule with the wrong protocol, or a missing media-port range, not a broken device.
How Ports Work: Ranges, TCP vs UDP
A port number identifies a specific service endpoint at an IP address. When a laptop opens a web page, it sends packets to the server's IP on destination port 443, while the laptop's own side of the conversation uses a random high-numbered source port that the OS picks from the ephemeral range. The four values of source IP, source port, destination IP, and destination port form the socket pair that uniquely identifies that one connection, which is how a single PC can hold dozens of simultaneous sessions to the same server without them getting crossed.
The protocol matters as much as the number. TCP establishes a connection with a SYN, SYN-ACK, ACK handshake, then guarantees that bytes arrive in order and retransmits anything lost. That reliability costs round-trips and overhead, which is fine for web pages, files, and logins but poor for live media. UDP just fires datagrams with no handshake, no ordering, and no retransmission, so it is the right tool for real-time audio and video, DNS queries, and telemetry where the application would rather drop a stale packet than wait for it. Some protocols use both: DNS answers over UDP 53 but falls back to TCP 53 for large responses and zone transfers, and HTTPS is TCP 443 for classic TLS but UDP 443 when a browser negotiates QUIC / HTTP/3.
Because ports are per-protocol and per-IP, the same number can be reused safely in different contexts. Two listeners cannot both bind TCP 443 on the same IP, but TCP 443 and UDP 443 coexist, and two different IPs on one host can each bind 443 independently.
- 16-bit range: 0 to 65535, split into well-known (0-1023), registered (1024-49151), and dynamic/ephemeral (49152-65535)
- TCP 80 and UDP 80 are distinct ports; the protocol is part of the identity
- TCP = connection-oriented, ordered, reliable (web, mail, files, RDP)
- UDP = connectionless, low-overhead, no guarantees (DNS, DHCP, VoIP audio, SNMP, streaming)
- Ephemeral source ports: Windows uses 49152-65535, Linux typically 32768-60999
- A connection is uniquely keyed by source IP + source port + destination IP + destination port
Everyday IT Ports: Web, Remote Access, and Mail
These are the ports that show up on nearly every job. Web interfaces for switches, access points, controllers, cameras, and NVRs live on HTTP 80 and HTTPS 443, and modern gear increasingly redirects 80 to 443 or drops plain HTTP entirely. Remote access is dominated by SSH on TCP 22 (which also carries SFTP and SCP), RDP on TCP 3389 with an optional UDP 3389 channel that improves performance over lossy links, and VNC starting at TCP 5900, where the display number is added to the base port so :1 is 5901.
Avoid Telnet on TCP 23 wherever you can; it transmits credentials in cleartext and exists mostly on legacy console gear. File transfer legacy still appears too: FTP uses TCP 21 for control and TCP 20 for active-mode data, while passive mode negotiates high data ports. Prefer SFTP over SSH (port 22) instead.
Mail has a cluster of ports worth memorizing because misconfigured submission is a frequent support call. SMTP 25 is server-to-server relay and is often blocked outbound by ISPs; mail clients should submit on 587 with STARTTLS or 465 with implicit TLS. Retrieval is IMAP 143 or POP3 110 in the clear, with the encrypted equivalents on IMAPS 993 and POP3S 995. File sharing over SMB uses TCP 445 (the legacy NetBIOS path was 139).
- 22/TCP — SSH, SFTP, SCP: encrypted remote shell and file transfer
- 23/TCP — Telnet: legacy, cleartext, avoid on anything modern
- 80/TCP & 443/TCP — HTTP / HTTPS: device web UIs (443 also UDP for QUIC/HTTP-3)
- 3389/TCP (+UDP) — RDP: Windows Remote Desktop; 5900+/TCP — VNC
- 25/TCP — SMTP relay; 587/TCP — submission (STARTTLS); 465/TCP — SMTPS (implicit TLS)
- 143/993 — IMAP/IMAPS, 110/995 — POP3/POP3S; 445/TCP — SMB file sharing; 21/20 — FTP control/data
IP Camera, DVR, and NVR Ports
Surveillance is where port knowledge earns its keep. The universal one is RTSP on TCP 554, which carries the stream-control commands (DESCRIBE, SETUP, PLAY). The video and audio themselves travel as RTP, either over dynamically negotiated UDP ports or interleaved back over the same TCP 554 connection when a firewall would otherwise block the media. A working RTSP URL such as rtsp://user:pass@ip:554/stream is the fastest way to prove a camera is delivering video independent of the recorder or app.
Beyond RTSP, every recorder brand adds its own service ports. Hikvision exposes HTTP 80, RTSP 554, HTTPS 443, and an 8000 TCP server/SDK port used by its clients and mobile apps. Dahua uses HTTP 80, RTSP 554, a 37777 TCP media/SDK port and a 37778 UDP port. Many white-label Chinese DVRs (XMeye / NetSurveillance family) use a 34567 TCP media port alongside HTTP 80. Because these defaults are freely reassignable in the device menu, always confirm the live values before opening firewall rules.
ONVIF, the interoperability standard, runs its device services over HTTP on a configurable port and is discovered on the LAN via WS-Discovery, a multicast probe to 239.255.255.250 on UDP 3702. That multicast does not cross subnets or VLANs by default, which is the usual reason an NVR on one VLAN cannot auto-find cameras on another.
- 554/TCP — RTSP: stream control for nearly all IP cameras; media rides RTP on negotiated UDP ports
- 3702/UDP — ONVIF WS-Discovery multicast; will not cross VLANs without a relay
- 80/443 — camera and recorder web UIs (HTTP/HTTPS)
- Hikvision — 8000/TCP SDK-service port (plus 80, 554, 443)
- Dahua — 37777/TCP and 37778/UDP media ports (plus 80, 554, 443)
- Generic XMeye/NetSurveillance DVRs — 34567/TCP media port; all defaults are reassignable, so verify on the device
VoIP Ports: SIP Signaling and RTP Media
VoIP trips up techs because it separates the call setup from the call audio, and they use different ports and often different protocols. SIP handles signaling (register, invite, ring, hang up) on 5060, available over both UDP and TCP, with TLS-encrypted SIP on 5061 (TCP). Getting SIP working only proves phones can register and calls can ring, not that anyone can hear anything.
The audio is carried by RTP over UDP on a range of high ports that the PBX and endpoints negotiate per call, with RTCP alongside for stream statistics. Different platforms default to different ranges: Asterisk commonly uses UDP 10000-20000, FreeSWITCH uses 16384-32768, and Cisco often uses 16384-32767. The classic symptom of a firewall that forwards SIP 5060 but not the RTP range is a call that connects with one-way or no audio.
Because RTP is UDP and stateless, NAT and firewalls need help keeping the media path open. Session border controllers, SIP ALG (frequently better left disabled, since a buggy ALG rewrites packets and breaks registration), and STUN/TURN all exist to solve this. When troubleshooting, confirm both that 5060 signaling is open and that the full RTP UDP range is forwarded end to end.
- 5060/UDP (and TCP) — SIP signaling; 5061/TCP — SIP over TLS
- RTP media — dynamic UDP, commonly 10000-20000 (Asterisk) or 16384-32767 (FreeSWITCH/Cisco)
- One-way or no audio almost always means the RTP UDP range is not forwarded
- SIP ALG on the router often breaks VoIP; disabling it is a common fix
- Legacy/related: 1720 H.323, 2000 Cisco SCCP (Skinny), 5061 for TLS signaling
- Open signaling AND media: 5060 alone is not enough for a working call
Infrastructure and Management Ports
These ports keep the network itself running and are what you monitor and log against. DNS answers name lookups on UDP 53 and switches to TCP 53 for large records and zone transfers. DHCP hands out addresses using UDP, with the server listening on 67 and clients on 68. TFTP on UDP 69 still shows up for phone provisioning and firmware pushes, and NTP keeps clocks in sync on UDP 123, which matters more than techs expect because expired TLS certs and broken logs often trace back to a device with the wrong time.
Management and telemetry cluster together. SNMP polls devices on UDP 161 and receives asynchronous traps and informs on UDP 162; use v3 for authentication and encryption rather than v1/v2c community strings. Syslog ships event logs on UDP 514 traditionally, with TCP 514 and TLS 6514 as reliable and encrypted alternatives. Directory and authentication services use LDAP on 389 and LDAPS on 636 (with Active Directory global catalog on 3268/3269), Kerberos on 88, and RADIUS for 802.1X and network access control on UDP 1812 for authentication and 1813 for accounting (older gear may still use 1645/1646).
Knowing these lets you write precise firewall and monitoring rules instead of blanket allows, and lets you spot anomalies: SNMP traffic from an unexpected host or syslog going to an unknown collector is worth investigating.
- 53 — DNS: UDP for queries, TCP for large responses and zone transfers
- 67/68 — DHCP: UDP, server on 67 and client on 68; 69 — TFTP provisioning
- 123 — NTP: UDP time sync (time drift breaks certs and logs)
- 161/162 — SNMP: UDP poll / trap (prefer v3 for security)
- 514 — Syslog: UDP (TCP 514, TLS 6514 for reliable/encrypted)
- 389/636 — LDAP/LDAPS; 88 — Kerberos; 1812/1813 — RADIUS auth/accounting (UDP)
Field Notes: Forwarding, Firewalls, and Security
The most common remote-access failure is a NAT port-forward with the wrong transport. If a rule forwards TCP but the service is UDP (SIP media, SNMP, DNS), it silently fails. Match the protocol exactly, and remember that some services need both a control port and a separate media or data range opened, cameras and VoIP being the prime offenders. Double-NAT and carrier-grade NAT (CGNAT) will also defeat port forwarding entirely, because the public IP is not on the customer's own router; a VPN or a vendor cloud relay is the fix there.
Do not expose DVRs, NVRs, or RTSP directly to the internet with a naked port-forward. These devices are relentlessly scanned and brute-forced (the Mirai botnet was built largely on exposed cameras and default credentials). Prefer a client-to-site or site-to-site VPN so the management and RTSP ports never touch the public internet, and disable UPnP on the router so devices cannot auto-open holes in the firewall without your knowledge.
Changing a service off its default port (moving SSH off 22, a DVR web UI off 80) reduces automated scan noise, but it is obscurity, not security; it must sit on top of strong passwords, current firmware, and least-privilege firewall rules, never instead of them. Whatever you change, document it, because the next tech will assume defaults and lose an hour proving the device is 'down' when it is simply listening somewhere else.
- Match the protocol: forwarding TCP when the service is UDP is a silent, common failure
- Open every port a service needs (SIP + RTP range, RTSP + RTP), not just the obvious one
- CGNAT / double-NAT breaks port forwarding — use a VPN or vendor relay instead
- Never expose DVR/NVR/RTSP directly to the internet; put remote access behind a VPN
- Disable router UPnP so devices cannot silently open firewall pinholes
- Non-default ports cut scan noise but are not security on their own — always document what you changed
Frequently asked questions
Is port 443 always TCP?
Traditionally yes: HTTPS runs over TLS on TCP 443. But HTTP/3 uses the QUIC protocol, which runs over UDP, typically on UDP 443. So a modern browser and server may communicate on UDP 443 while still falling back to TCP 443 when QUIC is blocked. When writing firewall rules for HTTP/3-capable services, allow 443 on both protocols.
My camera streams fine on port 554, so why can't I view it remotely?
RTSP on 554 only carries the stream-control commands. The actual video and audio travel as RTP on separate, dynamically negotiated UDP ports (or interleaved back over the TCP 554 connection). A remote viewer that can reach 554 but sees no picture usually has the RTP media path blocked. The better fix is not to open more ports to the internet but to put the camera behind a VPN, since exposed RTSP and DVR ports are heavily scanned and brute-forced.
Can two services use the same port number at once?
It depends on the protocol and IP. A port is bound per IP address and per transport protocol, so TCP 8000 and UDP 8000 are separate ports and can both be in use. Two different IP addresses on the same host can each bind the same port independently. What you cannot have is two listeners bound to the same IP, same protocol, and same port at the same time (barring special load-balancing socket options).
What's the difference between SFTP and FTPS ports?
They are unrelated protocols despite similar names. SFTP is the SSH File Transfer Protocol and runs inside an SSH session on TCP 22, so it needs only that one port. FTPS is classic FTP wrapped in TLS: implicit FTPS uses TCP 990 for control, while explicit FTPS (FTPES) starts on the normal FTP control port 21 with an AUTH TLS command, and both then negotiate separate data ports. SFTP is usually easier through firewalls because it uses a single, fixed port.
Should I change devices off their default ports for security?
Moving a service off its well-known port (for example SSH off 22 or a DVR web UI off 80) reduces automated scanning and log noise, but it is security through obscurity, not real protection. It has to sit on top of strong unique passwords, current firmware, and tight firewall rules, never replace them. And whatever you change, document it, or the next technician will assume defaults and waste time thinking the device is offline.
