[Feature Request] Allow traffic from Network Resource to Netbird Clients #6186
Replies: 1 comment
|
Just wanted to bump this and see if the NetBird team has any thoughts or plans around supporting this traffic pattern. This is still a blocker for our use case. We have routed Network Resources where the client starts the initial connection, but the resource then needs to send a separate UDP flow back to the NetBird client without MASQ/NAT. FlexRadio is our main example, but this seems like it could also affect SIP/RTP, media systems, SDR/radio systems, and other control/data split protocols. Right now our only working option is keeping end-user clients on 0.59.5. Newer clients break this because the resource-initiated UDP traffic back to the client is blocked. MASQ is not a workable fix for us because the application needs the real client/session behavior. Is this something the team would consider supporting either as:
Even knowing whether this is on the roadmap, intentionally out of scope, or something that would need community contribution would be helpful. I’m happy to test builds or validate behavior in a real deployment. |
Uh oh!
There was an error while loading. Please reload this page.
Before posting
Product area
Client / Agent
Problem or use case
The network resources we are using are FlexRadio HF radios. When SmartSDR, FlexLib, or another FlexRadio control client connects to a radio, it first establishes a TCP control session with the radio. That TCP session is used for radio commands, state updates, slice control, and session negotiation.
After the radio accepts the control connection and streaming is enabled, the radio sends VITA49/VRT UDP packets back to the client on a separate UDP flow. This traffic is separate from the TCP control session and may use a different UDP port than the original control connection.
The issue is that the UDP VITA49 stream is initiated by the radio toward the NetBird client. From the Network Resource ACL perspective, this appears as a new resource-to-client flow, not as return traffic for the client-initiated TCP control session. Because that direction is no longer allowed, the VITA49 UDP packets are dropped.
In short: the FlexRadio client can successfully open the TCP control connection to the radio, but the radio then starts a separate UDP VITA49 stream back to the client. Since that UDP stream is radio-initiated and separate from the TCP session, the Network Resource cannot reach the NetBird client unless resource-to-client traffic is allowed.
This behavior changed after PR #4653 was released. After that change, Network Resources were no longer able to initiate traffic toward NetBird clients. These resources need to be able to reach clients without the client first starting that specific communication flow.
Masquerading does not work for this use case because of how FlexRadio network resources behave. The radio needs to see and communicate with the actual client/session information correctly. NAT/MASQ changes the traffic in a way that breaks expected FlexRadio behavior.
I am able to upgrade all route nodes and the NetBird server to the latest version and things work correctly. However, the end-user NetBird client must stay on 0.59.5. If the user upgrades higher than 0.59.5, they can no longer use these Network Resources correctly because the resource-initiated UDP traffic is blocked.
Other users are seeing the same underlying problem with different types of Network Resources. The original issue is here for additional context:
#4936
and for logs I submitted.
#4842
The main problem is not FlexRadio-specific only. FlexRadio is one example of a broader issue where a Network Resource needs to initiate traffic back to a NetBird client without masquerading and without the client first initiating that exact protocol/port flow.
Proposed solution
I think the best fix would be to give admins a supported way to allow Network Resources to reach back to NetBird clients without requiring masquerading.
Right now, the client can start the connection to the resource, but some real-world systems do not keep all of their traffic inside that one connection. FlexRadio is a good example. SmartSDR connects to the radio over TCP first, but once the radio accepts the session, the radio starts sending VITA49/VRT data back to the client over UDP on a separate port.
From the application’s point of view, this is all part of the same radio session. From the current NetBird ACL behavior, though, that UDP stream looks like a brand-new connection started by the resource, so it gets blocked.
The goal would be to support that kind of traffic in a controlled way.
Preferred Fix
When a NetBird client is allowed to connect to a Network Resource, NetBird could allow that same resource to send related traffic back to that client for the life of the session.
For example:
The user opens SmartSDR.
SmartSDR connects to the FlexRadio over TCP.
The radio accepts the session.
The radio then sends VITA49/VRT UDP traffic back to the same NetBird client.
NetBird allows that traffic because it is tied to the client’s active connection to that resource.
This would not need to be wide open. It could be limited by:
resource group
user group
protocol
port or port range
timeout / session lifetime
That would keep the security model intact while allowing these types of network resources to work properly.
Another Good Option
Another option would be to add an explicit ACL setting for Network Resource → NetBird Client traffic.
That way, an admin could intentionally allow a specific resource, or resource group, to reach a specific group of users on specific ports.
For example:
Allow FlexRadio network resources to send UDP traffic to approved FlexRadio users on the required VITA49/VRT ports.
This would be simple to understand and easy to troubleshoot because it would be a clearly defined rule instead of hidden behavior.
Why MASQ Is Not a Good Workaround
Masquerading is not a good fix for this problem.
It may allow packets to pass, but it changes the traffic in a way that breaks how these resources expect to communicate. With FlexRadio, the radio and SmartSDR need proper direct session behavior. When MASQ is enabled, the radio no longer sees the real client the same way, and SmartSDR behavior becomes unreliable or broken.
So the needed fix is not just “make the packets pass somehow.” The needed fix is:
Allow routed, non-masqueraded Network Resources to initiate approved traffic back to NetBird clients.
Why This Matters
This is not only a FlexRadio issue. FlexRadio is just a clear example because it uses a TCP control session and a separate UDP media/data stream.
The same problem can affect other systems that work the same way, such as:
radio/SDR systems
VoIP/SIP/RTP systems
video/media systems
industrial control equipment
other devices that use separate control and data channels
The main request is for NetBird to support this traffic pattern intentionally, instead of requiring users to stay on client version 0.59.5 or use masquerading that breaks the application.
A good long-term solution would let admins safely say:
This Network Resource is allowed to reach back to these NetBird clients on these ports, without NAT/MASQ.
Alternatives or workarounds considered
Using netbird client 0.59.5 on the user side, packets are allow to flow through and they can use the network resources correctly.
Community impact and priority
Number of users: 100
Deployment type: Self-Deployed
Frequency: Daily
Examples from other tools or products
No response
Security, privacy, and compatibility considerations
No response
Implementation ideas
No response
Are you willing to help?
Yes, I can test or validate a proposed implementation.
Additional context
No response
All reactions