How to configure Nebula's full tunnel mode

[Ops-online]

Network topology description

1. Nebula node 1,2 and non-Nebula node A,B is behind the nat network;
2. The gateway of non-Nebula node A is Nebula node 1；
3. The gateway of non-Nebula node B is Nebula node 2；

How to configure Nebula's full tunnel mode so that non-nebulas nodes behind one nebula node can access the Internet through another nebula node

The Nebula node uses centos7.

Thanks.

[jradxl]

I'd love to know the answer to this too! Not tried it yet, and had assumed a route on non-Nebula node X would suffice. But I guess you've tried that! (Nice diagram, how did you draw it?)

[actronzs]

me too ;-)

[Mrc527]

Hello guys,

I tried to add a certificate with subnet 0.0.0.0/0 and then adding to the config of the client the following: - route: 0.0.0.0/0 via: 192.168.xxx.xxx

Unfortunately the route is not getting created on my client. If I put any other subnet, even a /8, it works perfectly.

Do you see any reason why this should not work?

Once this works, I think setting up the configuration shown in the picture is trivial

[ghost]

+1 I believe other network solutions call these endpoints exit nodes

[mrbluecoat]

Would unsafe_routes work for this use case? https://github.com/slackhq/nebula/issues/214#issuecomment-608065985

[mrbluecoat]

ref #280

[higgssinglet]

Love to see this implemented for I like to use this when traveling

[johnmaguire]

While Nebula still does not currently aim to support full tunneling, I wanted to share some information from the NebulaOSS community Slack that may be valuable to others discovering this issue:

Regarding unsafe_routes, @brad-defined writes:

unsafe routes works basically for RFC 1918 space, so you can use larger CIDR ranges [than a /32]. Nebula registers a route to the Nebula TUN device for all traffic that needs to transport through Nebula, and it also sends that traffic in UDP packets to peers (which could be on the LAN or on the internet.) If you register a 0.0.0.0/0 unsafe route in a Nebula client, then it'll register a route on the box to send all IPv4 traffic to the Nebula TUN device. So, when Nebula tries to send UDP traffic to some peer on the internet, that UDP packet gets locally routed back to the Nebula TUN device. there may be things we could try to get a full tunnel to work, but the product doesn't target that use case today. you can specify non-RFC 1918 CIDR blocks for unsafe routes, and that will work, too, as long as there are no Nebula peers running in that CIDR (meaning, Nebula doesn't need to send any UDP packets to that address space.)

Community user Claudio notes:

I have had some success with having run nebula in its own network namespace on a Linux system (ip netns), move the external interface to the internet in there and then move the nebula interface back into the “main” network namespace with a 0.0.0.0/0 route (+unsafe_routes to 0.0.0.0/0). It’s all a bit awkward to configure, but it does seen to work. (not sure it would work with the nebula reload/SIGHUP support, though). The idea of having the client run in one network namespace and then moving its TUN interface into another namespace was taken from the wireguard docs: https://www.wireguard.com/netns/

Link to discussion in the NebulaOSS community Slack: https://nebulaoss.slack.com/archives/CRWJJM52B/p1658476565627369

[jaymemaurice]

Would this work with some management of the route metrics?

[johnmaguire]

I'm closing this as a dupe of #280. Let's try to keep discussion over there - thanks!