6.1Filtering traffic with a firewall

In network support, a frequent report is "only a specific service will not connect." One cause is filtering by a firewall placed at the traffic boundary. A firewall is a checkpoint that decides by rules which traffic to pass (permit) and which to stop (deny), hardening defenses with a default-deny posture of blocking by default and opening only what is needed. This section covers a firewall's basic behavior, typical ports/protocols that are commonly blocked, and the stateful mechanism that remembers the state of a connection—through the lens of isolating "whether the filter is the reason traffic will not arrive."

6.1.1A firewall's role and rules

• A firewall is a device or software placed at the boundary between networks of different trust (e.g., between an internal LAN and the internet) that screens passing traffic by rules. By deciding "pass or stop," it limits unauthorized access from outside and unnecessary traffic from inside.
• The instruction to pass traffic is permit, and to stop it is deny. Rules mainly decide by source/destination IP address and port number/protocol (e.g., TCP 443, UDP 53). A set of rules is a list, line by line, of what to pass or stop when a condition matches.
• The basic stance is default deny—"stop everything except what is explicitly permitted." Open only the needed services (e.g., HTTPS for web browsing) with permit rules and keep the rest closed by default, reducing open holes.

6.1.2Stateful filtering and commonly blocked traffic

• A stateful firewall remembers the state of ongoing connections. It automatically allows the return (response) to traffic initiated from inside—without a separate permit rule—while stopping connections that suddenly start from outside by default. Modern firewalls are mainly this stateful type.
• Commonly blocked examples include unencrypted, risky Telnet (TCP 23), SMB/file sharing (TCP 445) that is dangerous to expose externally, and internal management ports. Conversely, business-essential traffic such as HTTPS (TCP 443) for web browsing and DNS (UDP 53) for name resolution is often permitted.
• In support, suspect the firewall when "ping succeeds but only a specific app will not reach." ICMP may be allowed while only the port the app uses is blocked, so the standard move is to check whether the port/protocol the traffic uses is permitted by the rules.

Suppose the help desk gets a report: "from inside the office we simply cannot connect to the new cloud accounting service (HTTPS)." Before hastily concluding "the server is down," isolate where it stops. Sending ping from the PC to the service's hostname returns replies—so L3 reachability exists and name resolution works. Yet the browser still will not connect. This symptom of "ping succeeds but only HTTPS fails" strongly suggests a firewall on the path is denying TCP 443 (HTTPS). It is a common pattern that ICMP (ping) is allowed while only the port the app uses is left closed under default deny. The key here is that the firewall is stateful: if there is a single permit rule allowing outbound HTTPS from inside, its return traffic passes automatically, so no separate hole needs opening for the return. Therefore what to check is "whether outbound TCP 443 from inside toward the cloud is permitted," and if needed, ask the network administrator to add a permit rule for that service. Conversely, if even ping fails, the suspicion shifts before the firewall to L3 reachability or DNS. Separating "whether ping works" from "whether a specific port works," and telling the filter's involvement from the symptom, greatly speeds up root-cause analysis.

6.1.3Section summary

• A firewall screens traffic at a boundary with permit/deny rules and, under default deny, opens only what is needed
• A stateful firewall automatically allows the return of inside-initiated traffic while stopping suddenly outside-initiated traffic by default
• When ping succeeds but only a specific app fails, suspect whether that app's port/protocol is permitted by the rules