Open Port Checker

Test if a specific port is open and accessible from the internet on any IP address or domain.

Evidence ASSESSED

Checked against: TCP connect() probe per port

RED TEAM 0 findings BLUE TEAM control did not hold

Common Port Reference

21: FTP (File Transfer)
22: SSH (Secure Shell)
25: SMTP (Email)

53: DNS
80: HTTP (Web)
110: POP3 (Email)

443: HTTPS (Web)
3306: MySQL (Database)
3389: RDP (Remote Desktop)

Our Open Port Checker tests whether one specific port on a host is reachable from the internet. Use it to confirm a firewall rule took effect, verify a newly deployed service is accessible, or check that a port you closed really is closed.

What is an Open Port?

A port is open when a service is listening on it and network traffic can reach that service from where you are testing. Both conditions must hold — a service can be running perfectly while a firewall silently discards every packet before it arrives.

That is why a single-port check answers a different question from an internal one. Running ss or netstat on the host tells you whether a process is bound to the port. Testing from outside tells you whether the internet can actually reach it, which is the only question that matters for exposure.

Three outcomes are possible. Open means the connection completed. Closed means the host replied with a reset, so it is reachable but nothing is listening. Filtered means nothing came back at all, which almost always indicates a firewall dropping traffic silently.

Requires both a listening service and an unobstructed network path
An external test answers a different question from a local one
Open, closed and filtered are three distinct outcomes
Filtered usually means a firewall is dropping packets silently
The most direct way to verify a firewall change took effect

Why Checking a Specific Port Matters

Firewall changes are easy to get wrong and hard to verify from the inside. A rule added to the wrong chain, applied to the wrong interface, or lost after a reboot produces no error — the service simply stays unreachable, or worse, stays reachable when you believed you had closed it.

Testing from outside is also the only way to confirm cloud security group rules, which layer on top of host firewalls. A port can be open on the instance, permitted by iptables, and still blocked by a security group, or the reverse. Only an external test shows the combined result.

Confirms a firewall rule actually took effect
Cloud security groups layer on top of host firewalls with combined effect
Verifies a newly deployed service is genuinely reachable
Confirms a port you intended to close really is closed
Local checks cannot tell you what the internet sees

How This Open Port Checker Works

The tool attempts a single TCP connection to the port you specify and reports the result.

Validates the host and port inputs against format and SSRF safety checks
Resolves the hostname to an address if needed
Attempts a TCP connection to the specified port
Waits for a completed handshake, a reset, or a timeout
Reports the port as open, closed or filtered

How to Use the Open Port Checker

Enter a hostname or IP address you own or are authorised to test
Enter the port number you want to check
Run the check to attempt a connection
Compare the result against what you expect
If a service should be reachable but shows filtered, check firewall and security group rules

Understanding Your Port Check Result

A single port returns one of three states, each with a different meaning:

Field / Value	Meaning
`Open`	The connection completed. A service is listening and the network path is clear. Correct for a port you intend to publish, and a finding if you do not.
`Closed`	The host replied with a reset. It is reachable, but nothing is listening on that port. Either the service is not running or it is bound to a different interface.
`Filtered`	No response before the timeout. A firewall is discarding packets silently. The correct state for anything that should not be publicly reachable.
`Timeout`	Indistinguishable from filtered in most cases. It can also indicate the host is offline or that an intermediate network is dropping traffic.
`Host not found`	The hostname did not resolve. A DNS problem rather than a connectivity one — check the A or AAAA record first.

Common Problems & How to Fix Them

Something between the internet and the service is dropping packets.

Work through the layers in order: the host firewall (iptables, nftables, ufw or Windows Firewall), then the cloud security group or network ACL, then any upstream device. In cloud environments the security group is the most frequently overlooked layer, because the host firewall alone looks correct.

The host is reachable but no service is listening on that port.

Check on the host whether the process is running and which interface it is bound to. A service bound to 127.0.0.1 is reachable only locally, which looks correct in a local test and closed from outside. Bind to 0.0.0.0 or the specific public interface if external access is intended.

A firewall rule is missing, was applied to the wrong chain or interface, or was lost on reboot.

Verify the rule is present and persisted across restarts — unsaved iptables rules are a classic cause. In cloud environments check whether an overly permissive security group rule is allowing traffic the host firewall would otherwise block.

This is the expected behaviour when a firewall restricts by source address, and it usually means the configuration is correct.

If external access is genuinely required, confirm the perimeter firewall or security group permits the intended sources. Test from a network that is meant to have access to confirm legitimate paths still work.

IPv4 firewall rules do not apply to IPv6 traffic, and many systems ship with permissive IPv6 defaults.

Audit ip6tables or nftables separately and mirror your IPv4 policy. This is one of the most common oversights when IPv6 is enabled on an existing host.

Best Practices

Test from outside your network, since that is the view that matters
Verify every firewall change with an external check rather than assuming
Confirm firewall rules persist across reboots
Check cloud security groups as well as the host firewall
Bind services to the narrowest interface that meets the requirement
Mirror IPv4 firewall policy in IPv6 rules
Re-test after every deployment and infrastructure change

Security Recommendations

Only test hosts you own or have explicit authorisation to test
Prefer filtered over closed for ports that should not be public, since it reveals less
Never expose database or management ports directly to the internet
Verify closure after decommissioning a service rather than assuming the port closed with it
Remember an open port is continuously probed by automated tooling within minutes of appearing
Check IPv6 separately, where missing firewall rules are a frequent source of unintended exposure

Frequently Asked Questions

No response came back before the timeout, which almost always means a firewall discarded the packet silently. For a port that should not be public this is the desired state, since it reveals less than an explicit rejection.

Closed means the host actively replied with a reset — it is reachable but nothing is listening. Filtered means nothing replied at all, because a firewall dropped the traffic. Closed confirms the host exists; filtered does not.

Either a firewall is blocking it or the service is bound to the wrong interface. A service bound to 127.0.0.1 accepts only local connections. Check the binding first, then the host firewall, then the cloud security group.

A firewall is restricting access by source address, which is usually correct and intentional. If external access is genuinely needed, the perimeter firewall or security group must permit the intended source ranges.

Only with authorisation. A single connection attempt is technically indistinguishable from ordinary traffic, but systematically probing third-party infrastructure without permission may constitute unauthorised access.

IPv4 firewall rules do not apply to IPv6. Many systems ship with permissive IPv6 defaults, so enabling IPv6 can silently expose services that were firewalled on IPv4. Audit ip6tables or nftables separately.

Within minutes. Automated scanning of the entire internet address space is continuous, so any newly reachable service will receive connection attempts almost immediately. Assume exposure is noticed as soon as it exists.