[GH-ISSUE #5465] Extend netbird expose to allow raw TCP (+ TLS termination) #11254

Open
opened 2026-08-05 01:29:05 -04:00 by saavagebueno · 0 comments
Owner

Originally created by @crntnvdl on GitHub (Feb 26, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5465

Is your feature request related to a problem? Please describe.
Extend the new expose command to allow exposing TCP ports. And possibly terminate TLS with an automatically provisioned certificate.
This would cover one more use case where developers need to expose more complex services like databases, AMQP or Minecraft servers fwiw.

Describe the solution you'd like
A clear and concise description of what you want to happen.
Something similar to the tailscale funnel command, it has a --tcp flag telling it to expose a raw tcp socket.

  --https value
        Expose an HTTPS server at the specified port (default mode)
  --proxy-protocol value
        PROXY protocol version (1 or 2) for TCP forwarding
  --tcp value
        Expose a TCP forwarder to forward raw TCP packets at the specified port
  --tls-terminated-tcp value
        Expose a TCP forwarder to forward TLS-terminated TCP packets at the specified port

Ideally the implementation could be shared with a serve-like command to make it easier to expose services inside NetBird: it's already easy to do by using the VPN IP when binding and the service will be available (as long as policies allow it).
Looking even further, it could allow HTTPS within NetBird by provisioning certificates when the DNS domain is actually resolvable and pointing to the management or a proxy and sending them to the client.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
You can kinda hack this by installing a NetBird client on a dedicated machine, configure GatewayPorts clientspecified in /etc/sshd_config and use ssh -R <remote_ip>:<remote_port>:<local_ip>:<local_port> <host>.

Additional context
Add any other context or screenshots about the feature request here.
Since the proxy is expected to run in containers it could be provided a port range (possibly 0-65535) to allocate randomly or let users pick which one to use.

Originally created by @crntnvdl on GitHub (Feb 26, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5465 **Is your feature request related to a problem? Please describe.** Extend the new `expose` command to allow exposing TCP ports. And possibly terminate TLS with an automatically provisioned certificate. This would cover one more use case where developers need to expose more complex services like databases, AMQP or Minecraft servers fwiw. **Describe the solution you'd like** A clear and concise description of what you want to happen. Something similar to the `tailscale funnel` command, it has a `--tcp` flag telling it to expose a raw tcp socket. ``` --https value Expose an HTTPS server at the specified port (default mode) --proxy-protocol value PROXY protocol version (1 or 2) for TCP forwarding --tcp value Expose a TCP forwarder to forward raw TCP packets at the specified port --tls-terminated-tcp value Expose a TCP forwarder to forward TLS-terminated TCP packets at the specified port ``` Ideally the implementation could be shared with a `serve`-like command to make it easier to expose services inside NetBird: it's already easy to do by using the VPN IP when binding and the service will be available (as long as policies allow it). Looking even further, it could allow HTTPS within NetBird by provisioning certificates when the DNS domain is actually resolvable and pointing to the management or a proxy and sending them to the client. **Describe alternatives you've considered** A clear and concise description of any alternative solutions or features you've considered. You can kinda hack this by installing a NetBird client on a dedicated machine, configure `GatewayPorts clientspecified` in `/etc/sshd_config` and use `ssh -R <remote_ip>:<remote_port>:<local_ip>:<local_port> <host>`. **Additional context** Add any other context or screenshots about the feature request here. Since the proxy is expected to run in containers it could be provided a port range (possibly 0-65535) to allocate randomly or let users pick which one to use.
saavagebueno added the feature-request label 2026-08-05 01:29:05 -04:00
Sign in to join this conversation.
No Label feature-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11254