Firewall Filtering and Traffic Policy

How Firewalls Filter Traffic

The Cisco Certified Support Technician (CCST) Networking exam (exam code 100-150, 50 minutes, a question count Cisco says varies by exam form, no publicly published passing score, US $125 through Certiport) lists "describe how firewalls filter traffic" as a skill. At technician depth you do not design enterprise security; you explain what a firewall is doing when a user reaches one resource but not another, or when a new device needs only narrow access.

A firewall is a policy-enforcement device that sits between networks, interfaces, or security zones (named trust levels such as inside, outside, DMZ). Each rule lists match conditions and an action. A rule might read: permit inside hosts to initiate HTTPS to any outside host. Another: deny guest VLAN to the 192.168.10.0/24 office subnet.

What rules match on

Ports matter because most apps use well-known transport ports. HTTPS is TCP 443, plain HTTP is TCP 80, DNS is UDP 53 (TCP 53 for zone transfers and large answers), and DHCP uses UDP 67 (server) and 68 (client). If a web server listens on TCP 443 but the policy permits only TCP 80, users report "the site is down" while the cable, route, and server are perfectly healthy.

Stateful vs. stateless

Most modern firewalls are stateful: they record each session in a connection (state) table, so when an inside laptop opens an HTTPS session outbound, the matching return packets are permitted automatically because they belong to an established connection. This is fundamentally different from opening inbound access from the Internet to an internal host, which normally requires a deliberate rule plus, on small networks, NAT port forwarding. A stateless access list, by contrast, inspects each packet in isolation and would need explicit return-direction entries.

Rule order and default deny

Policies usually evaluate top to bottom, first match wins, ending in an implicit deny: if nothing permits the traffic, it is dropped. So a broad deny placed above a narrow allow silently breaks access, and a broad allow placed too high creates risk. Apply least-access thinking: permit only the source, destination, protocol, and port the use case requires.

Worked troubleshooting example

A user on the guest SSID cannot reach the wiki at https://wiki.corp.local but a teammate on the wired LAN can. Steps: (1) confirm the guest client has an IP, mask, gateway, and DNS; (2) test by IP to bypass DNS; (3) confirm the wiki listens on the expected port; (4) compare the two clients — they differ only by source subnet. Conclusion: a boundary rule denies guest-to-internal, working as designed, not a fault.

Common traps

• Assuming every failure is the firewall — most are DNS, addressing, or a stopped service.
• Forgetting the implicit deny when a rule "should" match but does not.
• Ignoring that a firewall log can show the dropped rule name, zone, and reason even when you cannot change policy.

Good escalation notes: source IP, destination IP/FQDN, protocol, port, timestamp, exact error, and whether the issue is new or follows a recent change.

Where firewalls live in a small network

In a home or small office, the firewall is usually built into the same box that does NAT and Wi-Fi. NAT itself provides a side effect of inbound protection: because internal hosts use private RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) that are not routable on the public Internet, unsolicited inbound connections have nowhere to land unless a port-forward maps them in. This is not a substitute for a real firewall policy, but on the exam you should connect the ideas: a default home setup blocks most inbound traffic largely because of stateful NAT, while outbound traffic flows freely.

Larger sites place a dedicated next-generation firewall (NGFW) at the perimeter that can match on application identity and user identity, not just IP and port — so it can permit "Salesforce" while denying "BitTorrent" even when both ride TCP 443. A CCST technician does not configure these but should recognize the terms when reading a ticket or a vendor screen.

Reading a deny in a log

A single log line typically shows the action (built/teardown/deny), the source and destination IP and port, the protocol, the interface or zone pair, and the matching rule or ACL name. If a user's traffic appears in the log with a deny against a named rule, you have proof the firewall is the cause and a precise rule to hand to the security engineer. If the traffic never appears in the log at all, the packet may be lost earlier — at addressing, routing, or DNS — and the firewall is likely not the problem. Always reason in that order: reachability first, then name resolution, then the listening service, then the policy.