Show HN: Whole-home VPN router with hardware kill switch (OpenWrt and WireGuard)

[yoloshii]

With 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: - Firewall 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)

[neilv]

> 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.

[yoloshii]

You're probably right lol. It does have that connotation. I'll change it.

[neilv]

Was this AI-generated?

[cadamsdotcom]

I’m curious why you’re asking this. Are you concerned the author didn’t review what was generated?

If (I’m speculating here) that’s the real question you wanted to ask, it’s perfectly okay to ask that.

[neilv]

I asked that because I suspected it was AI-generated, but didn't want to assume.

[cadamsdotcom]

No worries - still curious why you would care if it’s AI generated?

Eg. Are you concerned about licensing?

[yoloshii]

Some, yes.

[dontdoxxme]

> 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.

[yoloshii]

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. And netns is for single-host isolation. This is a router forwarding LAN→WAN. Different problem.

[dontdoxxme]

> And netns is for single-host isolation. This is a router forwarding LAN→WAN. Different problem

Not at all. Put the LAN interface in a network namespace that is different to the host (ip link set ... netns ...).

This gives you your "kill switch" without even needing firewall rules, it happens on a lower level.

[yoloshii]

In this setup the "kill switch" works in tandem with the VPN server failover logic. Maybe a netns would be good for redundancy.

[beAbU]

Honest no-snark question, coming from someone who does not know a lot about VPNs other than the wireguard app I have for work.

What's the difference between this, and just configuring the VPN settings that's available on my router that came with my ISP?

[cbsks]

The downside is that some services, such as video streaming, block access from VPNs.

[yoloshii]

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.

[Retr0id]

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.

[yoloshii]

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.

[mzajc]

> 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.

[yoloshii]

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.

[mzajc]

But this isn't a simple explanation, it's just... wrong? Could you share where else it's referred to as such.

[yoloshii]

I mean if you want to be anal about it, its just semantics, right? You know, how something is one way relative to something else, but relative to the other thing its not. Certainly not something to get bothered about.

[pa7ch]

I've not seen it called this before. I'd say something like 'fail-safe' instead.

[orev]

No, it does not. Please stop responding with AI slop. A hardware kill switch always means a hardware (i.e. physical) mechanism. ALWAYS.

You might have something interesting here, but arguing this point is burying anything else of value you might have. Just take the feedback and remove it.

[yoloshii]

Its done, but too late to edit the title of this submission. One of the unfortunate things about churning out AI slop is that the AI doesn't always catch all of its turds in one go.

[orev]

The human in the loop should be acting as an editor of the slop before it gets posted.

[yoloshii]

Some humans also put out slop.

[Retr0id]

You're absolutely right!

[globalnode]

im kinda off vpns since i learnt that id likeley become an ai crawler or a proxy for someones paid ddos