Can someone walk me through setting up a firewall in my homelab?

General
1

I’m building a small homelab to learn networking and self-host a few services, but I’m stuck on how to properly set up a firewall. I’m not sure what rules I actually need, how to separate my lab from the rest of my home network, or how to avoid locking myself out remotely. Can someone explain the basics and maybe share a safe starter rule set for a homelab firewall?

2

I’ll walk through a simple, sane homelab firewall layout that works for most people.

Goal:

  1. Keep lab separate from home devices.
  2. Expose only a few services safely.
  3. Make it easy to manage and debug.

Assume:
ISP modem/router → Your firewall box → Switches/APs → Clients

Use something like OPNsense, pfSense, or a Linux box with nftables/iptables.

  1. Plan your networks

Pick at least three VLANs / interfaces:

WAN:
From ISP. No services listen here.

LAN:
For normal home stuff.
Example: 192.168.10.0/24

LAB:
For homelab servers, VMs, containers.
Example: 192.168.20.0/24

Optional extras later:
GUEST WiFi: 192.168.30.0/24
IOT: 192.168.40.0/24

  1. Basic interface setup

On the firewall:

WAN:
DHCP from ISP.

LAN:
Static 192.168.10.1/24
DHCP range 192.168.10.100-200

LAB:
Static 192.168.20.1/24
DHCP range 192.168.20.100-200
Or static addresses for servers.

If you use VLANs, tag them on your switch and AP, and assign VLAN interfaces on the firewall.

  1. Default firewall rules

Rule mindset:
Start with default deny from WAN.
Default allow from internal nets to WAN, then tighten as you grow.

On WAN interface:
Block all inbound by default.
Allow only:

  • ESTABLISHED, RELATED states
  • Specific port forwards you decide to open

On LAN interface:
Allow:

  • LAN net → Any (so LAN devices reach internet and LAB)
    If you want stricter:
  • LAN net → WAN net
  • LAN net → LAB net on specific ports if needed.

On LAB interface:
Safer layout:

Allow:

  • LAB net → WAN net (internet)
  • LAB net → DNS resolver on firewall
  • LAB net → NTP on firewall

Block or limit:

  • LAB net → LAN net (so lab cannot poke at home PCs)
    You can add specific exceptions, for example:
  • LAB net → 192.168.10.50 port 22 (SSH to one host)
  • LAB net → 192.168.10.10 port 3389 (RDP to one host)

On firewall (local rules):
Allow admin from LAN only:

  • LAN net → firewall IPs for HTTPS GUI, SSH
    Optionally block LAB net from reaching the firewall GUI.
    Allow LAB net only to SSH if you admin from there.
  1. Isolate the lab from the rest of the house

Core rules for isolation:

On LAB interface rules:
Top to bottom:

  1. Allow LAB net → firewall for DNS, NTP, maybe SSH
  2. Allow LAB net → WAN net (any) for internet
  3. Block LAB net → LAN net (any)
    Or more strict:
    • Block LAB net → 192.168.10.0/24

On LAN interface:
You can let LAN reach LAB so your main PC manages the lab:

  • LAN net → LAB net (any)

So result:
LAN → LAB allowed.
LAB → LAN blocked.
Both → internet allowed.

That is usually what people want.

  1. Port forwarding for public services

Expose services from LAB to the internet through reverse proxy or direct ports.

Example:
You have a web app in LAB at 192.168.20.10 port 80.

On firewall:
Port forward on WAN:

  • WAN address port 80 → 192.168.20.10 port 80
  • NAT reflection on if you care about internal access by public name.

Better:
Run a reverse proxy (Caddy, Traefik, Nginx) in LAB, and forward only 80 and 443 from WAN to that reverse proxy VM or container. Then internally route to apps.

Always:

  • Only forward what you need.
  • Use TLS.
  • Keep external ports small in number, like 80,443,22 if you must.
  1. DNS layout

Use your firewall as DNS resolver so you control names.

On firewall:

  • Enable DNS resolver.
  • Set DHCP to give out firewall IP as DNS.

For internal hostnames:
Create host overrides:

  • nas.lab.local → 192.168.20.10
  • proxmox.lab.local → 192.168.20.11

If you expose something public, use normal DNS from your domain registrar to point to your WAN IP, then forward to the lab reverse proxy.

  1. Logging and testing

Turn on logging for your block rules at first:

  • Log LAB → LAN block rule.
  • Log WAN blocked packets.

Then on a client:

From LAN:

  • Ping lab server IP.
  • Connect to its SSH or web UI.

From LAB:

  • Try to ping a LAN device.
    Should fail if rules are right.
  • Try to reach the internet.

From outside (phone on LTE):

  • Hit your WAN IP or domain for published services.
  1. Simple rule order example

OPNsense / pfSense style, top to bottom:

WAN:

  1. Allow TCP 80,443,22 to specific internal host(s) (if needed).
  2. Default block any, log.

LAN:

  1. Allow LAN net → any.

LAB:

  1. Allow LAB net → firewall address ports 53,123,22 (DNS, NTP, SSH)

  2. Allow LAB net → WAN net any

  3. Block LAB net → LAN net any, log

  4. Hardware tips

If you run up to 1 Gbps and some VLANs:
Small x86 box, 2 or 4 NICs, 4–8 GB RAM is enough.

