Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Empty endpoint #383

Open
strowk opened this issue Jun 11, 2024 · 0 comments
Open

Empty endpoint #383

strowk opened this issue Jun 11, 2024 · 0 comments

Comments

@strowk
Copy link

strowk commented Jun 11, 2024

From reading docs I have got this impression is that endpoint is required for kilo to generate wireguard configs. At the same time I know that it is not necessary for wireguard itself as it documents in server/client example. I.e one node can "initiate" tunnel and the other node would simply remember last ip it got authenticated communication from.

I have a setup where my rpi is behind NAT and it does have public IP from ISP (well, router does), but I don't actually know it and moreover I did not need it for my k3s to start on that node plus digitalocean droplet (that had static IP) , connected via wireguard where digitalocean wireguard interface does not have endpoint configured for rpi peer. This works thanks to wireguard roaming support (and keepalive's).

Now I don't want to stop at those two nodes and plan to get more digitalocean nodes and maybe more rpi's, plus DO nodes should be able to autoscale, hence I was looking at wireguard orchestrators. I did not see much in netmaker that would prevent me using it, except it does not seem to be native to k8s. Kilo looks more promising, except for that "know every location public IP" bit.

So the direction of my thinking was that maybe force-endpoint could have some sort of "empty" option that would just produce wireguard configs on other peers that would not have "Endpoint" with the expectation that roaming would be able to detect IP of node that has dynamic (and unknown beforehand) public IP.

I didn't see if such setup is quite documented, but maybe I am just confused somewhere or it could be feature worth adding?
I do know that I can workaround my issue by dynamicdns, but it seems to me like adding one more thing into equation, while wireguard by itself already is able to support such topology.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant