[GH-ISSUE #5319] Arbitrary TCP/UDP support for the Reverse Proxy #10966

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

Originally created by @xangelix on GitHub (Feb 14, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5319

Is your feature request related to a problem? Please describe.
The current Reverse Proxy implementation is limited to Layer 7 (HTTP/HTTPS) traffic. This prevents the adoption of NetBird as a complete replacement for legacy VPN concentrators in enterprise environments.

While HTTP covers web apps, critical enterprise workflows often rely on opaque TCP/UDP protocols that cannot be wrapped in HTTP. Specifically, we are unable to expose:

  • Legacy Healthcare/Financial Interfaces: Systems using HL7 (MLLP), DICOM, or FIX protocols which run over raw TCP.
  • Proprietary Thick Clients: ERP systems (e.g., SAP GUI), industrial control dashboards (SCADA), or custom internal tools that use non-standard TCP streams.
  • VoIP and Streaming: SIP/RTP traffic which requires UDP support.

Without Layer 4 proxy support, we are forced to maintain parallel infrastructure (legacy VPNs or firewall pinholes) for these non-web resources, which fragments our Zero Trust strategy.

Describe the solution you'd like
I would like the Reverse Proxy to support Layer 4 (Transport Layer) proxying.

  1. Protocol Selection: Extend the "Protocol" dropdown to include TCP and UDP.
  2. Stream Handling: When a Layer 4 protocol is selected, the proxy should forward the raw byte stream without attempting to inspect headers, terminate TLS (unless SNI routing is specifically configured), or enforce HTTP semantics.
  3. Single-Port/SNI Routing: Ideally, allow TCP traffic to be routed via SNI (Server Name Indication) so multiple TLS-wrapped TCP services can share port 443, or allow the allocation of dedicated public ports for non-TLS TCP/UDP traffic.

Describe alternatives you've considered

  • Cloudflare Tunnels: This is not a viable alternative because it requires the connecting client to install cloudflared or use WARP to access non-HTTP services. We cannot ask external vendors or public users to install middleware just to connect to a specific port.
  • Cloudflare Spectrum: While this supports "clientless" TCP/UDP, it is gatekept behind expensive Enterprise plans for arbitrary ports.
  • Port Forwarding / VPS iptables: We currently hack this together by manually forwarding ports on a VPS into the NetBird mesh, but this defeats the purpose of NetBird's managed management dashboard.
Originally created by @xangelix on GitHub (Feb 14, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5319 **Is your feature request related to a problem? Please describe.** The current Reverse Proxy implementation is limited to Layer 7 (HTTP/HTTPS) traffic. This prevents the adoption of NetBird as a complete replacement for legacy VPN concentrators in enterprise environments. While HTTP covers web apps, critical enterprise workflows often rely on opaque TCP/UDP protocols that cannot be wrapped in HTTP. Specifically, we are unable to expose: * **Legacy Healthcare/Financial Interfaces:** Systems using HL7 (MLLP), DICOM, or FIX protocols which run over raw TCP. * **Proprietary Thick Clients:** ERP systems (e.g., SAP GUI), industrial control dashboards (SCADA), or custom internal tools that use non-standard TCP streams. * **VoIP and Streaming:** SIP/RTP traffic which requires UDP support. Without Layer 4 proxy support, we are forced to maintain parallel infrastructure (legacy VPNs or firewall pinholes) for these non-web resources, which fragments our Zero Trust strategy. **Describe the solution you'd like** I would like the Reverse Proxy to support **Layer 4 (Transport Layer)** proxying. 1. **Protocol Selection:** Extend the "Protocol" dropdown to include `TCP` and `UDP`. 2. **Stream Handling:** When a Layer 4 protocol is selected, the proxy should forward the raw byte stream without attempting to inspect headers, terminate TLS (unless SNI routing is specifically configured), or enforce HTTP semantics. 3. **Single-Port/SNI Routing:** Ideally, allow TCP traffic to be routed via SNI (Server Name Indication) so multiple TLS-wrapped TCP services can share port 443, or allow the allocation of dedicated public ports for non-TLS TCP/UDP traffic. **Describe alternatives you've considered** * **Cloudflare Tunnels:** This is not a viable alternative because it requires the *connecting client* to install `cloudflared` or use WARP to access non-HTTP services. We cannot ask external vendors or public users to install middleware just to connect to a specific port. * **Cloudflare Spectrum:** While this supports "clientless" TCP/UDP, it is gatekept behind expensive Enterprise plans for arbitrary ports. * **Port Forwarding / VPS iptables:** We currently hack this together by manually forwarding ports on a VPS into the NetBird mesh, but this defeats the purpose of NetBird's managed management dashboard.
saavagebueno added the feature-request label 2026-08-05 01:27:53 -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#10966