If you use WiFi from the ISP router, put ISP box in bridge mode if possible, let your firewall handle NAT. If not, double NAT still works for a homelab, just forward from ISP box to your firewall WAN.

  1. How to grow it

Once this works, you can:

  • Split LAB into DEV and PROD VLANs with different rules.
  • Add an IOT VLAN, block IOT → LAN, allow IOT → WAN only.
  • Use VPN on the firewall for remote admin, so you stop opening SSH direct from WAN.

If you post your gear, IP ranges, and what services you want exposed, it is possible to write exact rules line by line.

3

You’re already 80% there if you just get the concepts right, the exact product is secondary.

I’ll take a slightly different tack than @himmelsjager and focus on “how to think” about the firewall so you don’t end up with a fragile rule mess.

1. Decide what you actually care about

Write this down, literally:

  1. Home stuff must not be broken by the lab.
  2. Lab stuff must not be able to rummage around my personal devices.
  3. A few services should be reachable:
    • From LAN only (e.g. Proxmox, NAS)
    • From the internet (e.g. reverse proxy, maybe SSH)

If a rule does not help one of those, you probably don’t need it at first.

2. Start with fewer networks, then split

I slightly disagree with the “add a bunch of VLANs first” approach. It’s educational, but people new to this often drown in complexity.

Bare minimum to learn a lot without going crazy:

  • LAN for home stuff: 192.168.10.0/24
  • LAB for servers/VMs: 192.168.20.0/24
  • WAN from ISP

You can absolutely bolt on GUEST, IOT, etc. later when you’re not still fighting DHCP and routes at 1 a.m.

3. Use a “trust level” mindset, not a device-type mindset

Instead of “lab vs home,” think:

  • High trust: your main PC, admin laptop
  • Medium trust: lab infra (hypervisors, containers, services)
  • Low trust: IoT, random VMs you’re testing

Then:

  • High trust can reach almost everything.
  • Medium trust can reach the internet and some high trust hosts if needed.
  • Low trust can mostly just reach the internet.

Practically, for you right now:

  • Put your main PC on LAN = high trust
  • Put lab infra on LAB = medium
  • Treat IoT as “later problem”

4. Concrete rule set to get you moving

Assume pfSense / OPNsense style, but applies generally.

WAN interface:

  • Rule 1: Allow “Established / Related” traffic
  • Rule 2: Block everything else, log

Add port forwards later like:

  • WAN TCP 80/443 → reverse proxy in LAB
  • Maybe WAN TCP 22 → a hardened SSH box in LAB (or better, use VPN instead)

LAN interface:

Start stupid simple:

  • LAN net → any allow

This makes sure your home devices and your main PC just work. You’re not running a bank.

LAB interface:

This is where you actually isolate:

  1. LAB net → firewall address (DNS, NTP, maybe SSH) allow
  2. LAB net → WAN net any allow
  3. LAB net → LAN net any block, log

Optional “nice to have” after that works:

  • Add a rule above the block:
    • LAB net → 192.168.10.X port 22/3389 allow if you want to manage a specific LAN machine from the lab.

End result:

  • LAN → LAB: allowed (so you can admin lab from your main PC)
  • LAB → LAN: blocked, except your explicit pins
  • Both → internet: allowed

That “triangle” is usually the sweet spot.

5. Keep NAT and routing boring

On the firewall:

  • WAN: NAT outbound as default (usual “automatic outbound NAT” is fine)
  • LAN + LAB: both are “internal” networks; they just need routes.
  • Do not add static routes to anything weird until normal internet + inter-VLAN behavior works.

If your ISP router cannot be bridged and you’re stuck with double NAT, don’t panic. Just:

  • Put firewall WAN in the ISP router’s DMZ or forward “any” to it.
  • Treat ISP box as a dumb upstream.

For a homelab, that’s fine.

6. Safe way to test without breaking the house

In this order:

  1. From LAN:

    • Can you browse the internet?
    • Can you ping 192.168.20.x lab hosts?

  2. From LAB:

    • Can you reach the internet?
    • Can you ping 192.168.10.x? It should fail if the block rule is right.

  3. From outside (cellular on phone):

    • Only after you add a specific port forward, test that one service.
    • If something you didn’t intend is reachable, your WAN rules are wrong.

Don’t open a bunch of WAN ports at once. Forward one, test, then move on.

7. A simpler way to expose multiple services

Instead of forwarding 10 different random ports, set up:

  • One reverse proxy VM/container in LAB, e.g. Caddy or Nginx:
    • Internal IP: 192.168.20.10
  • On firewall:
    • WAN TCP 80,443 → 192.168.20.10 80,443

Now all your homelab web apps live behind that one box. New app? Just add a vhost / route on the reverse proxy, don’t touch firewall rules again.

8. When you’re ready to level up

Once this basic two-subnet setup feels boring:

  • Split LAB into:
    • LAB-PROD and LAB-DEV VLANs
    • Different rules between them
  • Add IOT:
    • IOT net → WAN only, block IOT → LAN and IOT → LAB

By that point the rule logic will feel natural instead of magic.

If you post:

  • What firewall platform you ended up with
  • Current IP ranges
  • What specific services you want exposed and to whom

you can get very literal “line 1: allow X → Y on port Z” type rules. But don’t overcomplicate it yet. Two internal nets, default-deny from WAN, block LAB → LAN, and you’ll already be in way better shape than most home setups.