[HN Gopher] Launch HN: Gravitl (YC W22) - VPN Platform Based on ...
___________________________________________________________________
Launch HN: Gravitl (YC W22) - VPN Platform Based on WireGuard
Hi HN, this is Alex and Dillon from Gravitl, based in the mountains
of Asheville, North Carolina. We built Netmaker
(https://github.com/gravitl/netmaker), a virtual networking
platform for cross-cloud computing and Kubernetes. It's secure,
automated, and extremely fast. Networking across environments is
hard and slow. WireGuard can solve this, but it's tough to run at
scale. WireGuard is a fast and efficient VPN protocol that is
growing quickly in popularity. Linus Torvalds called it a "work of
art," and it was added to the Linux kernel in 2020. It now runs on
most major operating systems. We created Netmaker to automate
WireGuard-based networks at scale. It opens up a bunch of use cases
that are otherwise infeasible. With Netmaker, our users are
managing edge networks, connecting fleets of unmanned aerial
drones, and cloud-bursting k8s clusters for machine learning. Alex
got the idea for Netmaker while he was in New Mexico, staying in
the desert to escape the pandemic. We were trying to run a
distributed Kubernetes cluster. Our goal was to create a cloud
provider with no infrastructure, using compute provided by users.
To start, we bought a couple raspberry pis and some cloud VM's,
hooked them all together, and ran a k3s cluster across them using
WireGuard. We realized we needed a mesh VPN to do this at scale.
None of the existing options gave us everything we needed, so we
built Netmaker. We put it on GitHub, and it became so popular that
we decided to work on Netmaker exclusively. Netmaker works on a
client-server model (https://docs.netmaker.org/architecture.html).
A central config server tells each machine where its peers are and
how to reach them. The local client automates network settings and
DNS on each machine. The result is a flexible virtual network that
stays in sync whenever machines are added, removed, or there is a
change in state. Without Netmaker this is challenging, because
WireGuard requires reconfiguration whenever any peer in the network
changes. In addition, the network can be blocked by factors like
NAT, firewalls, and port availability. Netmaker anticipates and
solves for these factors, while being compatible across Mac, Linux,
Windows, and FreeBSD. There are other solutions out there with
similarities, but we've got some key distinctions. After all, we
created Netmaker out of necessity, because the other solutions
didn't meet our requirements. First off, Netmaker is super fast
because it can use kernel WireGuard. There are some other
WireGuard-based solutions like Tailscale, but they use userspace
WireGuard, which is much, much slower. Second, Netmaker is
tailored towards the cloud and Kubernetes. Stuff like OpenVPN was
built before the cloud became a go-to deployment strategy.
Finally, Netmaker is fully self-hostable. A lot of existing options
are SaaS, but our users want control of any servers that are
routing their traffic or managing their virtual networks. As for
what's next, with Dillon at the lead, we're putting in a lot of
work to overhaul the code base, implement community-driven
features, and pull Netmaker towards a "pure WireGuard" vision.
We're planning an enterprise release in the coming months which
will have a few features that businesses need at scale, without
taking away from the free community version. In the meantime, we
have a simple support subscription for the existing community
edition: https://gravitl.com/plans. We're always looking for ways
to do things better. If you have thoughts, we'd love to hear them,
and if you're doing anything cool with WireGuard that could be
relevant to our project, we'd love to hear that too. We've also got
a community on Discord you're welcome to join at any time:
https://discord.gg/zRb9Vfhk8A Thanks for reading, and Happy New
Year!
Author : afeiszli
Score : 157 points
Date : 2022-01-05 15:05 UTC (7 hours ago)
| scottwitcher83 wrote:
| lizen_one wrote:
| Pretty exciting stuff! This looks really interesting. I have a
| similar with setup hosts in the cloud, in the office, at home,
| and on UAVs with cellular internet. It was important that the
| hosts 'see' each other and it works on IP level in any direction.
|
| When I set it up, I have chosen ZeroTier instead of WireGuard. It
| does the following: (a) Hosts discovery and initiating handshake
| between clients with the help of a server from ZeroTier, (b) NAT
| hole punching, (c) pushing centrally managed routes to hosts, (d)
| network ACL rules. I primarily have chosen it because it is easy
| to setup by anyone (e) and I do not have to manage a server (f).
|
| - Can you tell a little bit how Graviti compares to it. I guess
| WireGuard itself does not have the features (a) to (f). I guess
| the Netmake server replaces the ZeroTier servers and provides
| some of these features.
|
| - Are you inclined to install Netmaker client on any host or use
| one node in a LAN as a router?
|
| - Is this more geared to servers/professional managed hosts or
| also for laptops?
|
| For my usecase with ZeroTier I found the following currenlty
| missing features useful:
|
| - Easy setup of a node as a router (or virtual switch) to connect
| a local network to the virtual one without installing it on all
| devices (hardware like GPS receiver do not allow to install new
| software). Of course, you can do it with the normal Linux tools.
|
| - Installing it only inside a Docker container and not on the
| host. But I guess that will not be possible because it has to
| live in the kernel.
| afeiszli wrote:
| For your points: a) We handle host discovery via the Netmaker
| server b) We do NAT hole punching with our own implementation
| on the server c) Yup, we do this too d) No ACL's yet, but this
| is coming in the Enterprise version e-f) We don't have a SaaS
| version at this point, but server deployment takes about 5
| minutes, can be run on a $5/mo VPS, and uptime has been
| production level in our tests.
|
| Router is obviously preferable when routing to LAN but is
| harder to support. If it's FreeBSD or OpenWRT, go router, but
| otherwise a client on a Linux node works fine as a router.
|
| This is definitely geared more towards servers/VM's etc, but
| does work on Laptops as well. We have Windows support and you
| can even loop in your phones.
|
| We do actually have a docker image for the client. We're not
| strictly tied to the kernel version of WireGuard, and you can
| use userspace wherever it is a necessity.
| grcfvfrqwc wrote:
| ramshorst wrote:
| User name checks out.
| ryukafalz wrote:
| This looks interesting, but I don't think I can legally use it
| for my use case if I'm running it on Linux? (Small VPN shared
| with a few friends - right now we use Tinc, which is nice but a
| bit of a pain to configure.) It looks like I'd have to provide
| Linux under the terms of the SSPL if I let anyone besides myself
| connect to a VPN running this, which I obviously can't do because
| it's GPL.
|
| I'm not expecting that I'd _actually_ get into trouble for
| running a small network with my friends, but I prefer not
| violating software licenses. :)
| afeiszli wrote:
| I am not a lawyer, but the only point of the SSPL at this stage
| is to prevent direct competition from companies who would just
| take the project and sell it as their own. It's the same
| license used by MongoDB. That said, it's on us to make this as
| clear as possible, and we'll work with our lawyers to do that.
| We want people using this wherever they have a need for it, and
| they shouldn't feel threatened by the license.
| ryukafalz wrote:
| Yeah, the big difference between this and MongoDB is that
| MongoDB is typically only ever used on the backend of an
| application. You generally wouldn't give someone else direct
| access to your MongoDB instance, but you might give them
| access to your VPN, at which point as far as I can tell the
| SSPL distribution requirements would kick in. (Because you're
| "enabling third parties to interact with the functionality of
| the Program ... remotely through a computer network.")
|
| This is probably fine for internal usage within a company (as
| the whole company is legally the same entity) but for
| individual use it's concerning. Although it might also be
| problematic if you ever want to give a contractor access to
| your VPN too.
| basch wrote:
| Would you be giving everyone in your network direct access
| to your management gui? If the clients are just running
| wireguard and their own copy of an interface, would you be
| fine? Your friends are interacting with your copy of
| wireguard not Netmaker. (This comment applies to their
| future roadmap moreso than their current offering.)
| ryukafalz wrote:
| If the clients were really only interacting with
| Wireguard, then... yes, I think you're right. But yeah,
| their current offering has the clients connecting with
| the server via a gRPC API, so at the moment I think it's
| still an issue. Unless you're using external clients[0]
| for almost everything, but that eliminates a big part of
| the reason for using this.
|
| Covers the contractor use case I think (provided the
| contractor isn't running services they intend to expose
| to _you_ on the VPN), but not my hobbyist use case (both
| me and a friend share services with each other via our
| VPN).
|
| [0] https://docs.netmaker.org/external-clients.html
| afeiszli wrote:
| That's a very fair point. I'll note again that I'm not a
| lawyer, but our intention is definitely not to limit those
| sorts of use cases. If it does, we need to make some
| changes. I'm going to make sure we figure out a clear way
| that allows people to do this. We went with SSPL because
| it's a lot easier to start restrictive and switch to more
| open than vice versa, but we're definitely open to making a
| change if it's going to prevent regular usage.
| mkaymalright wrote:
| Thank you for posting it here and congrats. Have been wanting
| basically this ever since WireGuard got merged into the kernel
| but never found anything suitable. Good luck and happy new year!
| afeiszli wrote:
| Glad to hear it, let us know your thoughts!
| turdnagel wrote:
| How do you pronounce your company's name?
| afeiszli wrote:
| gravit-all
| RL_Quine wrote:
| https://netmaker.org/_images/node-details.png
|
| Shown on the marketing pages, the controller supports pushing
| configurations which include commands for `postup` and
| `postdown`; does this mean that it implicitly has root code
| execution on every participant in the network? I don't think it
| would be designed like that, but I'm a bit confused how this
| could be working without introducing that as a concern.
| afeiszli wrote:
| You're right, and that's definitely a concern for a lot of
| users. The idea is you should be able to set any WireGuard
| configuration file setting from the server, including PostUp
| and PostDown, which are just arbitrary commands.
|
| However, we're adding a switch for this pretty soon which will
| allow disabling the edit-ability of those fields.
| RL_Quine wrote:
| It should probably be loudly default-disabled or outright
| removed, that's a very, very unexpected feature. It's an
| unprecedented tool for moving laterally and gaining gigantic
| amount of access within internal systems. Nobody could
| possibly build a secure network around a VPN where the
| controller can bypass all isolation, containerization, and
| all access controls through a web interface on another
| machine.
| gunapologist99 wrote:
| Agreed. That's a bit terrifying!
| afeiszli wrote:
| Totally fair. You've convinced us to put that into our next
| release. While that's a big flaw it's a simple fix, and it
| should be in the code base by the end of the week.
| RL_Quine wrote:
| Well done.
| earedpiece wrote:
| Impressive, I am new to coding, but I will definitely test this
| on a digital ocean server today, and take it for a spin.
| afeiszli wrote:
| Let us know how it goes!
| dolmen wrote:
| "A central config server tells each machine..."
|
| So single point of failure?
| afeiszli wrote:
| We have a few supported ways to deploy the server in an HA
| configuration. We've also got additional backup/failover
| mechanisms in the roadmap, though those will take a couple
| months.
| pid-1 wrote:
| I'm a Sysadmin / DevOps / Cloud Whatever and I find the solutions
| for this problem space seriously lacking.
|
| Most companies choose between not securely connecting their stuff
| correctly or having a complete mess of an internal network.
|
| So congratz and all the power to you.
| afeiszli wrote:
| Thanks! I came from the DevOps world too and noticed the same
| thing. There seems to be a disconnect since most people on the
| developer side never want to touch networking. Beyond what we
| put in the post, I think there's a big need for more stuff that
| brings networking up the stack into a space that is digestible
| to developers.
| ayewo wrote:
| I know that this is a bit meta but you've expressed a thought
| that had been lurking at the back of mind very succinctly :)
| unixhero wrote:
| Welcome to Ycombinator :)
|
| I am a user of this solution for my company, and also for my
| homelab. It works great! Just wanted to say that, and thank you
| for the open source free as in libre license.
| afeiszli wrote:
| Thanks! Glad you're enjoying it. Feel free to reach out on
| Discord if you've got any feedback.
| henning wrote:
| Thank you for being a real company working on something
| interesting and not some god-awful NFT thing
| afeiszli wrote:
| don't worry, we're saving that for v2.0 (jk)
| acatton wrote:
| Congratulation on the launch!
|
| Quick question, does Gravitl plan to become a company donor to
| Wireguard in the near future[1]? I think it would be great if
| companies which, as is their right, profit from FLOSS, also give
| back to FLOSS, not just with code.
|
| Again, good luck with your adventure :) .
|
| [1] https://www.wireguard.com/donations/
| afeiszli wrote:
| We would love to become a sponsor once we have the resources to
| do that. You're totally right in all regards about this.
| Without Jason and WireGuard, we'd be nothing. You just
| convinced me to send a donation but obviously at this stage it
| can only be a drop in the bucket.
| sha016 wrote:
| That's great! I fell in love with Wireguard after using
| OpenVPN for years and donated a small amount. Sure they're
| drops in the bucket, but they add up if more people get out
| of the mindset that their contribution is negligible. What's
| more is the author can get some form of feedback.
| afeiszli wrote:
| Very true. I could see WireGuard turning into something at
| the level of Kubernetes, where there is a gigantic
| ecosystem built around that core piece of technology, which
| everyone needs to support.
| jvanderbot wrote:
| Nice! I was just building a similar (but more specialized) tool
| for https://aenac.dev
|
| There's a few offerings in this space, some geared toward edge,
| some toward orgs. For example:
|
| - tailscale https://tailscale.com/download
|
| - Innernet https://github.com/tonarino/innernet
|
| - wiretrustee https://wiretrustee.com/
|
| Care to differentiate from those above?
| afeiszli wrote:
| I've commented on a few of these elsewhere in the thread. Each
| one has a couple differences like self-hostable, having a GUI,
| various configuration options, but the main thing I'd like to
| add is how we're moving the project for the long term (and this
| is again copy/pasted from another comment I added):
|
| Our aim is to really be a "WireGuard controller." You should be
| able to shut down our server and agents and your network should
| still run fine, and you should be able to manually modify all
| your WireGuard interfaces if necessary.
|
| This isn't something that any of those options allow you to do
| and I think is a fundamental difference in how we're viewing
| the scope and role of Netmaker.
| vertis wrote:
| I have a few qualms with this app:
|
| 1. For a Linux user, you can already build such a system yourself
| quite trivially by getting an FTP account, mounting it locally
| with curlftpfs, and then using SVN or CVS on the mounted
| filesystem. From Windows or Mac, this FTP account could be
| accessed through built-in software.
|
| 2. It doesn't actually replace a USB drive. Most people I know
| e-mail files to themselves or host them somewhere online to be
| able to perform presentations, but they still carry a USB drive
| in case there are connectivity problems. This does not solve the
| connectivity issue.
|
| 3. It does not seem very "viral" or income-generating. I know
| this is premature at this point, but without charging users for
| the service, is it reasonable to expect to make money off of
| this?
|
| /s[1]
|
| In all seriousness, congrats on the launch. It looks like you're
| solving an interesting problem. Having done at least little work
| on multi-region platforms I can attest to how painful it is.
| Hopefully your product will help solve this.
|
| [1]: See https://news.ycombinator.com/item?id=9224 if the above
| doesn't make sense.
| afeiszli wrote:
| 1. Our system is only compatible with Windows XP so I don't
| think this is relevant.
|
| 2. USB's aren't a viable long-term strategy. With supply chain
| issues they are likely to cost $3000/gb this year.
|
| 3. This is actually an NFT-based platform. So-called "money" is
| not a concern for us.
|
| Hopefully the "/s" isn't necessary for this one but I better
| add it anyway. Thanks for the good words!
| vertis wrote:
| I almost paraphrased it to meet your launch a bit better, but
| then I thought that might be a bridge too far with the
| sarcasm.
|
| Very glad you're going down the NFT route, solves so many
| problems.
| [deleted]
| gz5 wrote:
| @afeiszli congrats on the launch.
|
| @vertis, if you are looking at multi-region or multi-cloud, you
| may be interested in how Ozone solved this for private k8s
| https://ozone.one/blog/ozone-zitifies-private-kubernetes-dep...
|
| disclaimer: i am founder of a company which builds saas on the
| openziti open source which Ozone used in their solution as
| well. however, doesn't seem competitive with this solution from
| vertis - openziti being built for different use cases.
| vertis wrote:
| It's a past life at the moment. Hopefully one day it will be
| a problem for me again (pre-launch startup currently).
| jedberg wrote:
| You had me there for a second. I was about to link you to that
| comment. :)
| vertis wrote:
| I think it's almost a tradition now to reference that comment
| on any launch.
| jonfw wrote:
| This is a space that's surprisingly ripe for disruption. Cloud
| providers push 'hybrid cloud' by allowing you to integrate your
| own machines with their networks- but they maintain the upper
| hand in that relationship because they own your network.
|
| Tools like this allow users to own their network and avoid that
| lock in. All that's needed here is auto-scaling integrated w/
| various cloud providers, and some canned templates for creating
| K8s clusters and common services. At that point- we've got a self
| hosted cloud w/ 80% of what the big guys offer.
| afeiszli wrote:
| Agreed entirely. I used to work in the "hybrid cloud" space,
| and networking was always conspicuously absent from solutions
| that are supposed to be cross-cloud. I view it as the missing
| link in a lot of hybrid/multi/edge cloud solutions.
| sudosteph wrote:
| So happy for you guys! It's awesome to see a fellow startup from
| the Asheville-area kicking some butt. Wish you all the best and
| hope to see you around town more.
| afeiszli wrote:
| Thanks! Asheville FTW. I think I can guess who you are, in
| which case, I hope all is well!
| cassianoleal wrote:
| Congrats on the launch!
|
| A couple questions from me, if you don't mind.
|
| I currently use Tailscale for my home lab. My current model is
| similar to old-school road warrior VPNing, where I have my router
| as a node that routes to the LAN using the internal (non-meshed)
| IPs. Does your solution support that? How easy is it to deploy
| and configure it in that way?
|
| Another feature I use is "exit nodes", i.e. my router as a
| gateway to the Internet, similar to what consumer VPNs (Mullvad,
| PrivateInternetAccess, etc) do. This offers me 2 things: more
| security when I'm on insecure networks (airport or other public
| WiFi, etc); and allows me to access things as though I'm at home
| when I'm traveling abroad. This is a one-time configuration and I
| can easily switch it on and off on demand via the desktop or
| phone app. Is this an option in your product?
|
| Edit: s/customer/consumer/
| fierro wrote:
| do you have a write up or blog post on your setup?
| afeiszli wrote:
| I don't think we have one specifically for a setup like that,
| but we have lots of tutorials here:
| https://gravitl.com/resources
| cassianoleal wrote:
| Not really, but it was very simple and easy.
|
| The "hardest" part is managing the tailscale installation on
| the router, since the OpenWRT packages seem to be quite old.
| I went old-fashioned and just download the ARM tarballs and
| uncompress them.
|
| I lifted the init.d script from someone else's blog post [0]
| and adjusted the path to the binaries.
|
| After that I've pretty much just followed the official docs
| to implement LAN routing [1] and the exit node [2], then set
| the router's cert so it doesn't expire, which is done on the
| Tailscale GUI.
|
| Install the app on the devices, connect everything to the
| tailnet and Bob's your uncle.
|
| [0] https://willangley.org/how-i-set-up-tailscale-on-my-wifi-
| rou... [1] https://tailscale.com/kb/1019/subnets/ [2]
| https://tailscale.com/kb/1103/exit-nodes/
| afeiszli wrote:
| This is probably the #1 use case among our users, so yes it is
| totally do-able. Depends a bit on the router, since we don't
| support the full range of OS's yet, but if it is FreeBSD-based
| or OpenWRT you should be good to go. Otherwise, any Linux
| computer in your home network can act as the router to the LAN.
|
| I believe we actually had a feature like exit nodes before
| Tailscale released theirs :) Our is called an "egress gateway"
| and it acts in pretty much the same way.
| cassianoleal wrote:
| My router is indeed OpenWRT-based, but even if that was not
| directly supported I can run LXC containers on it.
|
| Thanks for your reply, I will try to deploy Netmaker
| alongside Tailscale and compare for my needs!
| afeiszli wrote:
| Sounds good, let us know how it goes! And be sure to do a
| speed comparison too :)
| ghostpepper wrote:
| What about routers that support wireguard natively, such as
| Mikrotik?
| afeiszli wrote:
| Routers are hard because they all have their custom OS's,
| and we need to do system level stuff besides just
| WireGuard. We're open to expanding the range where needed,
| and will happily support anyone in the community who wants
| to port the client to a new OS, but for now we're sticking
| to OpenWRT and FreeBSD as the supported routers.
| BitPirate wrote:
| Very cool. I remember recommending you to switch from
| nginx+certbot to caddy for an easier deployment :)
| afeiszli wrote:
| That was a fantastic recommendation, and it definitely did make
| deployment 10x easier. If you ever want to chat, reach out on
| Discord!
| deskamess wrote:
| In the Enterprise version it would be nice to see:
|
| - Named groups/subnets for a single NetMakerServer (lets say
| [Users] and [Servers])
|
| - Access control capability: Allow/disallow inter/intra group
| connectivity. For example, using the previous groups : [Users]
| can connect to [Servers] only (not other [Users]) and [Servers]
| can connect to other [servers] only (not [Users]). Basically, for
| this case, the peer list returned to NetClient's only contain the
| [Servers]. More generally, it is the concept of public vs private
| - not sure if this is needed on a group/subnet or individual
| netclient level.
|
| - MFA requirement for certain Groups. Example: [Users] who have
| not connected to the network in the last X hours/other criteria
| will need to MFA (provided by NetMaker+TOTP or other IDP like
| Okta). Server-server connections will never need to MFA. This is
| one of those Enterprise security check list items in security
| reviews.
|
| - Ideally: Ability to run the NetMakerServer on Windows (IIS,
| Nginx, Apache) without having to launch containers/install VM's.
|
| Congratulation ons on your launch. Will keep an eye on things.
| afeiszli wrote:
| I think you'll be happy with the Enterprise version based on
| your list, we've had very similar thoughts. One question on the
| final point, where do you see the need to install the server on
| Windows? We've had one other user ask for this, but not sure if
| I see the need.
| deskamess wrote:
| Company uses Windows exclusively and there are no in-house
| Linux ops/admin skills. We have good ops/admins resources for
| Windows and we need to leverage that. A native solution (even
| if running behind Apache/Nginx) is preferable. In addition
| this would be a critical part of the infrastructure so we
| would want that piece to be somewhat familiar to the
| ops/admin resources for debugging (access the box, restart a
| service, troubleshoot networking issues, etc).
|
| Edit: This is a requirement for self-hosted but if your
| enterprise solutions offers it as a highly available service
| that would by-pass this issue. It would need to be HA and
| spread in such a way that a single cloud provider going down
| does not affect things.
| afeiszli wrote:
| I think until we get more users requesting this, it will
| probably stick on the back burner for some time. We've
| designed several server components assuming it's deployed
| on Linux, and it's streamlined for containers. However, if
| there's an org interested in pursing this (and has some
| golang + ops skills) it should be do-able with a bit of
| effort, and we can provide some advice. It might make for a
| good community project.
| e12e wrote:
| > One question on the final point, where do you see the need
| to install the server on Windows?
|
| Can any client be an egress node?
| deskamess wrote:
| What is an 'egress node'?
| afeiszli wrote:
| Currently just Linux machines can be egress nodes.
| gigatexal wrote:
| How does this compare to tailscale?
| afeiszli wrote:
| Main differences are: #1 Speed #2 It's self-hostable
| gigatexal wrote:
| What makes it faster. #2 I get.
| afeiszli wrote:
| Tailscale uses userspace WireGuard as opposed to kernel.
| This on it's own can be up to ~50% slower. They also will
| frequently fall back to public relays, which depending on
| distance can add on substantial additional latency.
| pxeger1 wrote:
| Will the enterprise version be subject to the https://sso.tax/?
| (Please say no!)
| afeiszli wrote:
| we've actually already got OAuth support in the community
| version for Google, Azure, and GitHub. The enterprise version
| may add some extra features, though we haven't determined all
| of what that will be yet.
| cakoose wrote:
| The Linus "work of art" quote is slightly misleading. Here it is
| with more context:
|
| _Can I just once again state my love for it and hope it gets
| merged soon? Maybe the code isn't perfect, but I've skimmed it,
| and compared to the horrors that are OpenVPN and IPSec, it's a
| work of art._
| afeiszli wrote:
| Apologies, didn't mean for that to be misleading. Still, he got
| it into the kernel in record-time for a new feature, which has
| got to be saying something.
| 40four wrote:
| Really cool to see a Ycombinator start based out of my old
| hometown of Asheville! Congratulations on the launch, I will keep
| an eye on the project!
| afeiszli wrote:
| Thanks, and cheers from the Blue Ridge Mountains. I'll save you
| some white duck tacos.
| 40four wrote:
| Haha nice! I'm in Greenville SC now, luckily we have White
| Duck as well. Even got our own Rocky's Hot Chicken this year
| :)
| afeiszli wrote:
| Oh dang, Greenville is great too.
| jwcrux wrote:
| Congrats on the launch! Could you expand a bit on how you
| differentiate your product from other products in the space like
| Tailscale and Nebula?
|
| Edit - I see you mention that Tailscale uses userland WireGuard.
| Is that the biggest difference between the two? Do you foresee
| yourselves running into issues by not using the userland
| implementation?
| [deleted]
| afeiszli wrote:
| The biggest differences with Tailscale are that you can use the
| kernel version (speed) and that we are self-hostable. We
| actually noticed a major contributor to the speed difference
| between us and them was a lot of times, they'll route traffic
| through their relays which can eat up a good amount of time.
|
| With Nebula, they're a lot closer on speed, but also we've got
| a management GUI which makes things a lot easier. We were very
| close to using Nebula in our early days. The main thing that
| stopped us was, we decided WireGuard was going to be the
| standard in the future, and wanted to be based on WireGuard.
|
| That leads to a bit more fundamental of a difference which is a
| bit harder to quantify. Our aim is to really be a "WireGuard
| controller." You should be able to shut down our server and
| agents and your network should still run fine, and you should
| be able to manually modify all your WireGuard interfaces if
| necessary. We're getting close to that vision but aren't quite
| there yet.
|
| That last point leads back to the kernel thing. We use kernel
| by default, but really, Netmaker can use any WireGuard
| implementation. If users are scared of the security
| implications of using kernel, they can use the userland
| version, and Netmaker should be able to pick that up just fine.
| They can even run it in a docker container on their machine.
| gunapologist99 wrote:
| This is great! Can you also compare to Headscale and
| Zerotier?
|
| How do you handle NAT compared to these other options? I've
| run into issues with WireGuard when _both_ sides are behind
| residential NATs (or AWS EC2 IGW); as you know, Nebula solves
| this with "lighthouse" servers (which are self-hosted but
| externally accessible), and Tailscale uses its third-party
| intro devices.
|
| Do the Gravitl servers have to always listen on an exposed
| port?
| afeiszli wrote:
| It is way, way faster than Zerotier. Headscale I am less
| familiar with, and they do make Tailscale self-hostable,
| but they're a community-driven project I'm not sure how
| reliable it'll be long term (can't speak for the author).
|
| On the NAT side, we provide 3 layers of traversal options:
|
| #1 (default) port forwarding: This actually works in a
| surprisingly well, for about 90% of environments, but does
| require an exposed port.
|
| #2 UDP Hole Punching: The server acts similarly to a Nebula
| "lighthouse" and will tell clients where to reach each
| other. This covers that small situation of dualing NAT's,
| and doesn't require the exposed port.
|
| #3 Relay: In situations where neither works such as CGNAT,
| you can set a public node as a relay to route traffic to
| the "hidden" node
| gunapologist99 wrote:
| Awesome, thanks!
| easton wrote:
| Tailscale has some functionality to automatically
| determine what flavor of NAT traversal is necessary, this
| isn't a big deal but do I have to configure the nodes to
| use these methods or will your client figure this out
| itself?
| afeiszli wrote:
| Right now you need to choose your own option. We're
| planning to automate this in the next couple of months. I
| will say, this isn't always a bad thing. We have a lot of
| users who switched from Tailscale because it was
| frequently falling back to relay, often via public relays
| that were hundreds of miles away from them, causing big
| increases in latency. We want to give people the
| automation, but also the choice.
| easton wrote:
| Good idea! I'll have to give this a spin, I like the idea
| of "nebula but wireguard".
| znpy wrote:
| > but they're a community-driven project I'm not sure how
| reliable it'll be long term
|
| Don't take this the wrong way, but subtly/implictly
| implying that some software is not going to be reliable
| in the long run because it only has a community behind is
| low-key FUD.
| afeiszli wrote:
| Nahh you're right, that's not a fair criticism at all,
| and we rely on tons of community-driven stuff. I only
| meant that as a differentiator because to some companies,
| they need to know there's a company behind the project
| for support purposes or they're not gonna use it (whether
| or not that's fair of them).
| lwhsiao wrote:
| Can you compare to innernet from tonari?
| afeiszli wrote:
| Mainly we give a lot more configuration options as well as
| a GUI. I'm also not sure if they run on anything other than
| Linux (I think not?). We can run on Mac, FreeBSD, and
| Windows. If you're just looking to create a pure mesh
| network with linux-based devices, they're definitely
| comparable and I think you'd just have to try out both and
| see what you like more.
| anderspitman wrote:
| > You should be able to shut down our server and agents and
| your network should still run fine, and you should be able to
| manually modify all your WireGuard interfaces if necessary.
|
| This is excellent.
| Shadonototra wrote:
| Meh, why would i use your service when i can already self host
| everything with a simple docker file, in the cloud environment of
| MY choice
|
| If it was 2004, i would have understood, but this is a problem
| already solved decade ago
|
| "private slack channel" won't be enough to justify 70 dollar a
| month
| afeiszli wrote:
| A good portion of people are all-in on deploying everything to
| a single cloud. We're not really targeting those people/orgs.
| But There's also a large number of people who, for whatever
| reason, need to deploy stuff in multiple places.
|
| The existing subscription isn't really what we're looking to
| sell. We started offering it because some users asked us for
| extra support, so we created it for them, but really the main
| product will be the enterprise version in a couple months.
| kemals wrote:
| Thanks for providing quite good context in the post itself!
|
| I was just about to ask about differences with Tailscale, which
| is solving a lot of the challenges outlined in the post, but you
| answered it:
|
| "First off, Netmaker is super fast because it can use kernel
| WireGuard. There are some other WireGuard-based solutions like
| Tailscale, but they use userspace WireGuard, which is much, much
| slower."
|
| Good luck!
| afeiszli wrote:
| Thanks! That does miss one other key difference, which is that
| you can self-host our server. Also, we won't route your traffic
| through our relays, which can make stuff quite a bit slower.
| artificialLimbs wrote:
| Search for 2fa and two factor return nothing (relevant) on the
| support page. You want me to serve a web page to administer my
| VPN without 2fa?
|
| This does look fantastic and like something I dreamed about
| making a few months ago otherwise. Good work.
|
| *edit: clarity
| BusyLurker3K wrote:
| Been using Netmaker for about 6 months now. It is a really
| fantastic tool. Congratulations and looking forward to see it
| grow.
| afeiszli wrote:
| Thanks! I appreciate the long-time users who stick with us
| through the upgrade process (or lack thereof).
| grouphugs wrote:
___________________________________________________________________
(page generated 2022-01-05 23:00 UTC)