VMware ESXi and vSphere Cluster Management

Understanding TCP and UDP Port Numbers

Learn how TCP and UDP ports identify network services, how source and destination ports support client-server communication, and how sockets, five-tuples, firewalls, and NAT affect connectivity.

A port is a numbered transport-layer endpoint used to direct network traffic to a particular application or service on a host. An IP address identifies a host or network interface; a port identifies the service or application endpoint on that host.

For example, an IP address might identify a web server, DNS server, and file-transfer server running on the same computer. The IP address alone cannot tell the operating system which application should receive each incoming packet. Port numbers provide that additional destination information.

What TCP and UDP ports identify

TCP and UDP each have their own port-number space. A service can commonly use TCP port 53 and another service, or the same service for a different operation, can use UDP port 53. The number alone does not identify the protocol.

• TCP is connection-oriented. Applications exchange data through a TCP connection with reliable, ordered delivery provided by TCP.
• UDP is datagram-oriented. Applications send individual datagrams, and UDP does not establish a connection before delivering them.

Both TCP and UDP headers contain a source port and a destination port. These fields help the receiving host deliver transport traffic to the correct application.

Port-number format and ranges

A TCP or UDP port field is 16 bits long. Sixteen bits provide 65,536 possible numeric values, ranging from 0 through 65535.

An ephemeral port is a temporary local port selected for an outbound communication flow. A client normally does not need a fixed port such as 1200; its operating system selects an unused local port, subject to its configuration and current availability.

Source and destination ports

When a client contacts a server, the client normally places the server's service port in the packet's destination-port field. The client places its own locally available port in the source-port field.

• The source port identifies the sending application's local endpoint. For a client, it is often an ephemeral port.
• The destination port identifies the intended remote service or receiving application.

The server's reply reverses the port roles. The server's listening port becomes the response source port, and the client's original source port becomes the response destination port. The operating system can therefore return the response to the correct client application.

Client-server communication flow

How a server becomes reachable

A server application performs a bind operation to associate a socket with a local IP address and port. It may bind to one specific local address, such as an address on an Ethernet interface, or to all local interfaces using a wildcard address such as 0.0.0.0 for IPv4. A TCP server then listens for incoming connection attempts. A UDP server waits for incoming datagrams on its bound port.

A listening port is a local protocol-and-port combination on which a server process waits for incoming traffic. Listening is different from a temporary client source port: the server port is usually stable and advertised or documented, while the client port is commonly selected for one outbound flow.

How the client communicates

1. The client application asks the operating system for a local source port, or selects one according to its socket behavior.
2. The client targets the server using the server IP address, transport protocol, and destination port.
3. The packet carries both IP addresses and both transport ports.
4. For TCP, the protocol performs connection setup before normal application data exchange. For UDP, the client sends a datagram without a transport-level connection setup.
5. Replies use the server's port as the source port and the client's port as the destination port.

For the FTP example, the request can be represented as 192.168.0.50:1200 → 192.168.0.10:21 over TCP. The response is 192.168.0.10:21 → 192.168.0.50:1200 over TCP.

Sockets and the five-tuple

A socket endpoint is commonly written as an IP address plus a port, such as 192.168.0.50:1200. In practical networking, the transport protocol is understood as part of the context, because TCP and UDP use separate endpoint spaces.

A local socket endpoint describes one side of communication. A complete transport flow is more precisely identified by a five-tuple:

• Source IP address
• Source port
• Destination IP address
• Destination port
• Transport protocol, such as TCP or UDP

The five-tuple allows a host to distinguish concurrent flows. Many clients can connect to the same web server port, such as 203.0.113.20:443, because their source IP addresses, source ports, or both differ. The protocol is also part of the identity, so TCP port 443 and UDP port 443 are not the same flow.

Common service-port examples

These are default-port conventions, not permanent requirements. An administrator can run an HTTP application on TCP port 8080 instead of TCP port 80. Clients must then specify port 8080, such as in a URL or connection setting.

Listening ports and port availability

Only one compatible process can generally bind the same local IP address, transport protocol, and port combination at a time. A wildcard bind, such as binding to all IPv4 interfaces, can conflict with a process bound to one of those specific addresses. Some operating systems and applications support socket-sharing options, so the exact behavior depends on the platform and configuration.

