Test Firewall Rules With Nmap and tcpdump

Updated 8 November 2026 · Standard formula, shown below

Testing a firewall with Nmap and tcpdump helps you compare what a remote system can reach with what your host actually receives. Nmap probes selected ports; tcpdump captures packets on an interface so you can see whether probes arrive and whether replies leave. Use this only on systems and networks you own or are explicitly authorized to assess.

What You’ll Need

A computer with Nmap and tcpdump installed, plus permission to run packet capture (often requires administrator or root privileges).
A target host whose firewall you administer, and a separate machine on the network to run Nmap from. Testing from outside the firewall is especially useful for validating an external boundary.
The target IP address, the network interface name, and a list of ports that should be open or blocked. Confirm the intended firewall policy before changing anything.
A maintenance window or approval if scans could affect a production service. Start with a few TCP ports rather than a broad or aggressive scan.

Step-by-Step

Define the test and the vantage point. Write down the source machine, target IP, protocol, and expected result for each port. For example, a web server might allow TCP ports 80 and 443 from a particular network while denying SSH from the public internet. A firewall can apply different rules to local, internal, and external traffic, so scan from the location relevant to the rule. Do not use a hostname unless you have confirmed it resolves to the intended address.
Check the target address and interface. On the target, use ip addr on Linux to identify its addresses and interfaces. To list interfaces available to tcpdump, run sudo tcpdump -D. On other operating systems, use the system’s network settings or interface-listing tools. Record the interface carrying traffic for the test; capturing on the wrong one can make a working firewall appear silent.
Start a focused capture on the target. For a TCP test to one host and a few ports, run:
sudo tcpdump -ni eth0 'host 192.0.2.25 and tcp and (port 22 or port 443)'
Replace eth0 with the target’s interface and 192.0.2.25 with the scanner’s source IP as seen by the target. The filter limits output to relevant traffic. The -n option avoids name lookups, and -i selects the interface. If you do not know the source address or want to see all traffic on the interface temporarily, use sudo tcpdump -ni eth0, but avoid an unnecessarily broad capture on a busy network.
Run a conservative Nmap scan from the other machine. Specify only the approved target and ports, for example:
nmap -n -Pn -sT -p 22,443 198.51.100.40
Here, -n skips DNS lookups, -Pn skips host discovery (useful when discovery probes are blocked), -sT performs a TCP connect scan, and -p names the ports. Replace the example address with the target’s real IP. If testing UDP, choose specific authorized ports and use -sU; UDP results can be inconclusive and may take longer. Avoid scanning an address range or using high-rate options unless explicitly approved.
Match the capture to Nmap’s result. In tcpdump, look for the scanner’s incoming SYN packet and the target’s response. A SYN followed by SYN-ACK generally means a TCP service accepted the connection; a RST commonly indicates the port is closed or actively rejected. Repeated SYNs without a visible reply can indicate filtering, packet loss, a return-path problem, or capture on the wrong interface. Nmap labels a port filtered when it cannot determine whether it is open because probes or responses are blocked or missing. That label does not prove which device dropped the traffic.
Compare the observed behavior with policy. Check the host firewall and any network firewall, router, security group, or access-control list between the two machines. Confirm that the rule matches the correct source, destination, interface, protocol, and port, and that rule order or a default policy does not override it. Also verify that a service is listening: on Linux, ss -lnt lists listening TCP sockets. A firewall cannot make an absent service accept connections.
Change one thing at a time and retest. If a result differs from the documented policy, inspect logs and rules before editing them. Make a narrow, reversible change through your normal change process, then repeat the same capture and scan. Keep a record of the command, source location, time, expected result, observed packets, and rule changed. Stop tcpdump with Ctrl+C when finished.
Save evidence only when needed. To save a short capture for review, add -c 100 -w firewall-test.pcap to tcpdump, then inspect it with a packet analyzer or tcpdump -nn -r firewall-test.pcap. Capture files may contain sensitive addresses or application data; restrict access and delete them according to your organization’s retention rules.

Common Mistakes

Scanning from the firewall host itself and assuming the result represents traffic arriving from the internet. Local traffic may follow different rules or bypass network devices.
Taking “filtered” to mean “closed.” It means Nmap did not get enough information to classify the port; packet capture and firewall logs help narrow down why.
Assuming no packet in tcpdump proves the firewall dropped it. The scan may not have reached the target, the filter may exclude it, or the capture may be on the wrong interface.
Forgetting that a listening service is required for an open result. A permitted packet can still receive a reset if nothing is bound to that address and port.
Using a different source address than expected. NAT, VPNs, proxies, and routing can change the address the target sees, causing a source-based rule not to match.
Running broad scans or captures without approval. They can create load, trigger alerts, or collect unrelated traffic.

Tips

Test both allowed and denied ports, and include a known listening service as a control. That helps distinguish firewall behavior from an unavailable target.
Use numeric IPs and ports for a repeatable test. Record whether the scan used IPv4 or IPv6; firewall rules may differ between them.
For a short diagnostic capture, use a packet-count limit or a narrow capture filter. Tcpdump output shows packets visible at the chosen capture point, not necessarily the final decision at every firewall in the path.
Check firewall counters and logs alongside packet capture. A drop log or increasing rule counter can identify the responsible rule more directly than a scan alone.

Troubleshooting

Nmap reports the host is down: Confirm the IP and route, then retry with -Pn as shown above. This skips host discovery; it does not make an unreachable host reachable. Check connectivity and target-side capture.

Nmap says filtered, but tcpdump sees nothing: Confirm the scanner’s actual source IP, target address, interface, and capture filter. Check upstream routers or firewalls and whether traffic is routed through a different interface.

Tcpdump sees incoming SYNs but no response: Check host firewall rules, service status, and the return route. Look for a drop rule, application binding to a different address, or asymmetric routing. A capture on the target may not show packets dropped before that point.

Tcpdump shows SYN-ACK, but Nmap does not show open: Capture on the scanner too if possible. A response may be lost on the return path, or the scan may be targeting a different address or port than the capture suggests. Compare timestamps and addresses at both ends.

Capture permission is denied or the interface is unknown: Use the system’s approved elevated-privilege method, verify tcpdump is installed, and list interfaces with sudo tcpdump -D. Do not grant broad privileges permanently just to run a test.

Frequently Asked Questions

Can Nmap alone prove a firewall is working?
No. Nmap reports how probes appear from one source at one time. Use tcpdump, firewall logs, rule counters, and tests from relevant network locations to establish what happened.

What is the difference between closed and filtered?
Closed generally means the target responded that no service accepts that port. Filtered means Nmap could not determine the port state because probes or replies were blocked or absent.

Can I run tcpdump on the scanning computer instead?
Yes. It can show outgoing probes and incoming replies, which helps diagnose the return path. Capturing on the target is better for confirming whether probes reached that host.

Why does a port look open from inside but blocked outside?
Internal and external traffic may traverse different firewall rules, routes, or NAT policies. Repeat the test from the network location the policy is intended to control.

Does a TCP scan test UDP firewall rules?
No. TCP and UDP are separate protocols and may have different rules. Use an authorized, targeted UDP scan such as nmap -sU -p 53 TARGET, and interpret results cautiously because UDP services may not reply.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.