We’re not really designed for that sort of vpn. This is really meant for a mesh topology as opposed to a “gateway to the internet” topology. That said, in our next release it will have that option, where you can set a peer as an internet gateway and then all other peers will be set that way

I see two use cases personally for me. The mesh topology for my personal networks and devices.

I need the "internet gateway" topology solution for my clients at present. Would love to work on that.

Have you found a way to route multicast traffic over the WireGuard tunnel? Been trying to solve this one for my home setup. Would be great for P2P communication.

I can show you how we’re designing that. Im actually working on that today if you’d Iike to see. That said, there are a bunch of mature options for creating an internet gateway vpn with wireguard, is there any reason you’re not going with those?

I will let you know when I'm fully free to see that later today in a few hours or so. The reason is... Cost. Open Source solutions currently lack stuff like user management, timeout, auto validation via clients' email/password etc. If you know of an open source solution that does functions like the above for WireGuard gateway, that would be great. Trying to start a small VPN business for side income. Thought of putting my networking knowledge to use hahaha...

At present I'm using this to lease out my VPN access to clients (end-users) But I still need to manually keep track of timeouts/expired users + it has Pi-Hole as bloatware on the docker image itself. https://gitlab.com/cyber5k/mistborn

Have you looked at Algo or Subspace? https://github.com/trailofbits/algo https://github.com/subspacecloud/subspace

Subspace is dead. I've looked at it. I'll check Algo. Never heard of it before.

The main problem is a lot of them lacks IPv6 support.

I would love to have you support and use our project, but that is really not our primary use case, and it may not get the support it needs

Algo is a very popular option so definitely check that out

I would put our mission much more as "let servers talk to each other securely" as opposed to, "let people reach the internet securely"

Of course we'd love to do that too, but at this point we dont have the manpower

Yeah I understand

But I could use your project for my personal networks and devices and I need them to be able to talk to each other.

yup! That is definitely a great use case. And again, in the next release we will have the option you are talking about, but still, we havent added config generators for any non-linux devices, and it doesnt have dns support, so the sort of thing you'd like to implement is likely a ways off

Hmm... Any way we can tunnel multicast traffic over the tunnel? Like UPnP for instance

Or Bonjour

Good question, I don't know much about it so can't really tell you, but if it can be done over plain wireguard on linux then yes

I'm not sure myself if it's possible with WireGuard

oooo this seems pretty active, I've been really looking into a WG mesh and I'm probably going to use a DHT (distributed hash table) with WG and make an overlay. I have a strict IPV6 requirement. I would really like to not have to do this lmao. Do yall have a time frame for IPV6 adoption and the UDP hole punching?

You don't need UDP Hole punching if the server has a public IP.

i have nodes that are behind CGNAT, the IPV6 is to allow the nodes behind residential IPs who don't have access to a public IPV4 address and no IPV6

I know what UDP hole punching is for :)

You don't need UDP Hole punching for clients behind a CGNNAT if the topology is where they connect to your public IP.

I have done extensive research and testing for CGNATs and worked with an ISP to alleviate some of its problems

yes, but I don't want a hub spoke topology

You don't need that either

This project is coded in such a way that it's not hub-spoke