netbirdio
VITA49 packets seem to be dropped
Describe the problem
I'm part of a radio club that has been using netbird successfully to remote access HF radios. Everything was working well until version 0.60. Basic run down of how it works is the radio software starts the connection with a TCP hand shake, the radio acks the connection then start streaming UDP VITA49 packets to the software. Everything seem to be working fine until we upgraded from 0.59.12 to 0.60.2. Looking at wireshark on both sides of the tunnel, I see the handshake and VITA49 stream on the radio side and but only the TCP handshake on the client side. The VITA49 packets never seem to make it through the tunnel. I've ran tcpdump on the network routing peer and see the traffic on both the wt0 interface and ens18 interface. I've checked the netbird logs on both sides and don't see anything about it dropping that connection. I have multiple sites that this happening at and I'm kinda lost on what to do next. If needed I've saved the wireshark captures.
Expected behavior
To get all packets from radio TCP and UDP VITA49.
Are you using NetBird Cloud?
Self-Hosted
NetBird version
0.60.2
Is any other VPN software installed?
No
If yes, which one?
Debug output
To help us resolve the problem, please attach the following anonymized status output
netbird status -dA
Create and upload a debug bundle, and share the returned file key:
client side - 7863647c2661000989ad1bbc44fde56fcb49c4b2bf92f10145fcda57bc671697/800873d9-5b20-4925-907d-427901126894
routing peer - 7863647c2661000989ad1bbc44fde56fcb49c4b2bf92f10145fcda57bc671697/33a85440-9307-4037-978a-cbc6ef14d262
netbird debug for 1m -AS -U
Uploaded files are automatically deleted after 30 days.
Alternatively, create the file only and attach it here manually:
netbird debug for 1m -AS
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
Have you tried these troubleshooting steps?
- [ x] Reviewed client troubleshooting (if applicable)
- [ x] Checked for newer NetBird versions
- [ x] Searched for similar issues on GitHub (including closed ones)
- [ x] Restarted the NetBird client
- [ x] Disabled other VPN software
- [ x] Checked firewall settings
Did some more testing. I have software to connect to the radio via my iphone and I'm receiving all packets just fine.
Even more testing has been done. downgrading the client on my windows machine to 0.59.5 to match the iphone and I am recieving the packets. Everything is working like normal. The mangement side of things is still on 0.60.2. I have no clue what has changed between these two versions. Thoughts?
I've now tried version 0.60.7 for management, and network node, and client node. This is still not working. I had to roll the windows client back to 0.59.5 to recieve those packets correctly.
The client drops the inbound udp packets:
2025-11-21T22:47:44-05:00 TRAC Dropping local packet (ACL denied): rule_id= proto=UDP src=10.10.2.183:4993 dst=100.85.50.11:4991
It seems you previously relied on a bug that allowed the inbound connection. The "Routed Network -> NetBird Client" direction is currently not supported for ACLs. As a workaround, you can enable masquerading for that subnet and create a "Routing peer -> Client" ACL instead
The client drops the inbound udp packets:
2025-11-21T22:47:44-05:00 TRAC Dropping local packet (ACL denied): rule_id= proto=UDP src=10.10.2.183:4993 dst=100.85.50.11:4991
It seems you previously relied on a bug that allowed the inbound connection. The "Routed Network -> NetBird Client" direction is currently not supported for ACLs. As a workaround, you can enable masquerading for that subnet and create a "Routing peer -> Client" ACL instead
Well that makes sense but kinda sucks. The way these radios and their software work don't like MASQing at all. So I guess for now we will stick with 0.59.5 until there is a way to make the ACLs go the other way is added.