This post walks through the config as it currently runs. Not a tutorial. Not a clean-slate build guide. Just what’s actually on the box, what each piece is doing, and which of the “this looks clever” choices turned out to be worth it.

What OPNsense replaced

The previous edge was a consumer router running vendor firmware. It worked. It also had opinions about DNS, UPnP, and what “internal” meant that didn’t line up with mine. The moment I wanted per-VLAN firewall rules and per-host DNS overrides, I’d hit a wall.

OPNsense runs on a small x86 box with two NICs. One is WAN, one is a trunk into the switch carrying tagged VLANs. The whole thing idles under 15% CPU with everything I’ve thrown at it.

Interfaces

Three interfaces that matter, plus the ones that don’t.

• WAN — the public side. spoofmac is set, blockpriv and blockbogons are both on. Anything showing up from RFC1918 or reserved space on the WAN gets dropped before it hits a single rule. This is a default, but it’s a default I’ve seen disabled “temporarily” on other people’s firewalls more times than I’d like.
• LAN (192.168.1.0/24) — the trusted network. Hosts, servers, my workstation, the things I wouldn’t want on a segment with a cheap IP camera.
• VLAN20_IOT (192.168.20.0/24) — everything that speaks a protocol I didn’t write and can’t audit. Cameras, smart switches, the TP-Link stuff, a Ring doorbell, an Apple TV. Anything that phones home on a schedule.
• VLAN30_GUEST (192.168.30.0/24) — guest Wi-Fi. Scoped tight and deliberately boring.

The WireGuard interface exists as a stub. The actual WireGuard endpoint runs on Boreas (the Raspberry Pi I wrote about previously) and terminates on LAN. Port 51820/udp is port-forwarded through OPNsense to it. The virtual interface here is reserved for a future on-box tunnel I haven’t needed yet.

Inbound: what’s actually exposed

A small, deliberate list. If something isn’t on this list, the outside internet can’t see it.

• 32400/tcp → Alecto (Plex). Plex’s own account server handles connection brokering; this is the fallback direct path.
• 25/tcp, 993/tcp → Alecto (SMTP inbound, IMAP-over-TLS). Yes, a residential SMTP listener is a lightning rod. I accept the noise in exchange for owning my own mail flow.
• 9001/tcp+udp → the Tor middle relay host. Advertised to the Tor directory as the relay’s ORPort.
• 443/tcp, 51820/udp → Boreas. 443 is Nginx Proxy Manager fronting Overseerr for friends and family behind Cloudflare. 51820/udp is the WireGuard handshake port for remote access.

Port 80 exists as a disabled rule. I leave disabled-but-documented rules in the config on purpose; they’re a paper trail for “this used to be exposed, here’s why it isn’t anymore.” Deleting them loses that context.

Nothing else is forwarded. No UPnP. No NAT-PMP. If a device wants to be reachable from outside, I add the rule by hand.

VLAN policy

The LAN rule is broad: trusted hosts can reach anything. The two VLANs get narrower treatment.

IoT VLAN (VLAN20)

• Can reach the router for DNS (53) and NTP (123). Nothing else on LAN.
• Can reach WAN on 80/443. That’s it.
• Blocked from every other internal subnet.

Guest VLAN (VLAN30)

• Can reach WAN on 80/443. Nothing else.
• Blocked from LAN, IoT, and the router’s management ports.
• Uses its own DHCP scope (192.168.30.50–200) with the router itself as DNS.

Guest users regularly ask why their work VPN client doesn’t connect. That’s not a bug. Guest is guest; if somebody needs a real tunnel, they’re not on guest.

DNS is the interesting part

I run Dnsmasq (not Unbound) across all three interfaces. Domain is home.lan. Upstream is Cloudflare 1.1.1.1 and 1.0.0.1. DNSSEC is off, which I’ll come back to. Authoritative DHCP is on, so DHCP leases produce DNS records for every host automatically.

The interesting part isn’t the resolver. It’s the firewall rules around it.

