Guest Wi-Fi that can't reach your servers: 5 OPNsense rules, in order
A guest network that only gets the internet takes one alias and five firewall rules on the GUEST interface, in a specific order. DNS and DHCP to the firewall, block every private range, block the firewall itself, then allow the internet. Here is the full table and how to test it from a phone.
Your guests can see your server. If visiting phones, a friend's laptop and the smart plug you don't really trust all land on the same network as your NAS and your Proxmox host, every one of them can reach those web pages. A separate Wi-Fi name doesn't change that on its own. The firewall rules behind it do.
The good news: on OPNsense, a guest network that gets the internet and nothing else is one alias and five rules. The order of those rules is the whole job.
The trap: a guest network that is only a name
Giving guests their own interface or VLAN is step one, and it's easy to stop there. Without rules that block the private ranges, the guest network looks separate and isn't: the separation comes from the rules, not from the interface.
There's a second, quieter leak: the firewall itself. Even when guests can't reach the NAS, they can often still load the firewall's login page or try SSH on it. Nobody on guest Wi-Fi needs either.
Before you touch a rule
Snapshot the firewall VM first. On a Proxmox host:
qm snapshot 100 pre-hardeningIt takes seconds and turns a lockout into a two-minute rollback. Also keep a way into the console that doesn't depend on the firewall: the Proxmox web UI's noVNC console still works when OPNsense's rules are broken.
The fix, part 1: one alias for every private range
Go to Firewall → Aliases and create:
- Name:
RFC1918 - Type: Network(s)
- Content:
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
Those three ranges are the private address space your home networks live in: the main LAN, a servers network, and the firewall's own addresses on them. One alias means one rule can block them all.
The fix, part 2: five rules on the GUEST interface
Give guests (and any IoT gear you don't trust) their own interface or VLAN. Then, on the GUEST interface, add these rules in exactly this order:
| # | Action | Source | Destination | Port | Purpose |
|---|---|---|---|---|---|
| 1 | Pass | GUEST net | GUEST address | 53 (TCP/UDP) | DNS to the firewall |
| 2 | Pass | GUEST net | GUEST address | 67-68 (UDP) | DHCP |
| 3 | Block | GUEST net | RFC1918 | any | No private networks, including the firewall's other IPs |
| 4 | Block | GUEST net | This Firewall | any | No web UI or SSH from guests |
| 5 | Pass | GUEST net | any | any | Internet |
Read it top to bottom and it tells the story:
- DNS to the firewall. Guests still need names to resolve, so they ask the firewall's address on their own network, and nothing else.
- DHCP. Guests still need an address. Ports 67-68 UDP to the GUEST address.
- Block every private range. This is the rule that does the heavy lifting. Guests can't reach the NAS, the Proxmox host, the house LAN, or any other private network, and that includes the firewall's IPs on those other networks.
- Block the firewall itself. No web UI and no SSH from guest devices.
- Allow the internet. With the private ranges and the firewall already blocked, guests get the internet and nothing else.
The two pass rules sit above the blocks on purpose: DNS and DHCP are the only two things a guest is allowed to ask the firewall for. The internet rule comes last, after everything private has already been ruled out.
Make guest DNS private too
Rule 1 sends guest DNS to the firewall, so it gets whatever the firewall does. Worth making that good while you're in there: in Services → Unbound DNS, enable Unbound with DNSSEC, and add at least two DNS over TLS upstreams, for example Quad9 (9.9.9.9, port 853, hostname dns.quad9.net) and Cloudflare (1.1.1.1, port 853, hostname cloudflare-dns.com). Verify from a client:
dig +dnssec example.com @<firewall-ip> # look for the "ad" flag
dig dnssec-failed.org @<firewall-ip> # deliberately broken: should SERVFAILTest it like a guest
A rule you didn't test is a rule you hope works. Join the guest Wi-Fi with a phone and try two things:
- Your NAS's web page. It shouldn't load.
- The firewall's login page. It shouldn't load either.
Then load any normal website. It should work. If a private page does load, check the alias content and the rule order against the table above.
Keep that test in your update routine. After every OPNsense update, the checks are: WAN up, DNS resolves, VPN tunnel connected, guest network isolated.
If you add a servers network later
The same thinking runs the other way. When your servers move to their own network behind OPNsense, block SERVERS → GUEST on the servers interface, and allow only the specific house-LAN access you need, such as your desktop to the servers' web UIs.
Checklist: guest network
- ☐ Firewall VM snapshot taken (
qm snapshot 100 pre-hardening), noVNC console reachable - ☐ Guests (and untrusted IoT) on their own interface or VLAN
- ☐
RFC1918alias:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 - ☐ GUEST rules in order: DNS, DHCP, block RFC1918, block This Firewall, pass any
- ☐ Unbound with DNSSEC and DNS over TLS upstreams
- ☐ Tested from a phone on guest Wi-Fi: NAS page and firewall login page both fail, the internet works
- ☐ "Guest network isolated" is on your after-update checklist
