I Audited My Own Homelab — Here’s What I Found

I run what I describe as an enterprise-grade home network. Proxmox cluster, full UniFi stack — UDM Pro, managed switches, access points — VLAN segmentation, TrueNAS for storage, a mix of physical and virtual machines for various services. I built it deliberately, knowing that understanding how things break is how you understand how to secure them.

Earlier this year I decided to put it through the same structured audit process I use with clients. External and internal testing, configuration review, access control assessment. The results were instructive. Not catastrophic — I know this network well. But there were things I had allowed to accumulate that I would flag in a client report.

This article walks through what I found, what the risk actually was, and what it means for a business network that does not have a dedicated network engineer behind it.

The setup

The network runs across multiple VLANs — IoT devices, trusted devices, management, storage, and a DMZ for publicly accessible services. The Proxmox cluster runs a mix of Debian VMs and LXC containers. TrueNAS handles NAS duties with ZFS storage. UniFi manages all switching and wireless.

On paper this is a reasonably well-architected setup. The VLANs exist, the firewall rules exist, the management interfaces are supposed to be isolated. The question I was testing was whether the theory matched the reality.

What the external scan found

Starting from the outside — what would an attacker see without any inside knowledge?

My external surface was intentionally small. I run a few services accessible from the internet and nothing else should be visible. What the scan found:

• Services I expected to be exposed were exposed correctly
• One service was running an older version of its software — not critically vulnerable, but outside my normal patch window and worth noting
• TLS configuration on one service was acceptable but not optimal — specifically, TLS 1.0 and 1.1 were still negotiable, which a modern hardening standard would consider a finding
• No unexpected open ports — the firewall was doing its job externally

What the internal assessment found

This is where things got more interesting. Once inside the network (starting from the position of a compromised device on the trusted VLAN), what was reachable?

VLAN segmentation — mostly working, with one gap

The VLANs were working as intended in most cases. The IoT devices could not reach management interfaces. The guest network was genuinely isolated. But there was one inter-VLAN firewall rule I had added during a debugging session six months previously that had never been removed. It was a permissive rule that allowed broader access than intended from one VLAN segment.

This is a pattern I see in client networks constantly. A rule gets added to solve an immediate problem. It works, the problem is solved, and the rule stays. Accumulate enough of these and your segmentation is much weaker than your diagram suggests.

Service accounts and default credentials

One service I rarely use still had its default administrative username set. The password was unique and strong — but the username was default. This is a minor issue in isolation but represents exactly the kind of thing that gets exploited when combined with a weak password or a brute force attempt.

Certificate management

I run internal certificate authorities for internal services. Two internal certificates had expired and the services had fallen back to self-signed certificates. These were internal services not directly exposed to risk, but expired certificates generating browser warnings erodes the habit of trusting certificate warnings — which is exactly the kind of security hygiene erosion that matters over time.

What this means for a business network

My homelab is not a business network, but the failure patterns are identical to what I find when I audit small business networks in Yorkshire. Three things in particular:

Rules accumulate. Every firewall, router, and switch in a business that has been managed for more than two years has rules in it that nobody can explain. Some are load-bearing. Some are redundant. Some are actively creating risk. You need to review them against current requirements — not assume they are still correct because they were correct when added.

Software ages. The patch management problem is not that businesses refuse to patch. It is that patching requires testing, testing takes time, and over time the gap between current and deployed widens. An external scan shows you exactly how wide that gap is and whether any of the outstanding versions have known exploits.

Defaults persist. Default usernames, default SNMP community strings, default VLAN configurations on managed switches. Nobody removes them maliciously — they just never get removed because removing them requires someone to notice they are there and decide it is worth the time. An audit creates a specific moment where these get reviewed.

The honest summary

I found three things on a network I built deliberately, understand thoroughly, and maintain actively. None of them were critical — but they were all findings. On a business network maintained by an IT provider who also manages 50 other clients, and has not been independently assessed, the equivalent list will be longer and some of the findings will be more significant.

The point of an independent audit is not to find catastrophic failures. Most of the time, there are not any. The point is to systematically identify the accumulated drift between how a network should be configured and how it actually is — and produce a prioritised list of what to fix.

Three findings on my own network. I fixed all three in under two hours total. That is what a good audit looks like.

Charles Cassam is the founder of Wolds Cyber Ltd, based in Pocklington, East Yorkshire. He provides independent network security audits to businesses in York and Yorkshire. More about Charles →