Show HN: Whole-home VPN router with hardware kill switch (OpenWrt and WireGuard)(github.com)
github.com
Show HN: Whole-home VPN router with hardware kill switch (OpenWrt and WireGuard)
https://github.com/yoloshii/privacy-first-network
34 comments
> 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.
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?
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.
If (I’m speculating here) that’s the real question you wanted to ask, it’s perfectly okay to ask that.
I asked that because I suspected it was AI-generated, but didn't want to assume.
No worries - still curious why you would care if it’s AI generated?
Eg. Are you concerned about licensing?
Eg. Are you concerned about licensing?
Not being generated implies some intent behind what's and how's being written that you can read into. Being generated means it's just driven by random chance and the poster may or may not have cared to redact it, making attempts at interpretation futile.
This applies to code just as much as it does to prose.
This applies to code just as much as it does to prose.
Where it comes to AI generated output, that mostly depends on the input. If you prompt with specifics of what you want and go into detail, you are much more in control of the output.
But wouldn’t you just expect people to review the result?
I'd like to give them the benefit of the doubt, but prior experience tells me not to.
Here's a hint. Look at the number of commits on the repo.
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.
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. And netns is for single-host isolation. This is a router forwarding LAN→WAN. Different problem.
> 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.
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.
In this setup the "kill switch" works in tandem with the VPN server failover logic. Maybe a netns would be good for redundancy.
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?
What's the difference between this, and just configuring the VPN settings that's available on my router that came with my ISP?
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.
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.
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.
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.
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.
I've not seen it called this before. I'd say something like 'fail-safe' instead.
But this isn't a simple explanation, it's just... wrong? Could you share where else it's referred to as such.
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.
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
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)