Posts

Bringing pfSense’s admin login into Authentik with MFA — via RADIUS, which turned out to be broken upstream, and then via LDAP, which wasn’t. This is as much about how you prove a bug isn’t yours as it is about the build. Stack: Authentik · pfSense · Docker · LDAP · RADIUS 1. Purpose With an identity provider already running and Grafana logging in through it, the obvious next question was: how far does this go? ...

Deploying Authentik as a self-hosted identity provider, and wiring Grafana into it with OIDC — so a service that has never heard of MFA suddenly requires it. Stack: Authentik · Caddy · Grafana · Docker · Debian 1. Purpose Every self-hosted service arrives with its own login. Ten services means ten accounts, ten passwords, and ten places to forget to enable MFA. Worse, some services have no authentication at all and just quietly assume nobody hostile is on your network. ...

Building a self-hosted password vault with a genuinely trusted TLS certificate and zero inbound ports open to the internet — and the four-layer debugging session that stood between me and a working container. Stack: Debian 13 · Docker · Caddy (custom build) · Vaultwarden · pfSense · WireGuard · DuckDNS 1. Purpose Self-hosted services are easy to do badly. It’s trivial to run a container, forward a port, click through a certificate warning, and call it done — and end up with something less secure than the cloud service you replaced. ...

The blog you’re reading just moved house. Same content, same build, the same Cloudflare Pages underneath — but the address on the door changed from billalrehmani.pages.dev to a domain that’s actually mine: billsblog.dev. Why bother — it already worked billalrehmani.pages.dev was fine. It served over HTTPS, it was fast, it was free. But pages.dev is Cloudflare’s namespace, not mine. For a portfolio I link from LinkedIn and want people to remember, “billalrehmani-dot-pages-dot-dev” is a mouthful and a borrowed address. Owning the domain means owning the identity — and, as it turned out, a bit more control over the security posture too. ...

The blog you’re reading changed builders. The git push that publishes it is identical; what runs on the other end isn’t. It used to be a GitHub Actions job that built the site and served it from yourlocalunemployed.github.io. Now Cloudflare Pages builds from the same repo and serves it at billalrehmani.pages.dev. I didn’t move for speed or for a nicer dashboard. I moved because GitHub Pages won’t let me set HTTP response headers, and for a blog that’s meant to be a security portfolio, that was the one limit I couldn’t design around. ...

A flat network trusts every device on it equally. A smart plug, a guest’s phone, and the machine holding my important data all share one space — so if any one of them is compromised, the attacker can reach the rest. Network segmentation breaks that flat space into separate zones and controls what may cross between them, shrinking the blast radius of any single compromise. I wanted to build that properly — VLANs and a firewall — on VMware Workstation with pfSense CE, and design three zones at deliberately different trust levels: ...

My lab is deliberately isolated — an automation VM (CLAUDDEB) sits behind a virtual pfSense firewall on a segment (10.10.0.0/24) that my home network can’t reach. That isolation is great until you’re out of the house and want to check your Grafana dashboards, which only listen inside that segment. I already use Tailscale for casual remote access, and I’ll be honest up front: for pure convenience, Tailscale wins — it punches through NAT automatically with zero firewall work. But this project wasn’t about convenience. It was about building the thing Tailscale is made of. Tailscale is WireGuard under the hood; hand-rolling raw WireGuard on pfSense teaches you how VPNs actually work — keys, peers, routing, firewall rules, NAT — at a level the managed tool deliberately hides. So I built it from scratch, kept Tailscale as my daily driver, and got a genuinely brutal debugging lesson in the process. ...