Feature request: Support UDP/TCP port fowarding to a host without setting up a tun

[johnmaguire]

Allow binding another Nebula node's port as a local port on the machine. This would allow tun-less access to that host/port combo.

Discussed in #1011

^{Originally posted by nick008a November 12, 2023}
Feature request : support UDP/TCP port fowarding without setting up a tun

This will allow nebula to work without root, and one could further set up a socks proxy with this to enable #915

^{Originally posted by nick008a November 12, 2023}

i was looking for something like ngrok which allows you tunnel a port to a remote machine (a local machine can access 127.0.0.1:8080 to talk to, say, 127.0.0.1:8081 on a remote machine without setting up a tun)

[aa51513]

I'm also looking forward to this feature.

[sybrensa]

Yes, something like this would be great!
I'm currently using SSH for this, but still need a working tun adapter or direct connection.

[cre4ture]

I'm also interested in this. I would have some time to implement it if its not yet in progress by someone else.
Even tough I'm new to golang, I guess I understand the basic principles and should be able to find a way.

@johnmaguire do you know if currently someone is working on the topic?

[sybrensa]

I'm also interested in this. I would have some time to implement it if its not yet in progress by someone else. Even tough I'm new to golang, I guess I understand the basic principles and should be able to find a way.

@johnmaguire do you know if currently someone is working on the topic?

I don't think I can contribute anything to the programming, but if you need somebody to test or write docs/readme or something I'd be happy to help!

[cre4ture]

@sybrensa Thanks for offering support. I'll let you know as soon as there is something halfway stable. ;-)

I started already with doing some first tries:

1. UDP forwarding with manually creating and parsing the UDP headers+checksums
   This basically works already, but I think with limited functionality. There may only be one client to the UDP server port.
2. I started with TCP the same way. But I quickly figured out that the TCP-Stack is much more complex than the UDP one such that a manual implementation of it just doesn't make sense.
   2.1. Custom TCP stack: Too complex.
   2.2. Use of Wireguard stack implementation: Documentation totally missing. No Way.
   2.3. Use gvisor (google/netstack): Seems feasible. i started but then by chance figured out that this stack is already used in service.go. According to the PR add gvisor based service library  #965 this was added for the case where the nebula "endpoint" shall be used directly from within a seperate application such that there is no need for a TUN-Device and such no need for root rights.

This PR #965 seems to be the perfect preparation for this feature. My next try will therefor be based on this.

By the way, I hope nobody else is already working on the topic. @nbrownus do you know who might know this?

[cre4ture]

@sybrensa pls have a look to my PR #1179. Its in a shape such that it can be tested I think. I personally only did some netcat based manual tests till now. But I will also extend it to some real applications running on it.

[sybrensa]

@sybrensa pls have a look to my PR #1179. Its in a shape such that it can be tested I think. I personally only did some netcat based manual tests till now. But I will also extend it to some real applications running on it.

Hey, I'm looking at it right now. From what I can tell from the provided config example, do I need to configure nebula clients on both ends to expose ends to make this works, or can it be used similar to the "unsafe_routes" or SSH tunnel too? (Basically only specifying on one client to expose localhost:1234 to 192.168.100.60:80, or even export localhost:1234 to <other_ip>:80 VIA 192.168.100.60?

I'll try at least with some real scenarions where live video can be streamed over the tunnel using TCP.

[cre4ture]

... or can it be used similar to the "unsafe_routes" or SSH tunnel too? (Basically only specifying on one client to expose localhost:1234 to 192.168.100.60:80, or even export localhost:1234 to <other_ip>:80 VIA 192.168.100.60?

I designed it with the ssh tunnels in mind. So you should be able to use "unsafe_routes" when the config file allows it for the normal usecase.
But I didn't test this till now.

[sybrensa]

... or can it be used similar to the "unsafe_routes" or SSH tunnel too? (Basically only specifying on one client to expose localhost:1234 to 192.168.100.60:80, or even export localhost:1234 to <other_ip>:80 VIA 192.168.100.60?

I designed it with the ssh tunnels in mind. So you should be able to use "unsafe_routes" when the config file allows it for the normal usecase. But I didn't test this till now.

Alright I'll give it a try. I can already confirm that an RTSP video stream seems to work well so far (10 minutes and counting). So there's the first real application for you! :-)

I did notice when forwarding the webpage from the device nebula is running on, the logs get flooded with these messages:

It doesn't seem to impact the performance at all, just curious why this happens.

[cre4ture]

its nice to hear that it performs already for some officially tested real usecases. Thanks for the feedback :-)
I think I need to tune the log-output more. Because the "EOF"s are normal for a terminating tcp connection. That's for sure not an issue. The other logs ("use of closed ...") could be related to this as there are always two goroutines per connection (forwarding outgoing and ingoing data). But I will try to reproduce this and double check it.

[sybrensa]

I tried to get it working with an unsafe_route, but didn't succeed yet. Perhaps I'm doing it wrong.
It's good to know I've never used the unsafe_routes before, so it might be a wrong configuration elsewhere.

I've created a cert with a subnet 10.115.2.0/23 and ran it on client A

On client B, I've set up the following config:

tun:
  user: true
  disabled: false
  dev: nebula1
  drop_local_broadcast: false
  drop_multicast: false
  tx_queue: 500
  mtu: 1300
  unsafe_routes:
    - route: 10.115.2.0/23
      via: 100.104.2.2

port_tunnel:
  outgoing:
    udp:
    # format of local and remote address: <host/ip>:<port>
    #- local_address: 127.0.0.1:3399
    #  remote_address: 192.168.100.92:4499
    tcp:
    # format of local and remote address: <host/ip>:<port>
    - local_address: 127.0.0.1:3399
      remote_address: 100.104.8.2:1554
    - local_address: 127.0.0.1:4499
      remote_address: 10.115.3.55:80

When trying to access localhost:4499, nothing happens, but the logs on client B say the following:
INFO[0042] Handshake timed out durationNs=6774611742 handshake="map[stage:1 style:ix_psk0]" initiatorIndex=4255603315 localIndex=4255603315 remoteIndex=0 udpAddrs="[]" vpnIp=10.115.3.55

[cre4ture]

It's sad that the unsafe_routes didn't work. I also never used this feature so far. I can't detect anything wrong on what you did.

Meanwhile I reduced the log-level for the logs that report the connection termination. It seems that some tools do not properly close the TCP-IP connection. E.g. close the receiver side when the sender is still sending data. Thats a bit weird. But as it apparently doesn't lead to any practical issues, I decided to ignore it for now.

[cre4ture]

Update regarding the "unsafe_routes": I tested myself and It also didn't work for me.
I then checked the source-code more in detail. I came to the conclusion that the mechanism that installs the foreign routes is not active for the "tun.user=true" case. Only the "real" tun, and only on linux seems to support this.
I will spend time to figure out if it would be possible to make te unsafe_routes also available for the user-tun. But this should be handled in a seperate PR I guess.

[sybrensa]

Update regarding the "unsafe_routes": I tested myself and It also didn't work for me. I then checked the source-code more in detail. I came to the conclusion that the mechanism that installs the foreign routes is not active for the "tun.user=true" case. Only the "real" tun, and only on linux seems to support this. I will spend time to figure out if it would be possible to make te unsafe_routes also available for the user-tun. But this should be handled in a seperate PR I guess.

Ah that explains. In theory you'd say that if Nebula allows you to route packets over the network, it should be able to do the same with the user tun except use the local port binding instead of the route. The principle doesn't really change. But perhaps you're right about putting it in a separate PR.