Firewall Filtering and Traffic Policy

How Firewalls Filter Traffic

Cisco lists the ability to describe how firewalls filter traffic as a CCST Networking skill. At support-technician depth, the goal is not to design an enterprise security architecture from scratch. The goal is to understand what a firewall is likely doing when a user can reach one resource but not another, when a service works from one network but fails from a different network, or when a new device needs only a narrow set of access.

A firewall enforces rules between networks, interfaces, or security zones. A basic rule might say: allow inside clients to initiate HTTPS traffic to the Internet. Another rule might say: deny guest wireless clients from reaching the internal office subnet. Rules commonly match source IP address, destination IP address, protocol, TCP or UDP port, direction, ingress interface, egress interface, user identity, application, or time. The firewall compares traffic to policy and then permits, denies, logs, or inspects the traffic according to the matching rule.

Ports matter because many applications use well-known transport-layer ports. Web browsing over HTTPS commonly uses TCP port 443. DNS commonly uses UDP port 53, and sometimes TCP port 53. DHCP uses UDP ports 67 and 68. If a web server listens on TCP 443 but the firewall allows only TCP 80, users may report that the server is down even though the server, cable, and IP route are fine. Firewalls can also block by IP subnet, so a service may work from the IT VLAN and fail from the guest VLAN by design.

Modern firewalls are often stateful. A stateful firewall tracks connections so return traffic for an allowed outbound session is permitted automatically. For example, if an inside laptop starts an HTTPS session to a public web server, the return packets from that server can come back through the firewall because they belong to an established session. This is different from opening inbound access from the Internet to an internal host. Inbound access usually requires a deliberate rule and, in many small networks, a NAT or port-forwarding configuration.

A default deny or implicit deny policy is common: if no rule permits the traffic, the firewall blocks it. That makes rule order important. Many policies are evaluated from top to bottom, and the first match wins. A broad deny rule placed above a narrow allow rule can break access. A broad allow rule can create unnecessary risk. Least-access thinking should guide firewall rules: allow only the sources, destinations, protocols, and ports needed for the business or home use case.

When troubleshooting, avoid assuming every failure is a firewall problem. First confirm the client has a usable IP address, default gateway, DNS server, and local connectivity. Test by IP address when DNS is suspect. Confirm the destination service is listening. Compare a working client with a failing client: source subnet, SSID, VPN status, time of day, destination name, destination IP, and port. Useful escalation notes include the source IP, destination IP or FQDN, protocol and port, timestamp, error message, and whether the problem is new or tied to a recent change.

A technician should also understand logs at a high level. A firewall log can show allowed or denied traffic, translated addresses, rule names, zones, and reasons for drops. You may not have permission to change policy, but you can gather evidence that helps an engineer decide whether the rule is missing, too broad, too narrow, in the wrong order, or working exactly as intended.

Study Checkpoint

• Topic: Firewall Filtering and Traffic Policy.
• Verify the official Cisco concept before memorizing a shortcut.
• Practice the technician action: observe, document, test, fix when supported, or escalate.