Forcing IoT through the router

Most cheap smart devices ship hardcoded with Google DNS (8.8.8.8) or similar. They don’t care what DHCP tells them; they use whatever the vendor baked in.

So there’s a NAT redirect on the IoT VLAN that rewrites any outbound connection to *:53 and sends it back to 192.168.1.1:53. The device thinks it’s talking to Google. It’s actually talking to OPNsense. From the device’s point of view, nothing changes. From my point of view, every DNS lookup for every IoT device is now logged locally and subject to the same filters as everything else.

The alias that drives this (TP_LINK) started as one device and grew organically. It now covers the usual IoT suspects including the NVR.

Killing the DNS escape hatches

DNS hijacking works until a device decides it would rather use DNS-over-HTTPS or DNS-over-TLS to bypass your resolver entirely. Modern OSes will happily do this without asking.

Three rules cover the escape routes:

• block-dns-tls-853 — drops TCP/853 outbound (DoT).
• block-doq-quic-853 — drops UDP/853 outbound (DoQ).
• block-doh — drops outbound to an alias called doh_providers.

doh_providers is a dynamic URL table alias. It pulls from the awesome-dnscrypt DoH server list on a 30-minute refresh. The alias updates itself; I don’t maintain it.

This isn’t perfect. DoH hiding inside a general HTTPS flow on port 443 is indistinguishable from any other HTTPS traffic without deep inspection, and I’m not terminating TLS at the edge. What the blocklist catches is lazy implementations that connect directly to a known public DoH provider’s IP, which is most of them.

The goal isn’t to stop a determined adversary. It’s to stop my smart TV from quietly ignoring my DNS server because its firmware author thought that was a reasonable default.

Aliases that earn their keep

Most aliases are boring host groups. A few are worth calling out.

• doh_providers — the dynamic DoH blocklist described above.
• crowdsec_blocklists / crowdsec6_blocklists — external aliases driven by CrowdSec. These hold the IPs that CrowdSec has decided are hostile. Any firewall rule referencing these aliases gets the current set of bad actors without me maintaining a blocklist manually.
• CLOUDFLARE_IPS — Cloudflare’s edge ranges. Used to scope inbound rules so that services meant to sit behind Cloudflare only accept connections from Cloudflare’s IP space. Anything hitting those services directly at my IP gets dropped.
• TP_LINK — the IoT forcing-function alias. Named after what started it. Now overloaded with everything in the “must be hijacked for DNS” bucket.
• TOR_RELAY — single-host alias pointing at the Tor machine. Useful for bundling rules even when the alias has one entry, because when the hostname inevitably moves, I change it in one place.

CrowdSec is doing the heavy lifting

The earlier home lab post mentioned Suricata. That’s no longer what’s on the box.

OPNsense now runs CrowdSec as the main threat-intel layer:

• Agent enabled — parses local logs and identifies scanning, brute-force, and common exploit patterns.
• LAPI enabled — the local API that the bouncer talks to.
• Firewall bouncer enabled — actively drops traffic from IPs flagged by the agent or by the CrowdSec community feeds.
• Rules enabled — the community scenarios load and run automatically.

CrowdSec is cheaper on CPU than Suricata was, and its blocklist model fits the home lab better than a full IDS pipeline. Suricata gave me floods of alerts I wasn’t going to investigate. CrowdSec gives me “this IP has been a problem elsewhere, dropped at the firewall.” Less signal, but the signal it produces is directly actionable because the action already happened.

I lost some visibility moving away from Suricata — notably per-flow inspection rules for specific CVEs. That trade-off has been fine for this environment. If this were an enterprise edge I’d run both.

Observability

A firewall with no telemetry is a box with opinions you can’t verify.

