Show HN: Whole-home VPN router with hardware kill switch (OpenWrt and WireGuard)
github.comWith internet censorship and surveillance on the rise, ie; UK Online Safety Bill (July 2025) and Australia's social media legislation (Dec 2025) introducing mandatory age verification (read: initial step on the pathway to social credit), I wanted a privacy-first solution that protects browsing history from ISPs and third-party verification services, but not one that requires you to be an Einstein to deploy.
This stack turns a Raspberry Pi (or any OpenWrt-compatible device) into a network-wide VPN gateway.
Key features: - Hardware kill switch: VPN down = no internet (not a software rule that can leak) - AmneziaWG obfuscation for DPI-resistant connections - Optional AdGuard Home for DNS filtering - Works for all devices including smart TVs and IoT that can't run VPN apps
Not a techie? The README is optimized for AI-assisted deployment. Feed it to your LLM of choice (Claude, GPT, etc.) and it can walk you through the entire setup for your specific hardware.
Mullvad-focused but works with any WireGuard provider. MIT license.
Docker deploy in testing (coming soon)
> Hardware kill switch - Firewall-level failsafe, not software
I think that firewalling/filtering and routing are software (though they can be accelerated in hardware).
"Hardware kill switch" is a useful pre-existing term, which I've only seen used to mean a user-controlled mechanical switch that physically opens or closes one or more electrical circuit conductor paths necessary for whatever is to be "killed" (electrically disconnected).
For example, let's say your network connector had several pins; a kill switch might mechanically disconnect those pins from wires or PCB traces, in a very simple and verifiable way, which obviously nothing in software/firmware/backdoors/etc. could circumvent. (Well, unless the software could control a robot arm, to go flip the mechanical switch, or solder in a bypass.)
Calling something else "hardware kill switch" seems incorrect. I don't say this to be pedantic, but because it's an important security feature, which this system claims to have, but does not.
You're probably right lol. It does have that connotation. I'll change it.
Was this AI-generated?
Some, yes.
> Not a techie? The README is optimized for AI-assisted deployment. Feed it to your LLM of choice (Claude, GPT, etc.) and it can walk you through the entire setup for your specific hardware.
The whole thing is AI slop. I thought there might be something interesting here but it's just a bunch of disconnected fragments of OpenWRT config and some other bits without any overall thought.
It doesn't even use network namespaces. You can probably do better by giving your LLM https://www.wireguard.io/netns/ as input.
It prompts the user's agent to audit their network devices and topology first, and research online if it gets stuck. the configs need to be agnostic and contain placeholders. The whole idea is that the agent helps the user vibe code this, which is very doable, and probably the norm when there are so many people looking for solutions like this given the current climate.
The downside is that some services, such as video streaming, block access from VPNs.
That's where VPN obfuscation is the play, imo. A lot of people nowadays are leaving streaming platforms or watch YT on smart TVs, so it does have a place. You can always exclude a device from the VPN coverage too.
Obfuscation only protects you from your own ISP messing with VPN connections. Streaming services (etc.) can't see what protocol you're using between yourself and the VPN in any case, they just see the VPN's exit IP address. Which is likely on their list of known VPN IPs.
If you start countering geolocation blocking with vps rental and VLESS vray etc then its still good to obfuscate at the endpoint. Passing VPN traffic off as something else is good policy wherever your tunnel goes.
> The kill switch is implemented in the firewall and routing table, not in software.
As far as I know, both of these are in the kernel (not hardware). It's odd that so much of the README is dedicated to describing this relatively simple firewall rule, but the whole thing smells like generated slop.
You're right that iptables rules execute in kernel space, not dedicated hardware. "Hardware kill switch" in VPN contexts typically means the protection is implemented at the network appliance level (router) rather than a software client on each device. The distinction matters because a) client-side kill switch: App crashes → traffic leaks until you notice, and b) router-level kill switch :Default DROP policy persists regardless of client state. Also, the project is for non-techies and vibe coders, so simple explanations help. For their agents, there's the juice in other docs.
You're absolutely right!
im kinda off vpns since i learnt that id likeley become an ai crawler or a proxy for someones paid ddos