Setting Up a Home Firewall That Doesn't Break Everything

Two Firewalls, Not One

Your router already has a firewall, and it's already doing the single most important job: nothing from the internet gets to your devices unless you asked for it, via NAT and a default-deny inbound stance. That's your first layer. A host-level firewall, like ufw on Linux or Windows Defender Firewall, is your second: it controls what talks to that specific machine, including other devices on your own network. You want both, because the router protects you from the internet and the host firewall protects you from everything already inside it, including a compromised smart bulb or a laptop you brought home from somewhere you don't fully trust.

Default Deny Inbound, Default Allow Outbound

This is the baseline stance for almost every home setup, and it's worth understanding why the two directions are treated differently. Inbound connections you didn't initiate are, by definition, someone or something reaching in, so blocking them by default costs you nothing you're using. Outbound is riskier to lock down by default because so much of what you actually do depends on your own devices reaching out: updates, DNS, every app you own. Start with inbound deny and outbound allow, and only tighten outbound later if you have a specific reason to, like isolating a smart home device that has no business talking to the internet at all.

The Rules That Actually Break Things

Almost every "the firewall broke my network" story traces back to local discovery traffic, not internet traffic. mDNS (the protocol your printer, Chromecast, and AirPlay devices use to find each other, usually over UDP port 5353) and DHCP (UDP 67/68, which is how your devices get an IP address at all) both rely on broadcast or multicast packets that a naive default-deny rule set will happily eat. Before you tighten anything, know what's supposed to be able to talk to what on your own LAN, and carve out explicit allow rules for local discovery and DHCP before you lock down the rest. Losing Chromecast for a day is how most people learn this the hard way.

ufw Is a Front End, Not a Different Firewall

On Linux, ufw (uncomplicated firewall) isn't a separate firewall engine, it's a friendlier interface over the same iptables/nftables rules the kernel was always going to enforce. A minimal, sane starting point looks like ufw default deny incoming, ufw default allow outgoing, then explicit ufw allow rules for whatever you're actually running: SSH on your chosen port, a web server if you're hosting one, and nothing else. Run ufw status verbose after any change so you're reading back what you actually configured, not what you meant to.

Test It Before You Trust It

A firewall rule you haven't tested is a guess wearing a config file. After any change, verify from outside your own assumptions: run a port scan against your public IP from a phone on cellular data (not your home WiFi) to confirm nothing's exposed that shouldn't be, and check that the services you meant to keep working, printing, casting, file shares, still do from another device on the LAN. If you have a service exposed intentionally, confirm it's reachable from outside and nothing else is. Five minutes of testing catches the mistake before it becomes "why hasn't my backup run in two weeks."

Log Drops, But Don't Drown In Them

Logging every dropped packet sounds like good practice until your log file fills with the internet's constant background scanning noise and you stop reading it entirely. Log drops, but rate-limit the logging rule itself (ufw and nftables both support this) so a single noisy source doesn't bury the one entry you actually needed to see. A firewall log nobody reads protects nothing more than a firewall with no log at all.