Network Security Group Services and Emergency Plan
Post #017 — Network Infrastructure
Network Security,
Groups / Services.
30+ Devices. No Control. Here's How That Changed.
Pi-hole dashboard — 32 active clients · 14.4% of all DNS queries blocked
A few weeks ago I had 30+ devices on a single flat network. Everything could see everything. The router was handing out IPs without knowing who was who, and I had zero visibility into what was actually happening on the network. It worked — until it didn't feel right anymore.
This isn't a post about blocking YouTube or locking down guest WiFi. This is about something simpler and more important: knowing what's on your network, giving each group of devices exactly the access it needs, and nothing more. Once OPNsense was back online and stable, this was the next step.
The Numbers Right Now.
CURRENT STATE
|
32
Active Devices
On the network right now. All mapped, all assigned to a group. |
14.4%
DNS Blocked
Of all DNS queries on the network. Blocked before they leave. |
5
Security Groups
Each with its own ruleset. Assigned by MAC address. |
Groups and Segmentation.
WHO GETS WHAT
Every device gets classified by role. Not by who uses it — by how it should behave on the network. That's the key distinction. A family member's phone gets assigned to a group based on what level of access makes sense for that device, not based on who they are.
The groups are assigned by MAC address in Pi-hole. MAC addresses don't change, so the policy follows the device regardless of what IP it gets assigned. Right now the network has five active groups:
|
Employees
Work-focused access. Office machines, productivity tools, stable connectivity.
Full LAN access
Adult content blocked
Timed internet access
|
Visitors
Internet only. Isolated from internal devices, servers, and storage.
Internet access only
No LAN access
APK installs blocked
|
|
Kids
Parental controls, content filtering, screen time limits, controlled gaming access.
Adult content blocked
App install control
Timed access
|
Grandpa
Custom protection profile. Aggressive ad blocking, restricted installs. Its own thing.
App whitelist only
APK domains blocked
Extra protection active
|
|
Gaming / TVs
Media and gaming devices. Ad blocking active, no install restrictions. These devices consume content — they don't install software.
Full internet access
Ad blocking via Pi-hole
APK sideloading blocked
|
|
The Grandpa Rule.
NOT PUNISHMENT — CONTAINMENT
This one deserves its own explanation because it's not obvious from the outside.
The phone is on its own policy. The issue isn't browsing habits or anything personal. The issue is that certain device types are magnets for bad APK installs — fake app stores, ads that look like download buttons, links in messages that lead somewhere unexpected. An older user on an Android device with no restrictions is a real risk. Not because of intent. Because the attack surface is wide open.
The ad appears. The link resolves to nothing. Pi-hole blocks the APK download domains at the DNS level — the install never starts. No error message. No friction. The phone works normally for everything else.
This is the part most people don't think about when setting up a home network. The threat isn't always external. Sometimes it's a trusted user on a device that doesn't know how to protect itself.
Pi-hole — Network-Wide Ad Blocking.
NO EXTENSIONS. NO INSTALLS. NO PER-DEVICE CONFIGURATION.
Pi-hole runs on the NUC at 192.168.2.114. Every device on the network uses it as its DNS resolver — configured once in OPNsense, applied everywhere automatically. Smart TVs, phones, tablets, game consoles. None of them need anything installed.
After the first week: 32 active clients, 14.4% of all DNS queries blocked. That number will move as I tune the blocklists and add group-specific rules. The baseline is already there.
Pi-hole — 117,055 total queries · 16,877 blocked · 84,231 domains on lists
Why DNS-level blocking matters: Pi-hole blocks the request before it leaves the network. The device never connects to the ad server. This works on every device without touching the device itself — including TVs and consoles that have no browser extension support.
The OptiPlex Incident.
THE SIGNAL
In the middle of all this, the OptiPlex started to smell. Not smoke — not catastrophic. But that specific warm-electronics smell that means something is running hotter than it should. The capacitors, maybe. Thermal paste on a 15-year-old machine that's now doing real work 24/7.
I didn't panic. I documented it and started planning. If OPNsense goes down, the network goes with it. And that means the businesses go with it. That wasn't acceptable.
The Emergency Router Kit.
WHAT DIDN'T EXIST BEFORE
That's why the emergency router kit exists. A TP-Link E900 — small, cheap, fast — pre-configured and sitting in the rack. Not plugged in. Waiting.
The E900 is already configured with the same network range, same DHCP, and DNS pointing to Pi-hole on the NUC. The NUC runs independently — Pi-hole doesn't care which router is handling DHCP, as long as the DNS queries keep coming.
Network 192.168.2.x
Gateway 192.168.2.6
DHCP Range 192.168.2.100 – 192.168.2.149
DNS 192.168.2.114 <- Pi-hole (NUC)
Status Pre-configured. Ready.
| Failover Procedure — Estimated Time: 2–3 min | |
| Step 01 | Unplug the OptiPlex from the switch. |
| Step 02 | Plug in the E900 to the same port. |
| Step 03 | Wait 2–3 minutes for DHCP leases to renew. |
| Done | Network is back. Pi-hole is still running. Businesses continue. |
Pi-hole runs on the NUC, independent of OPNsense. If the firewall goes down, the DNS blocker keeps working. The two services are decoupled by design.
This Is a Living System.
WHERE THIS GOES NEXT
What I have right now is a baseline. The groups exist, the MAC assignments are in place, Pi-hole is logging everything. But the rules are going to evolve — as I learn more about how each group actually uses the network, as new devices come in, as I identify patterns in the query log that need addressing.
Security isn't a configuration you set once. It's an ongoing process of observation and adjustment. The infrastructure is there to support that process — not replace it.
Next phase: OPNsense firewall rules between VLANs, WireGuard for remote access, and the WD EX2 coming back online with its own access policy. The foundation is built. Now it gets layered.
Hardware in This Post.
WHAT I'M ACTUALLY USING
- TP-Link E900 — Emergency failover router. Pre-configured, same network, same DNS. 2-minute swap if OPNsense goes down.
- Intel NUC D34010WYKH — Running Pi-hole 24/7. 8GB RAM, compact, low power draw, independent of the firewall.
- Multicolor Network Cables — Black for LAN, white for WAN, red for the emergency kit. Color-coded from day one.
Related Posts
- My Network Has No Firewall Right Now. Here's Why That's Temporary. — Post #008
- Got the Firewall Running Again. — Post #011
- OPNsense Back Online. — Post #014
- A 2014 Mini PC. Two Services. Zero Monthly Fees. — Post #013
This post contains Amazon affiliate links. If you purchase through them, I may earn a small commission at no extra cost to you. Every product listed here is something I personally own and use.
Comments
Post a Comment