After using Nebula for a short period, this is what I concluded:
- 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?)
-
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.
-
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.
-
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).
- 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.
After using Nebula for a short period, this is what I concluded:
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?)
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.
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.
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).
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.