A port number is a hint, not a firewall policy. The Common Network Ports List tool catalogs 40 frequently encountered TCP and UDP service registrations so you can translate a number into a likely registered service, but it is deliberately not an allowlist: assignment by IANA is not an endorsement, a registered service name is not a proof of identity, and a list of ports is not a substitute for the business, direction, endpoint, protocol, authentication, and least-privilege decisions that a real firewall rule requires. Treating a curated ports table as an allowlist skips the work that turns network intent into safe policy, and the same table that helps you read a packet capture will not tell you whether traffic to port 5432 on a specific host is legitimate PostgreSQL or a misconfigured service you never intended to expose. The list is a reference for the questions "what might be running here" and "what does this number usually mean", not a rule you can paste into your firewall.
What the Common Network Ports List Actually Contains
The Common Network Ports List displays a curated table of 40 frequently encountered network ports. Each row carries one numeric port, the selected IANA service name, the relevant transport protocols (TCP, UDP, or both where the distinction matters), a short plain-language description, and a category used by the filter. Ports are sorted numerically and are unique within the table, and the rows cover familiar web, mail, file transfer, remote access, directory, database, messaging, printing, container, and core network services.
The tool does not pretend to reproduce the entire IANA registry. The number space is much larger: IANA divides it into System Ports from 0 through 1023, User Ports from 1024 through 49151, and Dynamic or Private Ports from 49152 through 65535, and registration ranges and conventions follow RFC 6335. A curated list of 40 rows covers common System and User Ports but excludes the dynamic range by design, so a port absent from the table can still be valid, registered, private, ephemeral, or widely used by convention. Absence here means only that the port sits outside the curated set.
Search runs as a case-insensitive match over the port number, service name, description, and category, so a query for 443 returns HTTPS, a query for PostgreSQL returns 5432, and a query for mail can return SMTP, POP3, IMAP, message submission, and their TLS variants. The copy action exports only the rows currently visible after your filters, as tab-separated text suitable for tickets, runbooks, notes, or study material. No query or copied result leaves the page.
Why a Ports List Cannot Replace Firewall Policy
The short answer is no. The Common Network Ports List is not a firewall allowlist, and the tool itself flags this: firewall policy needs verified business purpose, direction, endpoints, protocol, authentication, encryption, ownership, and least privilege. A ports list cannot supply any of those properties because each one depends on the specific host, deployment, organization, and threat model you are protecting. Three structural reasons make the substitution unsafe.
First, a port number is not an identity. The IANA Service Name and Transport Protocol Port Number Registry, the registry the tool's rows were checked against, explicitly warns that assignment does not endorse an application and does not prove that observed traffic is good. A server can listen on an unusual port, several registered names may share a single number, and a packet using a registered number may belong to a different program than the one whose name sits in the table. Confirming what is actually running requires inspecting the process, the configuration, the listening socket, and the traffic on the real endpoint, work that no static list can do for you.
Second, the same number can carry encrypted or clear-text traffic depending on configuration. The tool shows HTTPS over TCP, but a server on the same port can serve HTTP, a custom proxy, or a non-web service. Allowing 443 therefore does not "allow web" in any policy sense; it allows whatever the listening process accepts. Comparing clear-text and TLS variants such as HTTP and HTTPS, IMAP and IMAPS, or LDAP and LDAPS is useful for study, but the encryption decision belongs to the service configuration, not the port.
Third, the curated table prioritizes common operational use over exhaustive coverage. For example, DNS appears with both TCP and UDP, while HTTPS is shown with TCP only. That choice keeps the table readable, but it is not an authoritative statement about every modern protocol, extension, alternate registration, vendor convention, or deployment. An allowlist built from these rows inherits those omissions and silently excludes services you might have intended to cover.
What a Real Firewall Allowlist Must Capture
A working allowlist starts with a question a port table cannot answer: why does this traffic exist? The decision chain usually runs through several filters before the port number is even relevant. The table below contrasts what the curated list provides with the properties an actual rule needs.
| What a ports list provides | What an allowlist actually needs |
|---|---|
| Numeric port | Verified endpoint (specific IP, host, or CIDR) |
| Registered IANA service name | Direction (inbound, outbound, or both) |
| Common transport protocol | Actual protocol observed on the wire |
| Short plain-language description | Authentication mechanism in use |
| Category for filtering | Encryption requirement and version |
| — | Business owner, ticket, and documented purpose |
| — | Least-privilege scope and review cadence |
None of the right-hand column can be inferred from the left. Each rule should be specific to an endpoint and a purpose, scoped to the smallest set of source and destination addresses that meets the business need, and reviewed on a schedule that matches how often the underlying service changes. A port list can supply a starting guess for the protocol column, and that guess must then be confirmed against the actual service configuration, the listening socket on the host, and the packets you observe in capture.
For a flat reference of the 40 ports without the firewall framing, see the List of Most Common Network Ports: TCP and UDP guide. The list itself is the same source; the difference is that the current article centers the allowlist decision and the limits you must respect before you act on it.
Using the List to Identify a Port Before You Decide
The Common Network Ports List is most useful upstream of policy work, not as input to it. When you encounter an unfamiliar number in a log, a packet capture, a change request, a vendor document, or a ticket from another team, the tool turns that number into a likely service name, a likely protocol, and a category you can use to triage. From there, the real verification work begins: confirm the listening process on the host, read the service configuration, check that the protocol on the wire matches what you expected, and only then decide whether a firewall rule should permit the traffic, in what direction, and to which endpoint.
The category filter is a useful triage aid. The tool exposes filters that isolate familiar groups such as web services, mail, databases, remote access, and core network infrastructure without changing the underlying reference data. Applying a database filter when you suspect a database server, for example, narrows 40 rows to a handful so you can spot whether the number you saw matches a registered database port or something else entirely. Triage is not policy: a match in the database category still requires you to verify the endpoint, the direction, and the purpose before any rule is written.
| Filter | Use it to |
|---|---|
| TCP or UDP | Distinguish transports where it matters (DNS over TCP vs UDP, HTTPS over TCP) |
| Web | Isolate HTTP, HTTPS, and related web traffic |
| Group SMTP, POP3, IMAP, submission, and their TLS variants | |
| Database | Review PostgreSQL, MySQL, and similar service ports |
| Remote access | Find SSH, RDP, Telnet, and other shell services |
| Network infrastructure | Inspect DNS, NTP, DHCP, and core network services |
How to Look Up a Port in Common Network Ports List
- Enter a port number, service name, product term, or description in the search field. The match runs across the port number, IANA service name, description, and category as you type, and the table updates immediately in the browser.
- Optionally narrow the visible rows by transport protocol (TCP or UDP) where the distinction matters, or apply a category filter such as web, mail, database, remote access, or network infrastructure to isolate a service group. The underlying reference data does not change; only the visible rows do.
- Review the matching registration hints to confirm whether the number maps to the service you expected. A query for 443 returns HTTPS; a query for PostgreSQL returns 5432; a query for mail returns SMTP, POP3, IMAP, message submission, and their TLS variants.
- Copy the visible rows as tab-separated text when you need a reference for a ticket, runbook, study notes, or configuration review. The copy action exports only what is visible after your filters, so narrow first if you want a smaller excerpt.
- For exhaustive assignments, alternate registrations, aliases, change history, or SCTP and DCCP entries, follow the linked IANA registry instead of relying on the curated 40-row table. The curated list is a fast lookup for common cases; the registry is the authoritative source for decisions that need exhaustive or time-sensitive evidence.
What the Curated List Deliberately Excludes
The product contract is explicit about its limits so that you do not accidentally treat the table as more than it is. Five properties matter for the firewall question.
- The table is curated, not exhaustive. It does not reproduce every IANA assignment or change, and the transport list favors common operational use over every registry row.
- The dynamic port range from 49152 through 65535 is not enumerated. Ephemeral, private, and convention-driven ports sit outside the curated set, so absence here is not evidence of anything.
- IANA registration does not mean safety. The registry warns that assignment does not endorse any application, and the tool does not label any port safe or recommend firewall access.
- The tool does not scan a host, detect listening services, or replace packet inspection and authenticated system inventory. Verification of what is actually running has to happen on the endpoint with platform-native tools.
- No query or copied result leaves the page; processing is local. That is a privacy property, not a security verdict on the traffic the numbers represent.
For a decision that requires exhaustive or time-sensitive evidence, cross-check the IANA Service Name and Transport Protocol Port Number Registry directly and rely on platform-native tools, service configuration, logs, and your own network policy for the actual allowlist verdict. The curated list speeds up the lookup phase of that workflow; the policy phase still belongs to you.