• NetFlow v9 is enabled on LAN and WAN, with WAN set to egress-only. Export target is a local collector at 127.0.0.1:2056 that ships flow records into the metrics stack on Alecto. Active timeout 30 min, inactive 15 sec.
• vnstat runs against the WAN interface for long-term bandwidth counters. It’s the “how much did I actually use this month” graph, not a security tool.
• Zabbix agent is enabled, reporting to Alecto. CPU, memory, interface counters, states table, per-rule hits. The Zabbix server decides what to alert on; the firewall just emits data.

The alerting philosophy is the same as the one in the honeypot post. The firewall is not the thing that should decide what’s worth waking me up over. Its job is to produce honest signal. Somebody else’s job is to filter it.

Hardening that isn’t glamorous

None of this is interesting to read. All of it matters more than the DoH blocklists.

• Web GUI is HTTPS-only. HSTS is on. The cert is self-signed because the GUI is only reachable from LAN and I’d rather pin the cert than introduce an ACME dependency for a single internal endpoint.
• Console menu is disabled. Physical access to the box doesn’t immediately give you the OPNsense menu. It gives you a login prompt.
• NAT reflection is off — fewer surprises with internal traffic taking unexpected paths.
• SSH is bound to LAN only, group-restricted to admins. It’s one of the few places I’m still running password auth with root allowed. Not because I think it’s fine, but because the exposure surface (LAN-only) makes it low-risk and a key-only migration is on the list below.
• Bogon updates run monthly. Reserved/unallocated prefixes change less often than people think, but they do change.
• Backups go to Google Drive via os-gdrive-backup on a schedule. The XML config is small enough that a month of daily snapshots costs nothing and saves hours if I ever have to rebuild.

Gateway monitoring

Single WAN, no failover. The gateway monitor pings 1.1.1.1 continuously with alert thresholds at 30% packet loss (low) and 35% (high), and 300ms latency (low). If the line is bad enough to notice, OPNsense will flag the gateway before I do.

No multi-WAN yet. The second ISP option in my area isn’t worth the monthly cost for the uptime I actually need. If that changes, gateway groups are already half-configured.

What I’d change

A few things are genuinely outstanding, not just aspirational.

• Turn on DNSSEC. Dnsmasq supports it; I disabled it years ago when a misbehaving internal service was breaking on stale signatures. That reason is long gone.
• Move SSH to key-only, disable root login. The exposure is LAN-only today but the migration is trivial and overdue.
• Ship syslog off-box. Right now logs live on OPNsense and get rolled locally. A remote syslog destination (somewhere on LAN, not off-site) would survive a firewall rebuild and give me history during incident response.
• Terminate TLS on a reverse proxy for the services that sit behind Cloudflare. Right now the tunnel ends on Boreas with NPM, which is fine. Moving cert management to an ACME plugin on OPNsense for the few public services would remove a moving part.
• Split LAN. The LAN rule is still “trusted hosts can reach everything.” That worked when LAN was five devices. It’s less defensible now. A management VLAN separate from a workstation VLAN is the next logical step.

Closing

The interesting parts of this config aren’t the exotic features. They’re the boring ones: a DNS policy that assumes devices will lie, per-VLAN egress rules that default to deny, inbound exposure that fits on a single screen, and telemetry that lets somebody else decide what’s worth acting on.

OPNsense makes all of that reachable from a UI without punishing you for running CLI alongside it. That’s a rarer combination than it sounds.

If you’re standing one up from scratch and wondering where to start: segment the network, hijack DNS on the untrusted segments, block the DNS escape hatches, and wire up telemetry before you wire up rules. Everything else is refinement on top of that.

This is a notes post about standing it up, how it’s contained, and what actually showed up in the logs after a month.

Why bother

Most threat intelligence I read describes the internet as a battlefield. Every unpatched device is five minutes from compromise. Every IP gets 30,000 probes a day. The numbers are usually correct. They aren’t useful unless you can map them to what your environment looks like.

I wanted my own baseline. Not a vendor’s feed, not an aggregated report. What does my ISP-assigned IP attract, right now, and what does the traffic look like when you strip out the marketing spin.

Secondary reason: I wanted to segment the network, and a honeypot is a good forcing function. My homelab had been flat for too long. Nothing makes you VLAN a network faster than hanging something deliberately exposed off it.

