Firewalls & Blocked Traffic

Chapter 6 left one question open: a refused connection could mean nothing is listening on that port, or it could mean a firewall explicitly rejected it — and from a plain client-side test, the two can look identical. This chapter is about diagnosing firewall involvement specifically, under the constraint most support engineers actually work under: you very often can't see the firewall's own rules or logs at all, because it belongs to another team, a cloud provider's own console, or an ISP.

Two Ways a Firewall Can Say No

A firewall rule that blocks traffic can do it two genuinely different ways, and which one it uses shapes what you'll actually see from the client side:

Both behaviors are entirely legitimate, deliberate configuration choices — DROP is often preferred specifically because it gives an attacker less information (a silent void looks the same whether a port is closed or actively blocked), while REJECT gives a faster, cleaner failure for legitimate traffic that isn't allowed. Distinguishing which one actually happened, and telling a firewall REJECT apart from a genuinely closed port, needs a packet-capture tool like tcpdump or Wireshark to inspect the actual ICMP response — deliberately out of scope for this course, but worth knowing the limit exists rather than assuming a simple client tool can always tell you.

Symptom Patterns That Point at a Firewall

Testing From Multiple Vantage Points

The single most useful technique available when you can't see the rules yourself is testing the exact same port from more than one location and comparing the results — the same instinct as Chapter 1's own scoping questions ("one user or many, one destination or everywhere"), now applied specifically to isolating a boundary rule. A port that opens cleanly from inside the same network as the server, but times out from outside it, is strong evidence for a boundary firewall or a cloud security group specifically — not the service itself, which is demonstrably working for at least one source.

Cloud environments make this pattern especially common: a AWS Security Group or Azure NSG can silently restrict a port to a specific source range, and a support engineer without console access to that layer may have no visibility into the rule at all — only its effect, which is exactly why comparing results from multiple vantage points is often the fastest available path to a confident answer.

Working Example: A Fresh Ticket

A new ticket, unrelated to the one resolved in Chapter 6: users report an internal reporting app is unreachable when connecting from home, but works fine in the office. DNS and network reachability both check out from every location tested. Testing the port itself from multiple vantage points narrows it quickly:

• From the office LAN: port opens immediately
• Connected via the corporate VPN, from home: port opens immediately
• Connecting directly from home, no VPN: the port times out every time

This pattern points precisely at a boundary rule that permits traffic from the office network and the VPN's own address range, but not from the general internet — consistent with a port-specific, source-scoped firewall rule. Worth being honest about the next step: this could be a genuine misconfiguration, or it could be entirely intentional access control — this app may simply have never been meant to be reachable without the VPN. The right next step is confirming which one it is with whoever owns that access policy, not assuming either answer and proceeding to "fix" something that might not be broken at all.

Hands-On Exercises