The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
The reliable way to test a firewall is to compare the policy you expect with three observations: the Nmap result, the packets that actually crossed the monitored interface, and the firewall’s own log entry. Start only with written authorization and a narrowly defined source, destination, protocol, port set, schedule, and stop condition. Then capture traffic with tcpdump, run a bounded Nmap SYN scan, use an ACK scan when you need to investigate filtering, and repeat the test from every network vantage point that matters.
What this test can—and cannot—prove
A firewall test answers a path-specific question: what happened when a particular source address sent a particular probe to a particular destination, at a particular time, through the devices on that route? It does not prove that every interface, route, protocol, or rule behaves identically. Source networks, routing, stateful connection context, filtering devices, and the target interface can all change the result.
Free tools Windows power users keep installed
One-click scans. No signup required.
Nmap supplies a classification of the target’s response. tcpdump supplies packet-level evidence from the interface where you capture. Firewall logs show how the policy engine handled the traffic. None of those views is complete by itself. A convincing result is one in which all three are reconciled.
1. Get authorization and define the test
Obtain written authorization from the people responsible for every network and host in scope. Nmap’s legal guidance recommends securing written authorization from target-network representatives before scanning. Keep the authorization with the test record.
#1 Best Overall
- Used Book in Good Condition
Write the boundaries first
- Identify each approved source network or host, including outside, inside, VPN, and routed-segment vantage points.
- List destination addresses, interfaces, and the protocol and port combinations to test.
- Specify the start and stop times, scan rate limits, and an emergency stop contact.
- State whether service banners, application probes, or UDP traffic are permitted. Use the least intrusive probe that answers the policy question.
- Record the scanner’s source address, route, operating system, and Nmap version.
Build an expected-result matrix
Before sending traffic, make one row for every source-vantage-point, destination, protocol, and port combination. Add the expected action (allow or deny), the expected firewall log action, and the evidence you will require. A useful row has this form:
Source vantage point → destination → protocol/port → expected allow or deny → expected log event → observed Nmap state → packet evidence.
Do not infer an expectation from a previous scan. If the policy differs for a VPN address, a routed internal subnet, or a translated address, give each case its own row.
2. Capture the traffic before scanning
Start tcpdump before Nmap so the first packet is in the capture. Select the interface that carries the test traffic; on a multi-homed host, verify the route rather than assuming that eth0 is correct.
Start a bounded capture
- On the authorized capture host, run
sudo tcpdump -ni eth0 -w firewall-test.pcap 'host 192.0.2.10 and (tcp or icmp)'. Replace the interface, address, and filter with values from your approved test. The-ioption selects the interface,-navoids name lookups while capturing, and-wwrites packets to a pcap file instead of formatting every packet on screen. - Confirm that tcpdump is receiving packets and that the selected interface is the one on the test path. A capture point on only one side of a firewall may show the outbound SYN but not the return traffic.
- Leave the capture running for the entire bounded scan. Avoid broad, unrelated traffic in the filter because it makes review harder and may retain sensitive payloads.
tcpdump prints descriptions of packets matching a Boolean expression. In this capture, the expression keeps traffic involving the target and includes TCP and ICMP, which covers the normal SYN exchange, resets, and common unreachable or administratively prohibited messages.
Stop and preserve the file
- Stop tcpdump immediately after the scan completes, using the normal interrupt so it can finish the pcap cleanly.
- Record the capture filename, UTC start and stop times, interface name, capture host, and the exact Nmap command beside the file.
- Protect the pcap. Even a narrow capture can contain addresses, protocol metadata, or application payloads that are sensitive in your environment.
Check for capture loss
At shutdown, note tcpdump’s packet-received and kernel-drop counters. A nonzero drop count means the file may not contain every packet; missing evidence can be a capture-capacity problem rather than a firewall decision. Increase the capture host’s capacity, narrow the filter, or move the sensor before repeating the test.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →3. Run a bounded Nmap SYN scan
Use a SYN scan for the baseline TCP reachability test. Keep the port list explicit and small enough that the expected matrix and packet capture remain easy to audit.
nmap -n -Pn -sS -p 22,80,443 192.0.2.10The options mean:
-ndisables reverse-DNS lookups, preventing name-resolution delays and ambiguity.-Pntreats the host as up without relying on host-discovery probes. Use it when discovery probes are expected to be blocked, and record that choice because it changes what the scan tests.-sSsends TCP SYN probes and normally does not complete the application connection.-p 22,80,443limits the scan to the policy ports in this example. Replace them with the authorized set.
Record the complete command, source address, route, destination address, timestamp, and Nmap version. A result without that context cannot be compared reliably with a result from another segment.
4. Use an ACK scan to investigate filtering
When the policy question is whether a filter is blocking the path, run an ACK scan against the same bounded TCP ports:
nmap -n -Pn -sA -p 22,80,443 192.0.2.10An ACK scan is useful for mapping filtered versus unfiltered behavior. It does not determine whether an application is listening. Pair its result with the SYN scan and the packet capture; do not treat an ACK result as an open-service test.
Recommended Free Tools
5. Add UDP or ICMP tests only when the policy requires them
TCP results do not describe UDP policy. For an approved UDP rule, test the specific port and add an application-level probe when it is safe and authorized. Silence in UDP can mean that a filter dropped the packet or that no service responded, so a UDP result needs more context than a TCP SYN/SYN-ACK exchange.
Include ICMP in the capture when the firewall is expected to generate an unreachable or administratively prohibited response. Discovery behavior is also protocol- and policy-dependent; that is why -Pn should be used only when discovery probes are expected to be blocked and documented as part of the test.
6. Interpret Nmap states with packet evidence
| Nmap state | What Nmap observed | What to look for in tcpdump | Important limit |
|---|---|---|---|
| open | An application accepted the probe. | An outbound SYN followed by a SYN/ACK from the destination, with the expected policy log. | Confirm that the response came from the intended host and interface, not a proxy or another device. |
| closed | The host returned a TCP reset, indicating no listener or an active reject path. | A SYN followed by a TCP RST (often RST/ACK), plus the firewall and host logs where available. | Some firewalls can forge RST packets. Compare sequence numbers, TTL or hop details when useful, source address, and the capture location. |
| filtered | A firewall, filter, or other obstacle prevented Nmap from deciding open versus closed. Nmap commonly receives no response or an ICMP error. | A SYN leaving with no return packet, or an ICMP unreachable or administratively prohibited message. | Filtered does not identify which device dropped the packet or prove that the destination service is absent. |
| unfiltered | The probe reached the target, but that scan type could not determine open versus closed. | Evidence that the probe crossed the path and elicited a response compatible with the scan type. | ACK scans commonly report unfiltered; this state does not mean that an application is listening. |
Nmap’s definition of filtered is deliberately cautious: a firewall, filter, or other obstacle is blocking the port so Nmap cannot tell whether it is open or closed. The same destination can be open from one source and filtered from another because the route, source address, filtering devices, or target interface differs.
7. Prove which packets crossed the firewall
Read the pcap in the order a connection attempt should occur. First inspect the complete file:
tcpdump -nn -r firewall-test.pcapThe -r option reads a saved capture, and -nn keeps addresses and ports numeric so DNS and service-name lookups cannot disguise the actual endpoints.
Focus on TCP control packets
tcpdump -nn -r firewall-test.pcap 'tcp[tcpflags] & (tcp-syn|tcp-ack|tcp-rst) != 0'This expression highlights SYN, ACK, and RST flags. For an allowed TCP service, expect the scanner’s SYN, a destination SYN/ACK, and the scanner’s follow-up behavior. For a host with no listener or an explicit reject, expect a reset. For a silent drop, expect the outbound SYN without a corresponding return packet at the capture point.
Check ICMP decisions
Search the full readout for ICMP unreachable or administratively prohibited messages. Such a message is evidence that some device generated an explicit error; it is not, by itself, proof that the destination host received the original probe. Compare source and destination addresses, the embedded original packet, and the capture interface.
Verify direction and visibility
- Confirm whether the sensor sees ingress, egress, or both directions. A host capture may show only one side of a firewall traversal.
- Check for asymmetric routing. The SYN can leave through one interface while the response returns through another path that the sensor cannot see.
- Compare timestamps and sequence details with the Nmap run. Packets from another test or background service can otherwise be mistaken for evidence.
8. Reconcile tcpdump, Nmap, and firewall logs
For every matrix row, make the three evidence sources agree or explain the disagreement:
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitches- Nmap result: record the state and the exact scan type.
- Packet evidence: identify the outbound probe, any return SYN/ACK or RST, and any ICMP error. State where the capture was taken.
- Firewall log: locate the event by timestamp, source, destination, protocol, port, rule identifier, action, and translated address if applicable.
An allow rule should produce the expected packet exchange and an allow log at the enforcing device. A deny rule may produce silence (drop) or an explicit reject; those are different policies and should not be collapsed into one conclusion. If the log says deny but tcpdump shows a complete SYN/SYN/ACK exchange, you may be looking at a different enforcement point, a stale rule, a translated address, or a log record from another packet. If Nmap reports filtered while the capture shows an ICMP administrative prohibition, the state is consistent: the explicit error still prevented Nmap from determining open versus closed.
9. Repeat from every relevant vantage point
Run the same bounded tests from outside the perimeter, an inside segment, a VPN address, and any routed network that the policy distinguishes. Keep the destination and port set constant when possible. Record the vantage point with every result.
Different answers are expected when a route, source address, filtering device, or target interface changes. The comparison is useful only when those variables are explicit. A service can be reachable internally and filtered externally without either observation being wrong.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.10. Troubleshoot common mismatches
Nmap says filtered, but the rule says deny
That is often the expected outcome for a silent-drop rule. Confirm that the SYN left the scanner, that no SYN/ACK or RST returned at the capture point, and that the firewall log records the deny. If an ICMP error returned, identify which device sent it. If the log is absent, verify that you are reviewing the enforcing device, the correct interface, and the correct translated source and destination.
Nmap says closed, but the policy says deny
A reset indicates an active reject path or no listener. Determine whether the reset came from the destination host or was forged by a firewall. Compare packet details and logs; a reject rule intentionally produces a different observable result from a drop rule.
Nmap says open, but no firewall allow log exists
Check whether the traffic bypassed the device you are logging, whether another interface or route was used, and whether logging is sampled or delayed. Verify the destination address after any NAT and inspect the capture for the complete handshake.
The pcap has no response, but Nmap reports open
The capture point may not see the return path, the interface may be wrong, or packets may have been dropped by the capture kernel. Check the route, ingress/egress visibility, and tcpdump drop counters. Repeat from a sensor that can observe both sides of the relevant enforcement point.
Results change between runs
Check stateful-rule timing, load-balanced destinations, dynamic source addresses, route changes, and concurrent policy updates. Keep the port list and commands identical, note timestamps, and correlate each run with logs before drawing a conclusion.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
11. Produce an auditable test record
A useful report lets another administrator reproduce the observation without guessing. Preserve:
- written authorization and scope, including stop conditions;
- the expected-result matrix and any approved exceptions;
- source address, vantage point, route, destination address, interface, date, and time zone;
- the exact Nmap commands, Nmap version, and output;
- tcpdump command, capture filter, interface, pcap filename, and packet/drop counters;
- firewall log excerpts with rule identifiers and translated addresses;
- an explanation for every mismatch between expected policy and observed behavior.
Store pcaps and logs with access controls and retention appropriate to their contents. If the test crosses a change window, note the policy version or configuration revision so a later reader knows which rules were active.
12. Understand the limits of the conclusion
This method tests a path at a time. It cannot establish that every possible source, protocol, port, route, interface, or stateful connection is governed identically. A SYN scan does not test UDP, an ACK scan does not prove a listener, and a filtered result does not distinguish a firewall drop from another obstacle without additional evidence. Application-level authorization and behavior are separate questions from transport reachability.
Use the practical comparison axes consistently: source vantage point, protocol, destination port, stateful connection context, and evidence source. When all three evidence sources agree for each matrix row—and the test has been repeated across the required vantage points—you have a defensible explanation of the configuration behavior that was actually observed.
Further reading
For a deeper treatment of scan mechanics and firewall behavior, the Nmap Project’s official guide identifies Gordon “Fyodor” Lyon’s book Nmap Network Scanning (ISBN 978-0-9799587-1-7). The Linux tcpdump(8) manual explains Boolean capture expressions, interface selection, pcap writing, and reading saved captures.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
