Target is fixed
The server derives the target from the connection that requested the scan. There is no target field, which prevents the page from being used to scan an unrelated address.
Public Port Risk Scanner
One click checks selected high-value TCP ports on the public address FirewallGuide can observe. There is no target field, no vulnerability exploitation, and no claim that one scan proves a network safe.
What the scan answers
Can FirewallGuide's server establish a TCP connection to selected services on the public address it sees for you?
- Check selected public TCP services from an external server
- Fix the target to the requesting public address
- Explain open, closed, and no-response results with next actions
- Free to use with no account
- No scan result saved; short-lived address rate limiting only
A real external connection check
The scan runs from the FirewallGuide server, not from JavaScript in your browser. That external viewpoint is necessary to test public reachability.
Scope is limited
The scanner attempts TCP connections to a selected set of commonly exposed web, remote administration, file-sharing, database, and infrastructure ports. It does not send application commands.
Results are interpreted
An accepted connection is reported as open. An explicit refusal is reported as closed. A timeout or routing failure is reported as no response because the scanner cannot safely assume why it received nothing.
How risk is assessed
Open database, file-sharing, unencrypted administration, remote desktop, container-management, and cache services receive stronger warnings because they usually belong behind a restricted boundary. Public web, mail, or DNS services receive a review result because they may be intentional.
The port number alone cannot identify the exact software. The result tells you that a TCP listener responded on that number from this scanner's network position. Confirm the process, owner, authentication, patch level, and firewall rule on the actual system.
What one click cannot prove
- A router, VPN, carrier gateway, proxy, or shared address may be the system that responds.
- The scan does not cover UDP, every TCP port, passwords, application flaws, malware, or local network access.
- An upstream firewall or hosting provider can block the scanner even when another internet source can connect.
- No tested open port is a useful result, but it is not a certificate that the network or device is safe.
What to do with an open result
First decide whether the service is intentional. Check the router's port-forwarding and remote-administration settings, then inspect listening processes and host firewall rules on the destination device. In a cloud environment, also check load balancers, public addresses, security groups, and network firewall policy.
If the service is not required, remove the forwarding or allow rule and stop or unbind the listener. If it is required, restrict sources, use current encrypted protocols, enforce strong identity controls, patch the software, preserve useful logs, and set a review date. Run the scan again only after the change is complete.
Why your public address may not be your device
Most home networks use address translation, so the public address normally belongs to the router. Mobile and some residential providers can place several customers behind carrier-grade translation. A VPN or proxy can make its exit address appear instead. The result therefore describes the public boundary visible to FirewallGuide at scan time, not every device behind it.
For a controlled verification plan that includes expected allow and deny cases, use the safe firewall testing method. Use the port reference to investigate a service number and the rule planner before changing access.
Questions about public port scan results
Why is there no IP address field?
The server fixes the target to the public address used for your request. This prevents the tool from scanning an unrelated address and keeps the authorization decision tied to the connection you control.
Is every open port dangerous?
No. A public web or mail service may be intentional. Risk depends on the actual process, owner, authentication, patch level, source restrictions, and business need. Use the TCP and UDP port reference as a clue, then confirm the listener on the system.
What does no response mean?
The scanner did not complete a TCP connection or receive an explicit refusal before the timeout. Filtering, routing, provider controls, address translation, or a stopped service can produce that result. It does not identify which cause applies.
Does a clear result prove the network is safe?
No. The scan covers selected TCP ports from one external network position. It does not test UDP, local access, passwords, application flaws, malware, or every possible path. Continue with the firewall testing workflow when the decision needs stronger evidence.
Technical references
- IANA Service Name and Transport Protocol Port Number Registry for common port assignments and the warning that a registered number does not identify the traffic actually present.
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy for firewall policy, configuration, testing, deployment, and management principles.
- CISA StopRansomware Guide for reducing internet-facing exposure, restricting remote desktop services, and blocking unnecessary external SMB access.