Check selected public exposure
Authorize a fixed-scope scan of the public address connecting to FirewallGuide. Use the result as an external observation, then identify the local process and rule.
Start with the question you need to answer. Check selected public ports from an external server, calculate networks locally, clean address lists, inspect firewall evidence, find rule conflicts, or document a change before deployment. Every tool explains its limits.
Use the one-click public port check only when you want a limited external TCP test of the public address used for the request.
For a planned policy change, create a review record with the firewall rule planner before translating the decision into vendor syntax.
Select the tool by the question you can answer: identify a registered service, calculate a network range, document a rule, or observe selected public TCP reachability.
| Situation | Recommended starting point | Reason |
|---|---|---|
| You found a port number | Check the registry and the actual process | A registered service name does not prove what is listening on your device. |
| You need a network range | Calculate the CIDR boundaries | Validate the result against the router or cloud network configuration. |
| You need an exception | Draft the narrowest rule first | Record direction, protocol, source, destination, port, owner, purpose, and expiry. |
| You need to check public exposure | Run the consent-based public port scan | The target is fixed to your observed public address and results include service-specific limits and next actions. |
Begin with the observation you can make safely, then confirm it with evidence from the system or firewall you control. None of the browser tools uploads entered network data unless the page clearly says a server request is required.
Authorize a fixed-scope scan of the public address connecting to FirewallGuide. Use the result as an external observation, then identify the local process and rule.
Parse pasted logs locally, group repeated events, and identify source, destination, service, and action patterns that deserve investigation.
Compare vendor-neutral rules for overlap, shadowing, broad access, and conflicting actions before translating the plan into a product syntax.
Build a local inventory of devices, owners, support state, trust, and recovery needs so scan and log findings have operational context.
Calculate, compare, and normalize the address boundaries used by routes and policy.
Calculate IPv4 or IPv6 network ranges, masks, address counts, binary values, and subnet splits locally in your browser.
Convert an IPv4 address between dotted decimal, integer, hexadecimal, and binary notation, then identify its address category.
Convert IPv4 CIDR prefixes and netmasks into wildcard masks, inspect the matched range, and test whether an address matches.
Compare IPv4 CIDRs and address ranges to find duplicates, containment, and overlaps before changing routes or firewall policy.
Normalize IPv4 addresses and CIDRs, remove duplicates and covered networks, and produce the smallest exact allowlist for the same addresses.
Turn access requests into narrow, reviewable changes and check ordered policy for conflicts.
Draft a narrow, reviewable firewall rule with owner, purpose, scope, test, and expiry details.
Check an ordered vendor-neutral IPv4 rule list for duplicates, contradictions, and rules shadowed by earlier broader policy.
Plan one narrow port-forwarding rule with source restriction, internal destination, ownership, expiry, rollback, and external verification.
Use registry, scan, and log evidence without claiming more than the observation supports.
Look up common service ports, then assess whether the service should be reachable from the selected network.
Run a limited external TCP scan against the public address currently connecting to FirewallGuide and receive a risk-focused explanation.
Analyze pasted firewall log lines locally to summarize allowed and denied events, protocols, addresses, ports, and parsing gaps.
Record the devices, ownership, support, trust, and recovery facts behind the network.
Build a local device inventory with address, owner, trust, support, administration exposure, and recovery information.
A calculation, registry lookup, or external connection check is an input to a decision. None of them alone proves that a service is safe or correctly configured.
Decide whether you are identifying a service, calculating an address range, or documenting a rule. The same number can mean different things in different contexts.
Compare the result with the listening process, route table, gateway, cloud network, or firewall policy. A reachable port still does not identify the application, owner, patch level, or authentication strength.
Keep the input, result, owner, purpose, approval, rollback, and expected allow and deny cases. This makes a small tool useful in a larger operational process.
Only the public port risk scanner. It runs after a click and checks selected TCP ports on the public address used for that request. The other tools calculate or organize information locally.
No. Translate it through the target platform's documented syntax, peer review it, preserve rollback, and test in the correct environment.
Calculators are checked with deterministic examples, registry data retains its source date, and the scanner keeps a fixed consent-based scope. Tool output is never presented as proof that a live configuration is secure.