Defguard is a *Secure by Design* solution, which means security is important (if not more) then functionality.
Lower latency or peer-to-peer communication does not automatically mean better security often it means a larger attack surface.
Defguard is also *the only solution that enforces MFA on every connection*, aligning with true Zero Trust principles never trust a user or device by default.
Why Peer-to-Peer Is Not Safer?
Peer-to-peer and mesh solutions can be faster because traffic flows directly between peers, but they almost always expose all components publicly and make it easier to hijack the network or inject unauthorized peers.
So what does Defguard’s Secure-by-Design Architecture mean?
1. Minimal gateway exposure
The Defguard gateway exposes only a WireGuard port. Compromising it would require a Linux kernel or WireGuard zero-day at that point, no solution is safe.
2. Isolated, stateless proxy
The only Internet-facing "application" component is a stateless proxy, deployed in a separate network segment. It has no access to the gateway, core, or internal resources.
3. Protected control plane
The core (control plane) runs strictly inside the intranet (local network that should not be exposed anywhere). No user data are exposed to the Internet or DMZ/other network segments. Also the MFA validation process is done in secure network segments (for example when doing MFA with Desktop + Mobile client biometry/faceID combined).
Why This Is Different from Mesh Solutions?
Most mesh VPN solutions expose their control and peer-discovery components publicly by design. This significantly increases the risk of compromise and peer injection.
So would you say then that it’s perfectly safe to send plaintext traffic between services over Defguard instead of also using mTLS?
I still wish that Defguard had an option where peers only used the public gateway to retrieve their p2p ACLs from the control plane but otherwise traffic flowed directly.
From what I can tell you, good security is hard - we have prepared the product exactly as you describe on various levels (vpn, identity, SSO, Yubikey provisioning, etc) and prepared the architecture to be secure (multiple segments support: intranet, DMZ, proxy for exposing only public endpoints and functionalities publicly)…
What I observe in a year of the project being public and analysing heavily the landscape, similar projects, Reddit of what users are seeking and what problems they have is that: a lot of people and companies value comfort more then security (even if they will not admit it publicly), because security is hard. That also means there is w niche and need, but… it’s really hard to build a secure, easy to use and deploy security system…
Hope you don’t give up and peruse!, as it’s worth fighting about security and privacy
Defguard looks great, it's got a similar architecture (local first, with a vpn) and your feature list looks like my todo list!
I could see recommending this product to others!
You have a few features that surprised me, like support for "authentication with crypto software and hardware wallets". This seems like the sort of thing a business would never need. Did you have users agitate for this feature? Or is it a direction you're trying to steer clients?
Overall, nicely done, I wish I'd known about this when I started!
Those features you’ve mentioned were done for some customers/projects that deployed defguard - but web3 stack (especially wallet libraries) are so… immature and problematic that we will be most probably removing those features.
Can you share your roadmap? Ideas? Seems we share the same mindset and vision, would be great to exchange knowledge, ideas…
This looks very nice. Comment: there's a whole industry that - whether or not they utterly despise the idea - is required to use FIPS-certified encryption. If you were somehow able to make that a component, you might be able to expand your market significantly.
Hey cool project! I starred this a while ago. Nice to see you here.
Just to clarify though, WireHub is just a config generator. It doesn't run your networks. It doesn't ask you to install anything other than stock WireGuard apps. It doesn't do "Web3 wallet validation" or anything remotely cool.
TLDR: WireHub is a tool that helps you generate WireGuard configurations and easily share those with your end-users - instead of emailing configs around, you can just share a link to WireHub.
--
So if you want a secure private network for your devices and you choose WireGuard as the protocol for it, there a few ways to get there depending on your needs.
As is often the case, it's a question of convenience Vs security & trust.
In general, I think there are three categories of tools:
1) CLIs - Command line tools where you run a couple of commands and you get a folder of wireguard config files.
2) Self-hosted Admin UIs - `git clone ... && docker-compose up` (or something to that effect) in a server of yours and you get an admin UI to control a WireGuard interface and its peers.
3) All-in-One - tools that control the whole stack, from using/recreating WireGuard in userspace with custom agents to SSO, RBAC, etc etc.
With CLIs, its easy to generate configurations but then there's a lot of fiddling to main them. Multiple networks? New peers? Rotating keys? Securing Keys? Ugh.
With self-hosted admin UIs, like wg-easy, subspace, et al, you can get to 90% quite easily especially if you're up to to some open source hacking yourself, and the GUI aspect makes it kind of easier to maintain your network.
Yet, the issue of securing the PrivateKeys remains - they are all kept on the server running the admin UI and are then distributed to peers.
All-in-One solutions, like tailscale, netbird, netmaker, et al, solve the PrivateKey problem by providing agents - their own software you have to install on each of your devices. Their software securely handles PrivateKeys on each client so they are not stored in a single place and never leave the device they were created on. You get to 100% pretty quickly, but you're somehow left wondering about the layers and layers of pure magic (in a good way!) going on behind the scenes.
WireHub tries to strike a balance between convenience and security in all three categories by:
- Making PrivateKeys optional. For maximum security, just don't share them with WireHub. For convenience however, WireHub can encrypt your PrivateKeys in browser (using WebCrypto) with a password of your choice (that is never stored, anywhere). WireHub can also generate the keys in browser, using Jason's javascript implementation.
- Not running any servers. For maximum security, bring your own cloud. For convenience, you can use `curl` to download the relevant WireGuard config on each server.
- Relying on stock WireGuard apps and not providing clients or other software to install. Jason is just better at writing secure software :)
So these choices place a hard limit on what WireHub can and will try to do.
We already have a PoC/code working of WireGuard peer discovery/connections without a central VPN gateway.
Soon we will publish that module, and you will be able to deploy *your own private tailscale*.
Hey Hacker News! I'm Robert - the founder of Defguard. If you would like to get some background, motivation - please read the Defguard announcement blog post:
Hi Robert! What you are doing with Defguard (and teonite!) looks great! (btw -- fucking cool site^0, who did your team photo art? awesome!)
DefGuard looks like a great way for average folks and small business to get quickly and easily secure in their infrastructure! Sounds like you value creating something really quality and putting it out there, making it free and open (even Open Source!) along the way, and also like you really want to provide as much value as you can for folks in the security space.
It's probably way too different an aspect of security to compare, and the different licenses are likely a big problem, but the values you express with Defguard resonate with what we're doing with BrowserBox open-source^0, and I bet it's the dumbest question you will see on this thread and I'm sure it will seem like a tacky promo so I'm sorry, but would it be a terrible idea to integrate BrowserBox open-source into your swiss-army knife?
> Hi Robert! What you are doing with Defguard (and teonite!) looks great!
Thank you for your kind words!
> fucking cool site, who did your team photo art? Awesome!
Thank you! ;-) The credit goes to our creative director (Krzysztof - on our About page) - and the team who build the website.
One thing that may interest you - our "team art" is done with (soon to be released - and most probably open-sourced) geonodes^0 platform.
> (...) would it be a terrible idea to integrate BrowserBox open-source into your swiss-army knife?
This is our first open-source product - and just from brief glance on BrowserBox GitHub - you clearly have more experience in that area - so I’m open to any discussions.
Would be great to connect and have a brainstorming session, to understand your project better and how can we find value for the users to secure them with ease of use (which is our main focus). If you are open to that - my contact data are in my HN profile, and hope to chat soon!
We just implemented these ones. We plan to opensource the app soon (the core code is already on our github but not the complete webapp), the we will accept pull requests.
I don’t think that a constellation - lines and dots is under any copyright.
It’s like saying that python logo has a python so it validates all logos that has snakes in logos..
Remember, no actual logos were used, changed, modified...
Defguard is a *Secure by Design* solution, which means security is important (if not more) then functionality. Lower latency or peer-to-peer communication does not automatically mean better security often it means a larger attack surface.
Defguard is also *the only solution that enforces MFA on every connection*, aligning with true Zero Trust principles never trust a user or device by default.
Why Peer-to-Peer Is Not Safer?
Peer-to-peer and mesh solutions can be faster because traffic flows directly between peers, but they almost always expose all components publicly and make it easier to hijack the network or inject unauthorized peers.
So what does Defguard’s Secure-by-Design Architecture mean?
1. Minimal gateway exposure
The Defguard gateway exposes only a WireGuard port. Compromising it would require a Linux kernel or WireGuard zero-day at that point, no solution is safe.
2. Isolated, stateless proxy
The only Internet-facing "application" component is a stateless proxy, deployed in a separate network segment. It has no access to the gateway, core, or internal resources.
3. Protected control plane
The core (control plane) runs strictly inside the intranet (local network that should not be exposed anywhere). No user data are exposed to the Internet or DMZ/other network segments. Also the MFA validation process is done in secure network segments (for example when doing MFA with Desktop + Mobile client biometry/faceID combined).
Why This Is Different from Mesh Solutions?
Most mesh VPN solutions expose their control and peer-discovery components publicly by design. This significantly increases the risk of compromise and peer injection.
So that's about it.