VMware ESXi and vSphere Cluster Management

TCP and UDP Port Numbers

Learn how TCP and UDP port numbers identify application services, how client-server flows use source and destination ports, common port assignments, and port troubleshooting.

A port number is a 16-bit transport-layer value used by TCP or UDP to identify an application endpoint on a host. Port numbers let a computer deliver incoming traffic to the correct process or service.

An IP address identifies a host, such as a server or workstation, but it does not identify the application that should receive the traffic. A single host might run a web server, DNS service, email service, and SSH server at the same time. The transport-layer port distinguishes these services.

What a Transport-Layer Port Does

Both TCP and UDP headers contain a source port and a destination port. Each field is 16 bits long, so the complete numeric range is 0 through 65535.

  • Source port: The port associated with the sending application.
  • Destination port: The port associated with the receiving application or service.

For example, an HTTP client does not send traffic only to a server IP address. It sends traffic to a server IP address using TCP and destination port 80, unless the administrator has configured a different web-service port.

TCP and UDP Have Separate Port Namespaces

TCP and UDP use separate port namespaces. Therefore, TCP port 53 and UDP port 53 are different transport endpoints. A process using UDP port 53 does not automatically conflict with a process using TCP port 53.

A service may use TCP, UDP, or both, depending on its protocol design. DNS commonly uses UDP port 53 for ordinary queries and can use TCP port 53 for larger exchanges and zone transfers. The number 53 alone does not prove which transport protocol is being used or which application is present.

Port numbers are conventions and configuration values, not guaranteed proof of application identity. An administrator can configure a web server to listen on TCP port 8080 instead of TCP port 80, and another application can use a familiar port if the operating system and security policy allow it.

Client-Server Use of Ports

In the client-server model, a server application binds to a known local port and waits for requests. A listening port is a local port on which a server waits for incoming traffic.

A client sends traffic to three important destinations:

  • The server's IP address.
  • The transport protocol, TCP or UDP.
  • The server's service port.

The client normally selects a temporary locally available ephemeral port as its source port. This distinguishes that client's communication from other simultaneous communications.

When a server sends a response, the source and destination fields are reversed. The server sends from its service port to the client's temporary source port.

Socket Endpoints

A socket is an IP address paired with a port number. For example, 192.168.0.50:1200 identifies one socket endpoint.

A practical description of a TCP or UDP communication usually includes two socket endpoints and the transport protocol:

  • Client socket: 192.168.0.50:1200
  • Server socket: server-address:21
  • Protocol: TCP

Identifying a Flow: The Five-Tuple

A five-tuple is the combination of:

  1. Source IP address
  2. Destination IP address
  3. Source port
  4. Destination port
  5. Transport protocol

The five-tuple acts as a flow or session identifier. It allows a host, firewall, router feature, or packet analyzer to distinguish one communication from another.

Multiple clients can use the same service on one server at the same time. For example, two clients can connect to one web server at TCP port 443:

  • 192.168.0.10:50000 to 203.0.113.20:443 over TCP
  • 192.168.0.11:50001 to 203.0.113.20:443 over TCP

The destination service is the same, but the source IP addresses and source ports make the five-tuples different. The server can therefore associate each response with the correct client.

Port-Number Categories

Port ranges are commonly described using three categories. These categories describe registration and typical use; they do not by themselves determine whether a port is safe or active.

Range | Category | Typical use | Notes

0–1023 | Well-known | Common system and network services | Traditionally assigned to widely recognized services. Many operating systems restrict binding these ports to processes with elevated privileges.

1024–49151 | Registered | Registered application services | Assignments are maintained through the IANA service-name and port-number registry.

49152–65535 | Dynamic/private | Temporary or private use | Often used for ephemeral client ports, although operating-system allocation policies vary.

The IANA-defined dynamic/private range is 49152 through 65535. An operating system may select ephemeral ports from a different configured range, so do not assume every temporary client port falls in that exact range.

Common TCP and UDP Ports

The following list is useful for introductory networking and CCNA study. These are default assignments, not proof of the application running on a port.

Service | Transport protocol | Default port | Purpose

FTP control | TCP | 21 | File Transfer Protocol control channel

SSH | TCP | 22 | Secure remote command-line access

Telnet | TCP | 23 | Unencrypted remote terminal access

SMTP | TCP | 25 | Mail transfer between systems

DNS | UDP and TCP | 53 | Name resolution

DHCP server | UDP | 67 | Receives IPv4 address configuration requests

DHCP client | UDP | 68 | Receives IPv4 address configuration responses

TFTP | UDP | 69 | Simple file transfer

HTTP | TCP | 80 | Web traffic

POP3 | TCP | 110 | Email retrieval

NTP | UDP | 123 | Time synchronization

NetBIOS name service | UDP | 137 | Legacy NetBIOS name service

NetBIOS datagram service | UDP | 138 | Legacy NetBIOS datagram service

NetBIOS session service | TCP | 139 | Legacy NetBIOS session service

SNMP | UDP | 161 | Network monitoring and management queries

SNMP trap | UDP | 162 | Unsolicited network-management notifications

LDAP | TCP and UDP | 389 | Directory services

HTTPS | TCP | 443 | Encrypted web traffic

SMB over TCP | TCP | 445 | File and printer sharing