A service may be unreachable for several different reasons:

• No process is listening on the destination port.
• The client selected the wrong destination port.
• A firewall, security group, router access-control list, or upstream firewall blocks the traffic.
• The service is bound only to loopback or to a different network interface.
• NAT or port forwarding sends the traffic to the wrong internal host or port.

Inspecting ports on hosts and networks

On Linux, use ss to inspect listening sockets and active socket states:

sudo ss -tulpn
ss -tunap

The first command lists listening TCP and UDP sockets with owning processes when permissions allow. The second displays TCP and UDP sockets in all relevant states.

On Windows, these commands show listening ports and process information:

netstat -ano | findstr LISTENING
Get-NetTCPConnection -State Listen

To scan systems that you own or are explicitly authorized to test, Nmap can check selected TCP and UDP ports:

nmap -sT -p 21,80,443 <target>
nmap -sU -p 53 <target>

TCP and UDP scans differ because TCP has connection behavior while UDP uses datagrams and may require additional interpretation of a lack of response.

Binding address, firewall, and configuration examples

A service configuration might explicitly specify the following values:

listen_address = 0.0.0.0
port = 8080
protocol = TCP

This example means that the service intends to listen on TCP port 8080 on all local IPv4 interfaces. It does not by itself guarantee remote access: the process must start successfully, the host must have the expected interface, and firewalls or network devices must permit the traffic.

For example, a Linux host using UFW can allow inbound HTTPS traffic with:

sudo ufw allow 443/tcp

Allowing a port through a firewall is only one part of troubleshooting. A process must also be listening on the matching protocol, address, and port.

NAT and externally visible ports

Network address translation (NAT) rewrites addresses as traffic crosses a router or gateway. NAT may also rewrite a source port so that multiple internal clients can share one public IP address while their flows remain distinguishable.

Port forwarding maps an external address and port to an internal host and service. For example, a router might map public TCP port 8443 to internal host 192.168.0.10 on TCP port 443. An external client connects to the public address and port 8443, while the internal web service receives traffic on port 443. Therefore, the port visible to an external client may differ from the service's internal port.

Troubleshooting port problems

Connection refused

A TCP connection-refused result commonly means that no process is listening on the destination TCP port, the client used the wrong port, or the service stopped or failed to start.

• Verify the server's listening sockets.
• Confirm the configured service port.
• Review the service status and logs.

Address already in use

This startup error usually means another process owns the same compatible IP address, protocol, and port binding, although a previous instance might also be releasing its socket. Identify the owner with ss, netstat, or an operating-system process tool. Stop or reconfigure the conflicting process, or choose another port when appropriate.

Remote timeout

A timeout can occur when a firewall or security group blocks traffic, the service listens only on loopback or an unintended interface, or a NAT rule points to the wrong internal host or port.

• Inspect the exact local bind address.
• Test locally and from another network host.
• Verify host firewall, network firewall, and NAT rules.

DNS works for some operations but not others

DNS commonly uses both UDP port 53 and TCP port 53. If UDP is allowed but TCP is blocked, typical queries may work while larger responses or operations that require TCP fail. Check that the service listens on both protocols and that both are permitted where required.

The customary port is unreachable

The administrator may have configured a nondefault port, or a reverse proxy or NAT device may expose a different external port. Confirm the URL, connection string, service configuration, and forwarding rules.

Summary

• IP addresses identify hosts or interfaces; ports direct traffic to application or service endpoints.
• TCP and UDP have independent port spaces, even when the numerical port is the same.
• Ports range from 0 through 65535 because the field is 16 bits.
• Clients commonly use ephemeral source ports and target stable server destination ports.
• TCP and UDP packets both carry source and destination ports.
• A five-tuple identifies a transport flow: source IP, source port, destination IP, destination port, and protocol.
• Default service ports are conventions and can be changed.
• Listening state, bind addresses, firewalls, and NAT all affect reachability.

For a compact reference, review TCP and UDP port concepts together with the packet-flow and five-tuple examples in this lesson.