Feature request and general info: nat punching, keepalive, tunnel checks and other

[SOglf]

After using Nebula for a short period, this is what I concluded:

1. Lack of a periodic tunnel test. Nebula is not aware if the tunnel is down, it only gets that information when a peer tries to send some data, and well, it's too late then. The time needed for nebula to decide that the tunnel is dead is way too long, in that period everything has already happened and collapsed, game over.

Solution: add a periodic tunnel check, which will also act as a NAT keepalive in place of the current 5 second 1 byte udp packet. (Settable in the config?)

2. NAT punching is a broad topic, but one thing nebula could do, when trying to nat punch is a limited packet spray, just one or two ports up and down - this would be enough in most cases where the NAT is restrictive but does not use random ports.
   Ideally, it would be nice to implement a full packet spray, up to 100 ports up and down, with heuristics and learning.

3. Telling nebula, to NOT use public internet is a nightmare, no preferred network settings, nor relay settings, nor lighthouse settings work. It always doxxes itself by sending initial handshake packets over the plain internet or requests them from other peers, unless aggressively blocked on a firewall or bound to an internal interface.

4. Choosing the final network path is a bit random, but nebula aggressively tries to connect over an existing vpn tunnels, which in my case is not good, because it puts a load on crypto engines of those vpns, exactly the thing I wanted to avoid deploying nebula. I need those paths just as a backup, not primary routes. Setting preferred networks doesn't work. There is one advantage - if using openvpn, it has MLKEM already implemented and protects nebula traffic this way from PQ future attacks.

Solution: add a "last resort" address space setting, which will be used only when all other routes and relay are exhausted, OR strictly adhere to documentation spec which states, that public ipv4 is preferred over private ipv4 (but this doesn't work).

5. Nebula finds really wicked network paths between my nodes, some of which I didn't even know existed, but they are not short nor fast paths. A path choosing selector (based on criteria? TTL? latency? speed? jitter? multipath?) is mandatory, if nebula is to be used in an advanced routing environment.

Other ideas:
"Nebula interconnector" - some peers should not doxx themselves by sending hundreds of udp packets to god knows how many hosts - so a strictly limited nebula instance which would allow a remote peer to connect to it and use it as a relay to all other peers would solve this. A "nebula entry proxy". Current config, no matter how set up, always causes other peers to send handshake packets over the plain internet to this peer. Or worse, this peer responds to those packets. Also, putting the whole nebula network inside a vpn is not the best solution to this.
Solving it by using a wireguard/openvpn <-> nebula interconnector is also not acceptable - the traffic is decrypted at that very point.

Packet padding and obfuscation - nebula is not designed to be an OBFS proxy nor a similar tool, but some simple packet padding and handshake packet size randomization would be a nice feature to have.

Nebula runs on udp, so this opens a door, to port some code from the hysteria tool, which uses QUIC and BRUTAL algos, which would allow to push data over big long fat pipes with a much more stable speed. It would probably need an implementation of at least a port forward though.

Does nebula run over openvpn? Yes it does, flawlessly.
Does nebula connect in local lans between peers automatcally? Yes, no problem.
Does nebula choose the right relay? Nope. Nightmare level 1/10
Does nebula choose the worst routes? Nope. Most of the time those are acceptable. But not always. Too random.
Is nebula high throughput capable? Yes, maxes out 1gbit instantly no problem, no cpu hogging.

An example scenario, just one, because there can be thousands: A user connects from a highly insecure location.
The current path has to look like this:
Ephemeral encrypted storage to keep keys for nebula -> UDP encapsulation in openvpn TCP -> TOR obfs/webtunnel -> TOR exit -> TCP vpn entry -> UDP decapsulation -> outboud UDP traffic to the internet or internal vpns.
If breaking of E2EE is allowed, a simpler openvpn-nebula interconnector may be used.

So there you have it.
In general, Nebula is not a universal tool, it needs supplementing with hysteria, openvpn, wireguard, TLS, udp port blocks, and a few other things, but it does one job very well in it's default configuration - aggressive connection between peers no matter the cost even of full metadata visibility.

[johnmaguire]

Hi @SOglf - thanks for trying Nebula and taking the time to share your feedback.

You're right that Nebula has no periodic tunnel test. Test packets are sent on outbound traffic after a period of inactivity (timers.connection_alive_interval, 5s by default) and tear down after another period of inactivity (timers.pending_deletion_interval, 10s by default.) This means it can take up to 15s to detect a dead tunnel. We tried to address this from another angle by using tunnels.drop_inactive: true and tuning tunnels.inactivity_timeout - defaults to 10m, but you could set this lower if you find that it's insufficient for your NATs.

Regarding your points about avoiding routes over the Internet, or other VPNs, lighthouse.remote_allow_list and/or lighthouse.local_allow_list should allow you to restrict by CIDR (or interface for local_allow_list.) Unlike preferred_ranges, these are hard restrictions. If this isn't working for you, we'd definitely like to know about it, with configs and logs: https://nebula.defined.net/docs/config/lighthouse/#lighthouseremote_allow_list

Sequential port prediction (probing a couple of ports up/down) is cheap and low-risk, and I think that's a reasonable feature request to consider - I'm not aware of an existing ticket. Full birthday-paradox spray across ~100 ports is something we're unlikely to do: it's unreliable, it looks like a port scan, and it's very noisy. For NATs that won't punch, we recommend relays.

There's definitely improvements that could be made to relay selection, tracked as #720. Please share any specific recommendations or thoughts there!

Regarding obfuscation/padding/alternative transports, Nebula doesn't aim to be a censorship-resistant protocol and it's unlikely that these are features we'd build into the protocol today.

I've gone ahead and moved this to Discussions as it's covering quite a bit of disparate feedback. You're more than welcome to open issues for specific feature requests. Thanks!

[johnmaguire]

Just thinking through this all in more detail, I think what you're describing is a hub-and-spoke model: each sensitive node connecting to a central trusted node, and reaching everything else through it + strict metadata hygiene. This is a coherent goal, but it's not what Nebula was designed to be: a reliable mesh that prefers direct peer-to-peer communications for performance reasons.

Relays exist in Nebula to add reliability - not privacy. Encryption occurs end-to-end but they were not designed to mask underlay addresses. The mesh is coordinated through the Lighthouse, and most of your pain points originate here: it intentionally, by design, shares metadata (IP addresses) to any node which requests it to facilitate that.