Syslog | UDP | 514 | Network logging

LDAPS | TCP | 636 | LDAP protected by TLS

RDP | TCP and UDP | 3389 | Remote Desktop Protocol

Worked Example: FTP Control Traffic

Assume an FTP client has IP address 192.168.0.50. The client selects temporary TCP source port 1200 and contacts an FTP server's control service at TCP port 21.

Direction | Source endpoint | Destination endpoint | Protocol | Meaning

Client to server | 192.168.0.50:1200 | FTP-server-IP:21 | TCP | The client requests the FTP control service.

Server to client | FTP-server-IP:21 | 192.168.0.50:1200 | TCP | The server returns traffic to the client application.

In the first packet, the source IP is 192.168.0.50, the destination IP is the FTP server address, the source port is 1200, the destination port is 21, and the protocol is TCP. In the reply, the endpoint roles reverse.

FTP data behavior can involve additional ports. Active and passive FTP modes use separate data connections, so advanced FTP troubleshooting should not be reduced to checking only TCP port 21.

Other Practical Examples

Two Web Clients

Two clients may connect to the same server at TCP port 443. Their different source IP addresses, source ports, or both produce different five-tuples. The server uses those identifiers to keep the connections separate.

DNS Transport Choice

A standard DNS query commonly uses UDP with destination port 53. DNS can also use TCP port 53 for larger exchanges or zone transfers. Testing only TCP 53 does not prove that UDP DNS traffic is permitted.

Firewall Rule Interpretation

A rule allowing outbound TCP traffic to destination port 443 permits clients to initiate traditional HTTPS connections. Return traffic is addressed to the client's temporary source port, and a stateful firewall normally permits that related response.

A rule allowing UDP destination port 53 is a separate rule from one allowing TCP destination port 53. Firewall policies commonly evaluate protocol, source and destination IP addresses, and source and destination ports.

Ports in Networking and Security

Ports help a host run multiple services simultaneously. A web server, SSH server, and DNS service can listen on different combinations of protocol and port. Two processes generally cannot bind the same IP address, protocol, and port combination at the same time unless the operating system and applications use specific socket-sharing behavior.

Ports are useful for:

  • Service discovery: Finding which applications appear to be listening.
  • Troubleshooting: Checking whether the configured service port is reachable.
  • Packet capture analysis: Reading source and destination ports to follow a flow.
  • Security: Limiting permitted applications with firewalls and access-control lists.
  • Network address translation: Tracking translations that may change IP addresses and ports.

Inspecting Ports on Hosts and Network Devices

Use commands appropriate to the operating system. Administrative permissions may be required, and command output varies by platform.

Windows

netstat -ano

This displays listening ports and active TCP or UDP endpoints, including process IDs.

Linux

ss -tulpn

This displays TCP and UDP listening sockets and associated processes.

sudo lsof -i -P -n

This identifies processes using network ports without resolving names.

Connectivity Test

nc -vz <server-ip-or-name> 21

When netcat is available, this tests whether a TCP destination port is reachable. It does not test UDP behavior and does not prove that the expected application is functioning correctly.

Cisco IOS

show ip sockets

On platforms and software versions that support it, this displays IP socket information.

Troubleshooting Port Problems

The Host Is Reachable, but the Application Does Not Work

  1. Verify the expected transport protocol and destination service port.
  2. Confirm that the server application is listening on the expected local address and port.
  3. Check host and network firewall rules for the relevant protocol and port.
  4. Remember that successful ICMP reachability does not prove that a TCP or UDP service is available.

TCP Port 21 Is Refused

A refusal commonly indicates that the host is reachable but no service is listening at that destination port, or that a device actively rejected the connection. Verify the FTP service state and configured control port. Also check whether the service is bound only to a different interface or IP address.

The Client Does Not Receive a Response

Inspect the client's temporary source port and verify that stateful return traffic is permitted. Check NAT and firewall state handling, and confirm that the response is addressed to the client IP address and source port used by the original request.

A Service Cannot Start Because a Port Is in Use

Identify the process bound to the same IP address, protocol, and port. Stop or reconfigure the conflicting process, or assign the new service a different port. Check TCP and UDP separately before assuming that a listener in one protocol conflicts with a listener in the other.

TCP 53 Works, but DNS Queries Fail

Test UDP port 53 because standard DNS queries commonly use UDP. Verify that firewalls permit UDP requests and replies. TCP 53 and UDP 53 are different transport services.

Exam-Ready Summary

  • A port is a 16-bit TCP or UDP identifier ranging from 0 through 65535.
  • An IP address identifies a host; a port helps identify the application endpoint on that host.
  • TCP and UDP have separate port namespaces.
  • Clients normally use temporary source ports and send to a server's known destination port.
  • Server replies reverse the source and destination endpoints.
  • A five-tuple contains source IP, destination IP, source port, destination port, and protocol.
  • A socket endpoint is an IP address paired with a port, such as 192.168.0.50:1200.
  • Well-known ports are 0–1023, registered ports are 1024–49151, and dynamic/private ports are 49152–65535.
  • Default port assignments can be changed, so a port number is a convention rather than proof of application identity.

Continue reviewing TCP and UDP ports by practicing five-tuple identification and interpreting packet directions.