nebula
nebula copied to clipboard
slackhq
Feature Request: Route traffic through other nodes like Tinc VPN.
Nebula looks like a great VPN but one great feature that is missing is being able to automatically route traffic through other nodes in case each node is not able to talk directly to each other like Tinc VPN does. This is a VERY powerful mesh feature that has allowed for greater high availability in case network traffic between two nodes directly get blocked or becomes erratic that Tinc is able to re-route the traffic through different nodes. If Nebula supported this feature then most Tinc users [like myself] would switch over to Nebula.
This PR is for an opposite request... but I think it can also satisfy your request: https://github.com/slackhq/nebula/pull/217
That PR appears unrelated.
I would also like to see this, as it provides an efficient failover method should some routes break.
Somewhat related to #204. I believe this is being worked on (see also rawdigits' comments on #33 ).
Having traffic being able to re-route through the lighthouse is a first step but to be feature complete like Tinc, traffic should also be able to be re-routed through other nodes in case the lighthouse isn't available/reachable. [even to make it a toggle able feature]
Having traffic being able to re-route through the lighthouse is a first step but to be feature complete like Tinc, traffic should also be able to be re-routed through other nodes in case the lighthouse isn't available/reachable. [even to make it a toggle able feature]
I agree that a full dynamic routing solution would be the real solution here. I think figuring out a way to let the user configure that wholly independently and have it "peer" over the Nebula interfaces. The issue with this is that traffic would have to be decrypted by nebula, go through the kernel routing table, and finally reenter the Nebula overlay at each hop. I think Nebula could pull the routes in and route the traffic directly (even if the intermediary node is not in the proper Security Group), but I'm not sure.
Also see these: https://github.com/slackhq/nebula/issues/204#issuecomment-999035177 https://github.com/slackhq/nebula/issues/274
Splitting the routing out from Nebula lets the user pick from any number of existing routing protocols, and keeps the devs working on the parts of the project they're passionate about instead of attempting to reimplement a given routing protocol within Nebula.
If handling the routing directly within Nebula is preferred, I (currently) recommend BATMAN routing.
If handling the routing directly within Nebula is preferred, I (currently) recommend BATMAN routing. @tarrenj
Tested with ipv4 nebula:
It is not working on because: If use batman over l2 you must have mac-address on the tunnel interface. If use batman over l3 you must have a broadcast address on the tunnel interface. Nebula proto doesn't have it both.
upd. any dynamic routing proto not working with nebula, for example ospf may be runned, but routing not working p.s may be i did something wrong
@falshunov Thanks for the extra info! I haven't had time to actually test myself yet, so that's very helpful.
Nebula 1.6.0 is released with a Relay feature, to cover cases like a Symmetric NAT. https://github.com/slackhq/nebula/pull/678
Check out the example config to see how to configure a Nebula node to act as a relay, and how to configure other nodes to identify which Relay can be used by peers for access. Take a look at https://github.com/slackhq/nebula/issues/33#issuecomment-1180569297 for more info on how to configure it.
Due to the release of the relay feature, I'm going to close this issue out as solved. If you're continuing to experience connectivity issues, please feel free to open up a new issue or join us on Slack. Thanks!
