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