A firewall controls traffic at a particular point in a network or on a device. It can reduce unwanted access to exposed services and help separate networks with different levels of trust. Its value depends on the traffic that actually passes through it and the policy you configure, rather than simply having a product labelled as a firewall.
What Exactly Is a Firewall?
Imagine your home network as a secure building and the public internet as the bustling city outside. A firewall is the security checkpoint stationed at the perimeter. A packet filter evaluates addresses, protocols, ports and applicable connection state to decide whether traffic is permitted. Products use names such as ACCEPT, DROP and REJECT; a reject normally sends a response, while a drop silently discards the packet. Stateful processing can reuse an existing connection decision instead of evaluating every rule again. Application inspection is an additional capability, not a feature of every basic filter.
Why Is a Firewall Essential?
- Blocks Unsolicited Inbound Connections: Automated scanners continually look for exposed SSH, RDP, SMB, and database ports. A policy that blocks unwanted new inbound connections reduces that exposure; state tracking alone does not impose that policy. Check the active rules and exceptions.
- Enforces Network Segmentation (VLANs): Separate routed zones and explicit firewall rules can restrict IoT or guest access to trusted computers and NAS servers. Creating VLANs alone does not establish the required allow/block policy.
- Contains Malware & Command-and-Control Traffic: Outbound policy and suitable intrusion-prevention rules can block some known malicious destinations or patterns. An IDS can alert without blocking, and neither function detects every compromised device.
Types of Firewalls: From Packet Filters to NGFWs
Not all firewalls inspect traffic at the same depth. These common inspection approaches can overlap in one product; the layers below are a useful guide rather than a rigid classification:
| Firewall Type | OSI Layer | How It Inspects Traffic | Best Use Case |
|---|---|---|---|
| Stateless Packet Filtering | Layers 3 & 4 (Network / Transport) | Checks individual packet headers (Source/Dest IP, Port, Protocol) in isolation without tracking connection state. | High-speed router ACLs (Access Control Lists) for simple IP/port blocking. |
| Stateful Inspection Firewall | Layers 3 & 4 (State Table) | Tracks permitted TCP connections and inferred UDP flows using addresses, ports and timeouts; allows matching return traffic under the state policy. UDP has no TCP-style handshake. | Standard home routers, Linux nftables/ufw, and baseline pfSense/OPNsense setups. |
| Proxy / Application Gateway | Layer 7 (Application) | Terminates client connections and initiates a separate connection to the destination, inspecting application traffic where the proxy terminates the relevant encryption. | A reverse proxy or Web Application Firewall such as BunkerWeb for a specific self-hosted HTTP application; a WAF is not a general replacement for host or network filtering. |
| Next-Generation Firewall (NGFW) | Layers 3 – 7 (Deep Packet Inspection) | Combines stateful firewalling with Intrusion Prevention (IPS), application awareness, and real-time threat intelligence feeds. | Prosumer homelabs and business networks running OPNsense + ZenArmor / Suricata or Ubiquiti UniFi gateways. |
Default-Deny vs. Default-Allow: How Firewall Rules Work
Many home-network configurations start with a Default-Deny Inbound, Default-Allow Outbound posture:
- Inbound (WAN → LAN): Blocked by default. Only explicitly permitted services should accept new internet connections. IPv4 setups may combine a port-forwarding rule with an allow rule; IPv6 normally needs an explicit firewall policy without NAT. Private access can instead use an encrypted WireGuard VPN.
- Established & Related Return Traffic: When your laptop requests a web page on port 443, the stateful firewall records that session in its state table and permits the web server's reply packets back in.
- Inter-VLAN Rules (LAN ↔ IoT): In segmented networks, you can allow your main LAN to initiate connections to smart home devices (like a printer or Home Assistant hub) on the IoT VLAN, while blocking IoT devices from initiating connections back to your main LAN.
NAT, IPv6 and the Traffic That Bypasses the Gateway
Network address translation and firewall policy solve different problems. NAT maps addresses; the firewall decides which communications are permitted. Do not use the absence of an IPv4 port-forward as your only exposure check. IPv6 hosts can have globally routable addresses while still depending on explicit inbound filtering for protection.
Location matters just as much as the rule. Two devices on the same local subnet may communicate through a switch without crossing the router firewall. If a compromised laptop and NAS share that subnet, a WAN block rule does not decide whether the laptop can reach the NAS. Separate routed networks and host firewalls are the controls to evaluate for that path.
IPv6 filtering also needs to preserve the control traffic required for the network to function. Blanket blocking of ICMPv6 can disrupt features such as neighbour discovery and Path MTU Discovery. Use the platform's documented IPv6 policy and test it, rather than treating all control messages as unwanted application connections.
An Example Policy for a Small Homelab
Imagine three zones: trusted computers, IoT devices and servers. The following is a design example, not a rule set to paste unchanged. Replace broad groups with the actual source, destination and service needed in your network, and check rule order in the firewall you use.
| Traffic path | Example decision | Reason |
|---|---|---|
| Administrator computer to NAS HTTPS management | Allow the specific host and port | Provides a defined management path |
| IoT devices to trusted computers | Block new connections | Limits access from less-trusted devices |
| Home Assistant to one IoT device | Allow the required service | Keeps automation working without a broad network exception |
| Internet to server management ports | Block | Keep administration behind a private access path |
OPNsense documents state tracking and rule-processing order. An established session can continue using an existing state after a policy change. When testing a new block, start a fresh connection and inspect the state table rather than concluding that the rule is ineffective from an already-open browser tab.
Check a Linux Host Firewall Without Losing Access
On Ubuntu, UFW is a convenient interface for host rules. First confirm the actual SSH port and keep a local console or another recovery route available. This example allows a single administration address on SSH port 22 before enabling the firewall; 192.168.1.10 represents the administrator's computer.
sudo ufw allow from 192.168.1.10 to any port 22 proto tcp
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status numbered
Before changing an existing installation, inspect its current rules and identify any broad exceptions. Adding a narrow SSH allow rule does not cancel an older rule that already allows everyone. Replace the example address with the source address the server actually sees, including any VPN or NAT path, and account for IPv6 administration separately. Add the necessary application rules before enabling protection on a working server. Reconnect from the permitted computer and test from a second, disallowed source. The Ubuntu guide covers adding, inspecting and deleting rules. Review container networking separately: Docker's firewall integration can make published container ports reachable through paths that ordinary UFW rules do not filter as expected.
Read a Blocked Connection as a Troubleshooting Clue
Record the source, destination, protocol, port, interface and time from a blocked event. Then ask whether the traffic was expected. A blocked connection from an unfamiliar internet address can simply mean the policy is working. A blocked DNS query from your own client may explain why an otherwise healthy application cannot find its server.
Change one narrow rule at a time, test the intended access and the access that should remain forbidden, then save the result. Broadly allowing every port until an application works leaves no clear explanation of what it actually needs. Firewall maintenance is most useful when each exception has a purpose and can be removed when that purpose ends.
Firewall Pros and Cons
Pros
- Foundational Perimeter Defense: Blocks traffic that the policy does not permit; scanners can still probe the public connection.
- Granular Traffic Control: Enforces permitted traffic between zones; parental controls, GeoIP rules or VPN termination depend on the product and its additional services.
- Centralized Logging & Visibility: Can log selected traffic and rule decisions. Interface placement, NAT and logging settings affect which original clients and details are visible.
Cons
- Throughput Overhead with Deep Packet Inspection: Enabling full NGFW/IPS inspection (such as Suricata or ZenArmor) requires sufficient CPU and RAM to sustain multi-gigabit fiber speeds.
- Cannot Inspect Encrypted Payloads Without TLS Termination: A basic network filter sees addresses and some connection metadata, not the plaintext HTTPS payload. Inspection of that payload needs decryption at a supported endpoint, reverse proxy or deliberately configured TLS inspection proxy. Forward inspection requires managed client trust and can affect application compatibility; it is not automatic on an ordinary home router.
Conclusion
I regard a properly configured firewall as a crucial part of home and homelab security. It controls a traffic path; updates, account protection, endpoint security and backups address other risks. A permitted HTTPS connection can still lead to a phishing page, so an allow decision is not proof that the destination or its content is safe. Curious whether you should rely on an endpoint firewall or a dedicated appliance? Read our follow-up comparison on Hardware vs. Software Firewalls or learn how to build your own Raspberry Pi Hardware Firewall.



