[HN Gopher] Show HN: WireHub - easily create and share WireGuard...
       ___________________________________________________________________
        
       Show HN: WireHub - easily create and share WireGuard networks
        
       WireHub is a side project I've been working on, on and off, for
       close to a year now. It's made with django and minimal javascript.
       It's a hosted WireGuard config generator/manager, that you can
       invite others to join your networks and manage their own
       configs/devices.  It's still very much a beta, maybe an mvp, but I
       just wanted to get some early from the community.  Thanks!
        
       Author : rudasn
       Score  : 283 points
       Date   : 2023-11-05 20:54 UTC (1 days ago)
        
 (HTM) web link (www.wirehub.org)
 (TXT) w3m dump (www.wirehub.org)
        
       | mushufasa wrote:
       | OOh -- this sounds actually potentially awesome for business use-
       | cases. Tailscale is the commercial tool to help setup and manage
       | wireguard networks, and it had a big security incident earlier
       | this year (though they were prompt to rectify).
       | 
       | I don't use tailscale but I almost did. One of the things that
       | caught me was not wanting to give a third party any control.
       | (Also, at the time I didn't absolutely have a burning need given
       | the number of servers and people involved). Tailscale's model is
       | to charge businesses; I'm not sure if you are making this FOSS
       | but something FOSS to me would be preferable.
       | 
       | How does the privacy work on your site? I haven't the time to log
       | in and play around right now. My main concerns would be if I'm
       | posting my configs to a third party, that third party now has a
       | vector to 'root' my networks. And if this is a site meant for
       | sharing, there's the other concern that I or the site
       | accidentally temporarily makes permissions public giving
       | strangers that access. I'm sure you've already contemplated this
       | in the design; I'd love to hear your approach on this forum.
        
         | candiddevmike wrote:
         | Have you considered using Headscale?
        
           | mushufasa wrote:
           | Oh -- yes I did actually. Forgot about that till just now.
        
           | linsomniac wrote:
           | Tailscale is great, but for anything more than toy uses,
           | particularly business uses, where it's a critical part of
           | your infra, you should consider paying Tailscale or using
           | Nebula. My biggest reasons for saying this are: Headscale
           | config errors (including ACL issues) will take down the whole
           | Tailnet until you can get it corrected, setting up extra
           | "relay" nodes is fairly likely and somewhat "hard"
           | (especially without a dedicated IP), and headscale can take
           | quite a few resources. Data point: I recently set up a ~200
           | node Tailnet with headscale and in retrospect wish I had gone
           | with Nebula. Tailscale's "magic" can be nice, but it can also
           | lead to network weirdness. For example, I can't seem to use
           | the tailnet to route traffic between sites without turning on
           | "accept-routes", but turning that on causes traffic for local
           | ethernet segments on those nodes to be routed over the
           | Tailnet.
           | 
           | Reasons I went with Headscale/Tailscale over Nebula: We could
           | enforce periodic re-logins on user workstations, Tailscale
           | was good at routing around networking problems (Nebula has
           | since added similar functionality), Tailscale's self-service
           | is really nice (A user can login from any of their devices
           | using OIDC, Nebula you have to generate a cert).
           | 
           | Tailscale and Headscale are both fantastic, just beware of
           | the limitations.
        
             | cube2222 wrote:
             | > and in retrospect wish I had gone with Nebula
             | 
             | Could you expand why (happy Tailscale user here, asking
             | mostly out of curiosity)?
        
               | linsomniac wrote:
               | Largely went into it above...
               | 
               | Mostly it is the "adding an ACL can take down my tailnet"
               | issue. I had hoped to use Tailscale as an overlay
               | network, starting to route our internal traffic over it
               | for some things, but I've lost my tailnet so many times
               | because of issues with headscale ACLs taking it down.
               | This is largely a headscale issue.
               | 
               | Largely my issues are running ~200 nodes via headscale.
               | Don't get me wrong, headscale is fantastic software. But
               | it's not up for having our production networking rely on
               | it. I tried and tried to get funding to by Tailscale, but
               | it just wasn't in the cards with the economy as it is
               | right now.
        
         | helloooooooo wrote:
         | Which security issue? https://tailscale.com/security-bulletins/
         | 
         | None of these appear particularly severe?
        
           | mushufasa wrote:
           | https://emily.id.au/tailscale
        
           | linsomniac wrote:
           | https://tailscale.com/security-bulletins/#ts-2022-004
           | 
           | It was a pretty severe issue, but tailscale did respond
           | quickly to it.
        
         | rudasn wrote:
         | Thanks for looking into it!
         | 
         | Yes, I thought/think about security a lot. First, you don't
         | have to share/upload your private keys to WireHub for it to
         | work - the generated configs will only have the public key
         | (which we do store, it's public anyway).
         | 
         | Second, if you do provide provide private keys, you must first
         | encrypt them in browser with a password. The password is never
         | stored, just used for encryption.
         | 
         | Third, because of 2, to see a full config with private keys and
         | everything you need to provide said password.
         | 
         | If you scroll at the bottom of the page you can see the widget
         | in action.
         | 
         | I don't want to worry about loosing important data, so I try to
         | avoid collecting it in the first place.
        
           | jve wrote:
           | > Other than the in-browser PrivateKey encryption/decryption
           | mechanism, all functionality of WireHub is accessible without
           | JavaScript.
           | 
           | But that is done by browser, right? So one still must
           | consider trust to wirehub.org to be sure that it is not
           | sending the secret somewhere? But then again, same trust must
           | be considered by hosted solution - trust for the running
           | website code.
        
             | rudasn wrote:
             | Trust, or no trust, since it's all in the browser you can
             | check for yourself what gets posted to WireHub when you
             | submit the form containing your private key :)
             | 
             | Quick edit: you also don't have to provide your private
             | keys, just the public ones.
             | 
             | Another edit: actually it's two forms. One that has the
             | public key and password hint that gets posted to WireHub,
             | and one that has the private key, your password and the
             | password hint that's only handled on the client with
             | javascript and never gets submitted. So I do try not to get
             | to your secrets. I even have the form attribute of the
             | private key input set to a non existent form, just in case
             | it does get submitted, that piece of info will stay in the
             | browser.
        
         | FL410 wrote:
         | Check out Nebula/Defined.net
        
           | PlutoIsAPlanet wrote:
           | Been running a Nomad/Consul cluster on Nebula for nearly a
           | year now and have next to zero issues.
           | 
           | Only issue I ever had was caused by the Lighthouse being
           | behind 1:1 NAT, due to Scaleway.
        
         | rodlette wrote:
         | > Tailscale is the commercial tool to help setup and manage
         | wireguard networks, and it had a big security incident earlier
         | this year (though they were prompt to rectify).
         | 
         | > I don't use tailscale but I almost did. One of the things
         | that caught me was not wanting to give a third party any
         | control.
         | 
         | Yes, https://tailscale.com/security-bulletins/#ts-2022-004 was
         | scary. Their response was great, but I'm reminded of Tim Cook's
         | response to a question over what he'd do if it was in
         | Zuckerberg's position (re a FB leak): "I wouldn't be in that
         | situation".
         | 
         | Tailscale is a technical marvel, but it does a bit too much for
         | my liking, for something that has the access it does... even
         | more if you enable its SSH key support. I use plain Wireguard,
         | but would like LAN discovery and STUN.
         | 
         | https://www.wirehub.org/ looks nice, as does
         | https://git.deuxfleurs.fr/Deuxfleurs/wgautomesh which does LAN
         | discovery too (as Tailscale does).
        
         | braginini wrote:
         | Have you seen NetBird? Can be fully self-hosted
         | https://github.com/netbirdio/netbird#quickstart-with-self-ho...
        
       | xrd wrote:
       | This looks really interesting. But that might be because I'm
       | unsure of something: is this somehow a browser based proxy? Or
       | just a way to securely generate wireguard configurations? I'm
       | unclear but I'm always interested in wireguard or tailscale
       | tools. I'm using headscale with a lot of success.
        
         | rudasn wrote:
         | Just a config generator. I don't run any servers.
         | 
         | I'm trying to strike a balance between full fledged solutions
         | like tailscale, cloudflare tunnels, et al, and cli or gui based
         | self hosted solutions like wg-easy and subspace.
         | 
         | So you get to host your nodes, exit nodes, devices whatever and
         | fully control what goes passes through but also a really easy
         | way to manage which device gets what config, esp when dealing
         | with end-users.
        
       | dangoodmanUT wrote:
       | I'd add a way to connect networks together so you can have
       | devices see each other on the respective networks!
        
         | rudasn wrote:
         | Ah good one!
         | 
         | I already support having a single WireGuard interface belong in
         | multiple networks. So you can enable just a single config on
         | your phone and be able to access devices in multiple, unrelated
         | networks.
        
           | rickydroll wrote:
           | I want the opposite :-) I don't want any remote network to be
           | able to see into my network _or_ down to any other. I
           | frequently run 2-3 vpns at the same time and I really need to
           | isolate them.
        
             | rudasn wrote:
             | Well, that's actually the default for WireHub. Routing
             | between peers (ie their generated AllowedIPs configs) by
             | default only refers to the IPs of the two peers and you can
             | use an Interface per Device per Network, so that you'd need
             | to explicitly enable the relevant WireGuard interface for
             | each network.
             | 
             | But, re-reading your comment, as long as your networks are
             | on different CIDRs you could use a single WireHub interface
             | to refer to more than one device/networks. As I said,
             | traffic by default is routed to the specified peer's
             | Address not the whole network (eg, 192.168.x.y/24) nor the
             | internet (0.0.0.0/24).
        
       | cedws wrote:
       | This doesn't have any relation to this right?
       | https://github.com/gawen/WireHub
        
         | rudasn wrote:
         | No, just a name conflict.
        
       | SMART_failure wrote:
       | How would you then spin this up in the cloud?
        
         | rudasn wrote:
         | It's just a config generator but you can share the configs. You
         | bring your own cloud.
         | 
         | Check the generated examples once you log in, but for a hub and
         | spoke network let's say, the idea is this:
         | 
         | - Create your network.
         | 
         | - Add a device. Name it hub. Label it hub. Do not assign the
         | device to your self, but create a guest invite. Name the invite
         | hub.
         | 
         | - Add more devices, one for each server or enduser device.
         | Label them as you wish. For servers, create guest invites. For
         | enduser, create guests or members. Guests don't need to create
         | an account to get their configs.
         | 
         | - In connections, add two rules. all to hub, and hub to all.
         | 
         | Now the network is defined, but there are no associated
         | private/public keys with these devices. You need to create
         | Interfaces for that.
         | 
         | For your servers, for which you created guest members, create
         | an interface for each device. Either generate the keys in
         | browser, or just provide the public key if you already have
         | one.
         | 
         | For the hub interface, you need an endpoint url, that's where
         | all other devices will connect to. No endpoint is needed for
         | the other interfaces.
         | 
         | For the devices belonging to end users, just copy and share
         | their invite url. They will be able to generate their own
         | Interfaces and keys.
         | 
         | During all these changes , all configs are kept in sync.
         | 
         | Going back to your server devices, you can just curl their
         | respective interface url (including the invite code) and you'll
         | get your config. Add a cron and a fallback in case of a botched
         | change, and you're set. (in theory at least)
        
           | lorenzo95 wrote:
           | Thank you for the quick how-to. Makes for a great intro to
           | see how you thought about the workflow. I was able to follow
           | it no problem and now understand the Connections section. Of
           | course you have the pre-loaded examples in there as well.
           | Pretty neat actually! What I also really like is the export
           | function for a quick backup. Do you have an example of the
           | cronjob?
        
             | rudasn wrote:
             | Awesome! Glad you got it:)
             | 
             | So for the cronjob part, that only applies to devices
             | assigned to guests, as they can be used without creating an
             | account on wirehub.
             | 
             | - Create your invite, Guest Role.
             | 
             | - Assign the Device to that Guest.
             | 
             | - Add an Interface on that Device.
             | 
             | - Preview the network as that Guest (click the eye icon
             | next to their username). Open the URL in a new private
             | window, because you need to:
             | 
             | - Accept the Invite.
             | 
             | - As that Guest, you'll just see the device(s) assigned to
             | you. Click on the config button for any device and right
             | click, copy the Download URL. That should contain the
             | invite_code as well, which is basically the authorization
             | token for that Guest.
             | 
             | Now, on your device, just curl the URL, like so:
             | 
             | ``` curl 'https://wirehub.org/wirehub/n/hub-
             | network/device/1/download?...' ```
        
             | rudasn wrote:
             | I can't edit my previous comment but here's a better curl
             | example:
             | 
             | `curl -s -o ./wg0.conf 'https://wirehub.org/wirehub/n/hub-
             | network/device/1/download?...'`
             | 
             | This pulls the config and stores it in `wg0.conf`. The
             | [Interface] section though is invalid (as there's no
             | private key). So you'd have to either generate the keys on
             | the server or somehow get them there. From then on it's
             | just standard wg-quick and wg to create the interface and
             | load your keys.
             | 
             | After the cron job, you'd want to do something like `wg
             | syncconf wg0 <(wg-quick strip wg0)` so that wireguard picks
             | up any changes from the pulled config.
        
           | INTPenis wrote:
           | I'm going to be honest, I didn't understand the use case of
           | the site until I read this comment.
           | 
           | And I've worked in IT for 25 years, I make and manage my own
           | wireguard setups.
           | 
           | I wish new products and sites were more to the point in how
           | they're supposed to be used. I generally don't check the docs
           | unless I already have an inkling that I want to make use of
           | it.
           | 
           | So in other words this is a service for the selfhoster that
           | provides wireguard to their family and friends. This way they
           | don't have to manually send them a config or a qr code,
           | instead just send them to this site.
        
             | rudasn wrote:
             | > And I've worked in IT for 25 years, I make and manage my
             | own wireguard setups.
             | 
             | You are the target audience, I guess, so your feedback is
             | doubly appreciated. Thanks! :)
             | 
             | You described it just right. That's it. Right now, on the
             | "hero" section of the landing page, I have this:
             | 
             | The easiest way to create and share WireGuard Networks.
             | Define WireGuard networks, devices, and connections. Invite
             | friends, family and teammates to add their devices. View,
             | Scan or Download WireGuard configuration files.
             | 
             | I'm just not sure how else to put :)
        
               | INTPenis wrote:
               | >The easiest way to create and share WireGuard Networks.
               | Define WireGuard networks, devices, and connections.
               | Invite friends, family and teammates to add their
               | devices. View, Scan or Download WireGuard configuration
               | files.
               | 
               | I think it was a combination of me not expecting a
               | service like this, and the fact that you use terminology
               | like "invite".
               | 
               | You mean that as in "add devices of friends by inviting
               | them" right? Because the main question in my mind is
               | "wait, who's generating the keys? who's storing the keys?
               | who has access to my private key?"
               | 
               | I do not want to tell you how to write stuff, I'm an
               | autistic nerd with limited people skills. But I think it
               | would make more sense if you said something along the
               | lines of "easy way to share client wireguard config with
               | friends and family".
        
               | rudasn wrote:
               | No, I get it. I'm not a network guy so I don't know the
               | terminology :)
               | 
               | What I think is kind of confusing, is that I'm separating
               | the notions of a Network Device and the WireGuard Keys
               | that go with a device. So it's like this:
               | 
               | Network <-> Device <-> Invited Member <-> Interface
               | (PrivateKeys)
               | 
               | As a network owner/admin, you get to define your devices,
               | routes/connections etc. To associate and/or generate keys
               | for those devices, there's a separate step, the
               | Interfaces. Those are managed by end-users themselves,
               | who can generate and encrypt their key set right from the
               | browser.
               | 
               | Of course, you can just create an Interface for each
               | device in your networks so that your end-users won't have
               | to do anything other than scanning the QR codes or
               | downloading the relevant configs to their devices.
               | 
               | This design makes it super clear who has access to what:
               | Interfaces are owned by their creators, Devices are owned
               | by their Network owners or the Member they were assigned
               | to. Also makes it easier to make changes to WireGuard
               | related data (key rotation maybe?) without needing to
               | make changes to the network-level settings.
               | 
               | > "wait, who's generating the keys? who's storing the
               | keys? who has access to my private key?"
               | 
               | So, the user owning the network or the device can
               | generate keys for that device. The private keys, if
               | provided, are encrypted in the browser before storing
               | them on WireHub. The user who created the Interface has
               | access to the private key, if they provided it, and if
               | they remember the password they used to encrypt it in the
               | first place.
               | 
               | If you forget the password to an Interface, you create a
               | new Interface for that device with a new set of keys. The
               | configs of all other devices will be updated to reflect
               | that change (they will need to re-download and re-install
               | of course).
        
           | SMART_failure wrote:
           | Thanks - that's a really comprehensive response and I
           | appreciate it.
        
             | rudasn wrote:
             | Sure no problem :) let me know if you run into any issues.
             | Email in profile.
        
       | rudasn wrote:
       | So, there was an issue when you added devices to a network and
       | had the Assign to me flag enabled. That's fixed now!
       | 
       | Thank you kind strangers for hitting that bug :)
        
       | flas9sd wrote:
       | great idea to reduce scope and skip "the agent" part and let the
       | users do it, can be added later. When you do, you probably want
       | to introduce some means to query for and update IPs via api
       | first, to have all-dynamic nodes covered. Currently users need at
       | least 1 peer that is either static or has outside dyndns setup.
        
         | rudasn wrote:
         | > great idea to reduce scope and skip "the agent" part and let
         | the users do it, can be added later.
         | 
         | Yeah, you get it :)
         | 
         | I haven't really considered dynamic nodes but I was thinking of
         | eventually giving out dynamic domains myself, so that you can
         | just use that one for your Endpoint. Not sure if that would
         | help though for true p2p/non-hub networks.
        
       | unixfox wrote:
       | Does it support ipv6 private ranges and ipv6 peers?
        
         | rudasn wrote:
         | Sorry not at the moment, but is something I can spend some time
         | on if you're willing to walk me through your use cases :)
         | 
         | Thanks!
        
       | russelg wrote:
       | Awesome work! I can foresee this being very useful.
        
         | rudasn wrote:
         | Thanks! :)
        
       | cchance wrote:
       | is there no way to remove a network or device for that matter or
       | am i blind?
        
         | rudasn wrote:
         | Hehe sorry not yet! :)
        
       | kxrm wrote:
       | Nice project!
       | 
       | Super minor, not sure if you own "my-office.com" but consider
       | using "example.com" instead as that domain is specifically set
       | aside for documentation.
        
         | rudasn wrote:
         | Oops good catch! Where's that? :)
         | 
         | Thanks!
        
           | kxrm wrote:
           | > Where's that?
           | 
           | In the configuration example on the bottom of the main page.
        
       | ValtteriL wrote:
       | This looks useful, I'll give it a try when I have the need next
       | time.
       | 
       | What are your aspirations for it by the way? Are you looking to
       | monetize it?
        
         | rudasn wrote:
         | Thanks!
         | 
         | > What are your aspirations for it by the way? Are you looking
         | to monetize it?
         | 
         | You know.. Coding was my hobby as a kid, and I've been doing it
         | professionally for _years_ now and at some point I realised
         | that I don 't have to show for it. Something of my own, you
         | know?
         | 
         | Of course I started a million other stuff but this is my first
         | real actually useful and publicly shared project. So I'm happy
         | that's out there, happy it's been well-received, (super happy
         | the server didn't break a sweat), and excited to see where this
         | leads :)
        
       | kszyh wrote:
       | The question is what about the security of such a solution
       | compared to the self-hosted version of https://www.netmaker.io/.
        
         | fl0id wrote:
         | As I understand, wirehub does less and encrypts locally, can be
         | used without js. Sor some threat models that might be better
         | than trusting a vc backed company, even if they recently open
         | sourced.
        
         | rudasn wrote:
         | I've looked at netmaker before, but haven't used it nor have
         | examined any of its publicly shared source code. So I don't
         | know how exactly that works, but I'm guessing it's touching on
         | quite of a few layers of the stack.
         | 
         | WireHub, OTOH, gives you 0 LOCs to worry about especially if
         | you don't provide your PrivateKeys to begin with - of course,
         | the QR codes won't work, and you'd have to manually copy/paste
         | stuff around, but it works (it's a feature be design). I don't
         | provide clients/agents to install, you use stock WireGuard apps
         | as usual.
         | 
         | Without even having your PrivateKeys, the attack surface shifts
         | from WireHub to whatever else _you_ have going on in your
         | networks and networked devices.
        
       | mdekkers wrote:
       | This looks incredibly similar to wg-easy, which I see you have
       | cloned in your github repo as well. Is this simply a SaaS-y
       | frontend to wg-easy, or something different all together?
        
         | rudasn wrote:
         | If you've been that far you might as well view-source on
         | WireHub and see for yourself ;)
         | 
         | To answer your question though, wgeasy was definitely a source
         | of inspiration as to the simplicity and cleanness of the design
         | compared with other WireGuard related tools.
        
           | mdekkers wrote:
           | > If you've been that far you might as well view-source on
           | WireHub and see for yourself ;)
           | 
           | This isn't a service I currently understand I need - I
           | already have wgeasy and the site didn't make it clear to me
           | how this was better or different, so I don't really have time
           | to evaluate. I didn't want to sign up for the beta if I
           | wasn't going to use it :)
           | 
           | I did have questions around your future monetisation approach
           | and licensing, but also did not find ready answers.
        
             | rudasn wrote:
             | Yeah sure I get it :)
             | 
             | WireHub is like wgeasy in regards to the UI (a nice list of
             | devices and some buttons on the right), but different in
             | that it doesn't run WireGuard, it just generates the
             | configs.
             | 
             | So if you find yourself a bit worried of the single point
             | of failure that is wgeasy (all the private keys are kept in
             | plain text on the server running wgeasy), and you want more
             | flexibility in your WireGuard routing (not just 0.0.0.0/24,
             | per device rules), and the ability to securely share any of
             | your configs with others, then maybe give WireHub a try.
             | 
             | No future plans as of yet. This is just a side project.
        
       | m_santos wrote:
       | It is always great to see another solution using Wireguard, which
       | is a great technology for modern private connectivity.
       | 
       | I built https://github.com/netbirdio/netbird, which can be self-
       | hosted and offers an option to run Wireguard without managing
       | firewalls for P2P connectivity.
        
         | oynqr wrote:
         | I would love to try this out, but my VPN resources are limited
         | and having to set up an OIDC IDP really doesn't sound like fun.
        
         | Jacobinians wrote:
         | Except it is another hijacking of opensource software to
         | enslave people #SecureStorageOfWireGuardPrivateKeys
        
         | rudasn wrote:
         | Oh hey:)
         | 
         | I'm not sure if it was netbird or some other self hosted
         | solution I tried, but after doing the recommended one liner
         | bash install script I got locked out of my vm for some reason.
         | Still can't get in.
         | 
         | That's around the time I decided to start working on something
         | simpler.
        
       | karolist wrote:
       | This looks interesting. I'm currently evaluating my options of
       | just giving in to Tailscale or trying to replicate it with plain
       | Wireguard... or something like you've built. One thing I'm
       | intrigued about is Tailscale's MagicDNS, is there any way to
       | replicate it with just WireGuard?
        
         | rodlette wrote:
         | I just use plain DNS with plain Wireguard.
         | 
         | It's not as magic, but DNS can be made easy/automated with
         | https://github.com/octodns/octodns or
         | https://github.com/StackExchange/dnscontrol .
        
       | mmasu wrote:
       | this reminds me of zerotier. however i confess i don't know a lot
       | of how it works under the hood. what is the main difference of
       | this with zerotier in terms of potential use cases? it seems a
       | very cool project and would like to try it out.
        
         | rudasn wrote:
         | Thanks! :)
         | 
         | So, WireHub is basically a wireguard config generator. A tool
         | to generate some text files. What you do with those files is up
         | to you.
         | 
         | Because getting from text files to a fully working and secure
         | VPN is the real deal, you have things like zerotier, tailscale,
         | etc which provide you with a bunch of custom-made tools to do
         | that.
         | 
         | Problem is, with solutions like that you place a lot of trust
         | on these companies because they effectively control everything.
         | It's like trusting CloudFlare to be your DNS (no need to get
         | into _that_ discussion though).
         | 
         | So WireHub is kind of the middle ground. Makes it easy to
         | create and maintain wireguard networks (configs for each and
         | every device and their peers) and gets out of the way for when
         | it comes to deployment.
         | 
         | If Wirehub goes down, you just don't get to update your configs
         | via its UI. If it gets hacked, you get your public keys exposed
         | - no biggie, right?
        
       | leonixyz wrote:
       | Hi, nice project. The Single Sign On using Gitlab does not work
        
         | rudasn wrote:
         | Hey thanks for letting me know. I'll check it out once I get a
         | chance.
         | 
         | And I was wondering why I got no sign ups from there. Didn't
         | get any errors either though.. :/
        
       | teon wrote:
       | If you like to have the same functionality but self-hosted try
       | out: https://github.com/defguard/defguard
       | 
       | Cheers, Robert.
        
         | rudasn wrote:
         | 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.
        
       ___________________________________________________________________
       (page generated 2023-11-06 21:02 UTC)