Threat model and ground rules

Before anything went online, I wrote down what I was willing to tolerate and what I wasn’t.

Willing to accept:

• My IP appearing on scanning blocklists.
• My ISP sending me a polite note. (They never did.)
• Getting buried in logs I’d then have to process.

Not willing to accept:

• Anything the honeypot attracts touching my real LAN.
• A honeypot compromise turning into a pivot into anything else I own.
• Outbound traffic that looks like I’m participating in someone else’s botnet.

Those three constraints drove every architectural decision that followed.

Architecture

The honeypot runs as a single VM on a secondary host, isolated on its own VLAN behind OPNsense. It has one purpose, no shared storage, no shared credentials, and nothing legitimate behind it. If it gets popped, I wipe the VM from snapshot and start again.

The physical picture:

• Honey-VM: 4 vCPU, 8 GB RAM, 60 GB disk. Ubuntu 22.04 base, T-Pot on top.
• VLAN 66: dedicated “DMZ-lite”. No inter-VLAN access. DHCP scoped tight.
• OPNsense: port-forwards a curated set of TCP ports from WAN to the honey-VM.
• Suricata on the OPNsense WAN interface logs everything hitting those ports, independent of what the honeypot itself sees.
• Outbound rules on VLAN 66: no outbound except to a specific syslog collector and to Cloudflare DoH for DNS. No SSH out, no SMB out, no SMTP out, no arbitrary outbound anything.

The last point is the one that matters most. A honeypot with open outbound is a honeypot that can participate in the abuse you’re trying to study. If Cowrie accepts a shell and the intruder tries to curl a second-stage payload, they should fail at the network, not at the endpoint.

Ports exposed to the internet: 22, 23, 80, 443, 445, 1433, 2222, 3306, 3389, 5060, 5900, 8080. Nothing else.

Stack

I used T-Pot for the heavy lifting. It’s maintained, it aggregates sensible honeypots, and its dashboards are ready out of the box. The components that mattered for me:

• Cowrie on 22 and 2222. SSH and Telnet. Logs full session transcripts.
• Dionaea on 445, 1433, 3306, 5060. Protocol emulation for SMB, MSSQL, MySQL, SIP.
• Heralding on anything else that smells like a login prompt.
• Honeytrap as the generic catch-all TCP listener.
• Snare / Tanner serving HTTP decoy content on 80 and 8080.
• Elasticsearch + Kibana for the dashboards, with data shipped out to my own Loki instance as a backup.

T-Pot’s internal firewalling is fine, but I don’t rely on it. The OPNsense rules are the real enforcement. If T-Pot broke tomorrow, nothing on VLAN 66 would suddenly start talking to my real network.

Standing it up

Provisioning was uneventful once the segmentation was in place.

# T-Pot install on a fresh Ubuntu 22.04
env bash -c "$(curl -sL https://ghst.ly/tpot-install)"

The installer handles Docker, pulls the containers, and wires up the reverse proxy for the Kibana side. The one thing I changed was restricting the admin web interface to the management VLAN, reachable only over WireGuard.

SSHD for actual host management got moved to a non-standard port on the management interface. Cowrie owns 22 on the WAN side.

Before opening the firewall, I ran a full scan from an external VPS against the advertised ports to make sure only the intended services responded, and that the banners looked realistic enough to not scream “honeypot” on the first handshake. A couple of Cowrie defaults were too obvious (the default SSH version string, for one) and needed tweaking. Anyone running OpenCanary fingerprints or Shodan’s honeypot detector will still figure it out. Most bots won’t.

First 24 hours

I expected a slow ramp while DNS caches and scanners noticed the IP. That wasn’t the experience.

Within 12 minutes of opening port 22, the first SSH login attempt came in. Inside the first hour: 340 SSH attempts from 47 unique source IPs. By the end of the first day: 8,200 SSH attempts, 1,100 HTTP requests, and around 60 SMB connections.

