To troubleshoot a firewall problem, prove where the traffic stops before changing any rule. Confirm the source, destination, port and direction, read the firewall log for that flow, check which rule matched, look at connection state and NAT, and change one thing at a time with a recorded rollback.
Where do you start?
Write the failing flow as a sentence: "From 10.1.4.20 to 10.2.8.5 on TCP 5432, started 09:10, fails with timeout." A timeout usually means a drop. An immediate refusal usually means the packet arrived and the destination service rejected it, which is not a firewall block at all. That one distinction rules out many tickets.
Then test from both sides. A connection test from the source host tells you what the client sees. A packet capture or the firewall's own flow log tells you what the firewall saw. If the firewall never logs the flow, the packet is not reaching it, and the fault is routing, a switch, a host firewall or a cloud security group upstream.
What do the logs tell you?
NIST's guidance on firewalls and firewall policy (SP 800-41 Rev. 1) treats logging as part of normal operation, and its log management guide (SP 800-92) says routine log analysis helps find security incidents, policy violations and operational problems. For a block, you want the rule that matched, the action and the interface. Without that, you are guessing.
Check that logging is on for the rules you care about. Many firewalls do not log permitted traffic by default and may not log the final deny.
Which problems come up most often?
Rule scope and order. NIST notes that rulesets should be as specific as possible about the traffic they control, and that vendors may have restrictions or suggestions on rule order. A broad deny placed above a narrow allow will block the traffic you meant to permit. A broad allow above a deny makes the deny dead.
Stateful tracking. A stateful firewall keeps a table of connections, typically with source and destination addresses, ports and connection state. NIST describes three major states for TCP: establishment, usage and termination, including long idle connections. If a database connection drops after an hour of silence, a state table timeout may be the cause, not a rule.
Asymmetric routes. If the return path goes through a different device, the second device never saw the handshake and may drop the reply. The symptom is a connection that starts and then hangs.
NAT. A rule written for the real address may not match once translation changes it. Check which address the firewall sees at the point of evaluation.
ICMP. NIST advises denying incoming and outgoing ICMP except for specific permitted types, but notes that type 3 messages should not be filtered, because they are used for important network diagnostics. Blocking them breaks path MTU discovery, and large transfers stall while small ones work.
Management and DNS. Firewall policies also cover things that are not traffic, such as who can change rules and where DNS and time servers are located. A wrong time source makes logs hard to correlate.
What should you avoid?
Do not add a temporary "allow any" to test. It teaches nothing about the cause and tends to stay in place. Do not change several rules at once. And do not close the ticket when the traffic works. Close it when you know why.
A constructed example
A team reports that a nightly job fails when it copies large files to a partner server, but small test files succeed. The flow log shows the connection established and then no further packets. A capture shows large packets sent with the do-not-fragment flag and no reply. Incoming ICMP type 3 had been blocked by a broad ICMP deny rule. The team permits that type for the path, retests with a large file, and records the rule with its reason so the next person does not remove it.
How to check or apply this
- State the failing flow precisely, with times, addresses, port and protocol.
- Distinguish a timeout (drop) from a refusal (service rejected).
- Find the flow in the firewall log and note the matching rule and action.
- Check rule order, scope, NAT, state timeouts and return path in that sequence.
- Change one rule, test, and document the reason and the rollback step.
- Review the ruleset afterward for rules that became unused or too wide.
Quick check
Why do small files pass and large ones fail?
A common cause is blocked ICMP type 3 messages, which breaks path MTU discovery. Large packets are dropped silently while small ones fit within the path limit.
The firewall log shows nothing. Is the firewall innocent?
Often, yes for that device. Either logging is off for the rule, or the traffic never reached it. Verify with a capture before blaming or clearing it.
Sources
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
- NIST SP 800-92, Guide to Computer Security Log Management
Last reviewed: 18 October 2026.