There is no onboarding period for a public IP. You’re in the database already. Opening a port just tells the scanners that something is finally listening.

What 30 days actually looked like

Rough totals at the 30-day mark (Suricata plus T-Pot aggregated):

• SSH and Telnet attempts: 412,000 across 22 and 2222, from 14,300 unique source IPs.
• HTTP requests to honeypot web roots: 28,400. Mostly scanner fingerprints and path probes.
• SMB connections: 3,900.
• MSSQL login attempts: 1,100.
• RDP connections: 9,700, almost all from a handful of subnets running NLA probes.
• SIP INVITE floods: two distinct campaigns, one targeting Asterisk defaults, one targeting a specific FreePBX module.

Geography is the least interesting dimension and the one vendors love to lead with. Source IPs spread across 90+ countries. That maps to compromised hosts, not operator location. Treating a GeoIP heatmap as a map of threat actors is a mistake.

The credential side is more useful. Top ten SSH username/password combinations over the 30 days, in order:

1. root / root
2. admin / admin
3. root / 123456
4. root / password
5. admin / password
6. user / user
7. ubnt / ubnt
8. pi / raspberry
9. root / 1234
10. support / support

None of those will surprise anyone who’s spent time on this. They confirm what the big honeypot operators have been saying for years: the low end of the attack surface is stuck on the same dictionary it’s been stuck on for a decade, because it keeps working.

What the payloads looked like

Cowrie logs full session transcripts, which is the part worth reading. Patterns I saw repeatedly:

• uname -a; cat /proc/cpuinfo; free -m as environment fingerprinting before any payload drop. The bot wants to know whether it landed on an ARM router, a MIPS camera, or an x86 box, so it can pull the right binary.
• A wget or curl chain pointing at a staging server, usually on port 80 over a direct IP with no DNS. Almost always a short-lived URL, dead within days.
• A chmod 777 on the downloaded binary, followed by ./<binary> and a quick rm to clean up.
• Busybox-style commands with shell tricks to survive minimal environments.

Three payloads I captured and detonated in an isolated environment later:

• A Mirai variant targeting MIPS and ARM, with the usual hardcoded C2 list.
• A Monero miner compiled for x86_64 with an embedded pool address and worker ID.
• An XorDDoS dropper with the “encrypted” strings still trivially XOR-decodable against a one-byte key.

Nothing novel. That’s the point. The mass of the internet’s attack noise is bots spraying five-year-old payloads at anything that looks like a vulnerable edge device. A residential IP running no listening services would never see this traffic because the TCP connections would simply RST. Exposing ports makes you legible to the layer that scans for this kind of target.

The quieter, more interesting traffic

Once you filter out the SSH brute force floor, and it is a floor of roughly 300 to 600 attempts per hour, the rest gets more varied.

Log4Shell probes still show up on HTTP. More than two years after the advisory, JNDI probes are a standing wave. Most point at self-hosted Burp collaborators or long-dead VPS callbacks. Somebody, somewhere, is still paying for a scanner that fires these shots and never checks whether anyone answered.

A handful of requests were clearly scripted against specific CVEs:

• GPON router authentication bypass (CVE-2018-10561 / 10562). Still hitting in 2026.
• Various Ivanti and Fortinet path traversals.
• Confluence OGNL injection strings.
• Generic WordPress xmlrpc.php pingback fishing.

The unusual one: a small cluster of requests that tried to negotiate TLS with an SNI matching a real banking domain. No credentials, no follow-up. Probably a scanner doing inventory for cert transparency lookups. Possibly something less innocent. I don’t have enough data to tell, and that’s the honest answer.

Operational reality

A honeypot is not a set-and-forget box. In the first week I burned an evening chasing false positives and another fixing log rotation before a partition filled. The real costs:

• Disk grows fast. Cowrie session logs plus Elasticsearch indices ate about 18 GB in 30 days. That’s cheap, but it isn’t free.
• Containers drift. Watchtower handles the weekly pull. I still review breaking changes in the T-Pot release notes before merging.
• Elasticsearch is memory-hungry and will swap itself into uselessness if you underprovision. 8 GB is the practical floor.
• Alerting is where this gets useful. A 500-per-hour SSH baseline is noise. A successful Cowrie shell that persists for more than 30 seconds, or any outbound hit blocked at the OPNsense rule, is signal. Those page me. Everything else goes to a dashboard I check when I feel like it.

The alerting config is where most of my ongoing time goes. Without it, the whole thing is a pretty dashboard.

What I’d change

A few things I’ll do on the next iteration:

Split the honeypot across two IPs. Run Cowrie on one, everything else on the other. The SSH noise crowds the indices and makes queries slower than they need to be.

Move the dashboards off the honey-VM entirely. Shipping to an external Loki instance is already half the work. The remaining Kibana stack on-box is there for convenience, not necessity.

Add a second outbound-blocking layer inside the VM itself. Defence in depth against a container escape I’m still not fully satisfied with.

Log rolling PCAPs on a 7-day window. Right now I only have what Suricata and the honeypots chose to log. Full packet captures would let me revisit sessions I under-investigated at the time.

Does this change what I do at work

Partially. It doesn’t change how I think about APT-level adversaries. Nothing I saw in 30 days would strain a reasonable environment.

What it changes is how I talk about the baseline. The background radiation of the internet is real, it’s measurable, and it doesn’t stop. Any machine with an unpatched edge service survives hours, not days. Any default credential on a public interface is already compromised. You just haven’t noticed yet.

That isn’t a marketing line. That’s 412,000 login attempts across 30 days on one residential IP running an obvious honeypot.

Closing

Segment first. Then break something on purpose, in a place where it can’t reach anything you care about. The logs that come back are more honest than any vendor report.

I’ve always enjoyed tinkering with operating systems and finding ways they improve day-to-day life. I’m not a cloud hater. Cloud services are useful and I still use them. I self-host because it’s fun.

With most SaaS tools, you’re limited by design choices you had no part in. My biggest self-hosted system is a Plex machine. I watch what I want, how I want, for roughly the cost of electricity. There’s also been a serious learning component: networking, security, general IT practice. That alone has made it worth running.

Topology

Starting at the internet edge and working inward:

Router / Firewall I settled on OPNsense. It met and exceeded what I needed. The box runs intrusion detection, Unbound DNS, and a handful of other security-focused services.

Switching Traffic hits a 24-port unmanaged gigabit switch with SFP ports. Nothing exotic, but most ports are in use.

Flat Network The network is currently flat, so traffic flows directly to access points, servers, Raspberry Pis, NVR systems, gaming consoles, and everything else.

The topology is simple. The interesting part is what the devices are doing, not how complex the diagram looks.

Core Infrastructure

Alecto

Hardware

• Ryzen 7 1700X
• 1 TB NVMe
• 4 TB HDD
• GTX 1050 Ti

Nothing exotic, but it handles everything I need with around 85% idle time.

Software Ubuntu LTS as the host OS, Docker for everything else: media acquisition, media consumption, networking, local services, metrics, and automation.

Docker makes backing up and restoring critical services significantly easier, which is the main reason I keep everything containerised.

Services

Media Acquisition

The pipeline follows a simple request, acquire, process, library chain.

• Overseerr
• Prowlarr
• Sonarr / Radarr
• qBittorrent
• Deluge
• Unpackerr
• cross-seed

Prowlarr manages indexers. Private trackers have far less fake or malicious content than public ones, which matters later in the chain.

Sonarr and Radarr handle TV and movies. Quality profiles are simple: HD and 4K. That has covered everything so far. Both monitor RSS feeds from configured indexers and push matched torrents to the downloader automatically.

I run two download clients. qBittorrent handles the entire arr stack. Deluge handles manual downloads and non-media content. Dynamic save paths split movies and TV cleanly for Plex.

Unpackerr handles automatic extraction for downloads that arrive as archives. cross-seed finds identical or near-identical torrents across trackers and advertises that I already have the data, which improves speeds and availability for others.

The only recurring issue is Sonarr or Radarr occasionally grabbing a fake title. Aggressive regex-based filters have mostly resolved it.

Media Consumption

• Plex
• Tautulli
• Overseerr
• Homepage

Plex is the primary player. Mature, stable, available on every device, and accessible for non-technical users. I’ve tested Jellyfin and like it, but haven’t switched.

Tautulli gives visibility into Plex usage: playback activity, per-user bandwidth, transcoding load. That data makes decisions around limits and capacity easier.

Overseerr lets users request titles themselves rather than messaging me. Requests still require approval, but that takes seconds instead of a back-and-forth conversation.

Homepage is a single customisable dashboard with a high-level view of everything running. It doesn’t replace Zabbix or Grafana for monitoring, but it’s useful for day-to-day glancing.

Networking and VPN Containment

Torrent clients are routed through Gluetun, a dedicated VPN container running WireGuard. The downloaders have never touched my LAN directly and never see my public IP.

Gluetun runs in strict kill-switch mode. If the VPN drops, traffic stops. There’s no fallback to my home connection. Given the provider’s SLA, this hasn’t been an issue in practice.

No inbound ports need to be open, which reduces exposure further. Speed degradation from the VPN hasn’t been noticeable.

Observability

Prometheus, Node Exporter, cAdvisor, and Grafana cover system-level metrics: CPU load, memory usage, container behaviour. Critical alerts go to Telegram. I’m refining thresholds so only actionable issues send a notification.

Automation

Watchtower handles container updates on a schedule at 03:00. If an update breaks something, rolling back means redeploying from the same configuration paths. Docker’s stateless container model makes that straightforward.

Portainer handles anything that needs a UI.

Network Edge

OPNsense

OPNsense sits between the internet and all internal systems. UPnP is disabled. No device exposes itself automatically. Only explicitly required services are permitted outbound or inbound.

All traffic is statefully inspected. DNS is forced through Unbound. Suricata monitors inbound and outbound traffic for known malicious patterns. Devices can’t quietly phone home, bypass DNS filtering, or accept unsolicited inbound connections without generating an alert.

Services get published deliberately, not accidentally exposed.

Boreas

A Raspberry Pi running Nginx Proxy Manager and WireGuard. This started as a workaround for a previous router that lacked VPN support. After moving to OPNsense, the separation made enough sense to keep.

Boreas is my remote access point back into the LAN. Nginx Proxy Manager exposes Overseerr to friends and family outside the local network. Both services sit behind Cloudflare, primarily to obscure my real IP.

The throughput on the Pi is better than you’d expect for the hardware.

Chronos

A Tor middle relay running as a small contribution to online privacy. No exit node: the ISP complaints and CAPTCHA overhead aren’t worth it. A middle relay provides value without the operational noise. It’s low-maintenance and largely invisible once configured.

Failures and Lessons

In the past year, two things actually broke:

• Disks filled up from log spam. Entirely my fault. Log rotation is properly configured now.
• Incorrect or fake titles downloaded. Better filters and denied extension lists resolved most of it.

Beyond that, issues have been minor misconfigurations and occasional reboots.

What I’d Do Differently

I’d spread services across more hosts if I could go back. Some hardening measures were probably over-engineered, but I don’t regret that trade-off. Deploying the arr stack earlier would have saved time.

What’s Next

Hardware: managed switch, better access points, a more capable GPU for transcoding.

Monitoring: a consolidated Zabbix dashboard with proper alerting.

Networking: VLANs.

Self-hosted AI models aren’t on the list. Cloud tools cover what I need without the overhead.

Closing

Running this lab has mostly taught me patience. Getting multiple devices, containers, and services working together takes iteration. It’s improved my understanding of networking and containerised systems more than any course I’ve taken.

I keep running it because it’s fun and I learn from it. That’s enough reason.