Trouble connecting to RDS (Remote Desktop Services) #668

Open
opened 2025-11-20 05:15:42 -05:00 by saavagebueno · 2 comments
Owner

Originally created by @TSJasonH on GitHub (Mar 1, 2024).

Describe the problem

Some users cannot connect to RDS, or have sporadic issues connecting.
RDS uses a gateway connection over port 443/tcp and establishes connections to brokers on the backend for an RDP connection.

To Reproduce

Steps to reproduce the behavior:

  1. Connect to Netbird
  2. Click on RDP connection
  3. Enter authentication
  4. RDP Client immediately reports "There was a problem connecting to the remote resource. Ask your network administrator for help."
    RDPNBFail

Expected behavior

  1. Connect to Netbird
  2. Open RDP connection
  3. Enter authentication
  4. RDP client negotiates connection and opens desktop.

Are you using NetBird Cloud?

No, self-hosted docker instance.

NetBird version
0.26.2 across the board
(this issue was present in previous versions)

NetBird status -d output:

Everything is connected when checking status -d.
The traceroute to the resource works as expected. It hops through the netbird peer we have setup to route this network exactly as it should.

Even the RDWeb webpage at the same address as the RDS gateway will load just fine for the user. The issue happens when attempting to connect with the RDP client.
The RDP connection file is identical and distributed to the users so there is no variance there.
All users have no problem accessing websites over the same NB connection.

If the users connect to Wireguard the RDP connection works flawlessly every time.
Does netbird do anything special with connections on port 443?

The really weird thing is that it does work for some users (but sometimes not).

I have tested this registry change https://github.com/netbirdio/netbird/issues/730 on some users laptops and it seems to resolve the problem some of the time. I'm uncertain if that is a red herring because it didn't fix it 100% of the time.

I also tried changing some options in the /etc/sysconfig/netbird file on the router peer. Right now I've settled on these options:
NB_ICE_KEEP_ALIVE_INTERVAL_SEC=15
NB_ICE_DISCONNECTED_TIMEOUT_SEC=45
NB_ICE_FORCE_RELAY_CONN=false

Grasping at straws at this point.

Originally created by @TSJasonH on GitHub (Mar 1, 2024). **Describe the problem** Some users cannot connect to RDS, or have sporadic issues connecting. RDS uses a gateway connection over port 443/tcp and establishes connections to brokers on the backend for an RDP connection. **To Reproduce** Steps to reproduce the behavior: 1. Connect to Netbird 2. Click on RDP connection 3. Enter authentication 4. RDP Client immediately reports "There was a problem connecting to the remote resource. Ask your network administrator for help." ![RDPNBFail](https://github.com/netbirdio/netbird/assets/25849774/2b6c4de1-c6b7-4d23-9da5-3f4848611fe2) **Expected behavior** 1. Connect to Netbird 2. Open RDP connection 3. Enter authentication 4. RDP client negotiates connection and opens desktop. **Are you using NetBird Cloud?** No, self-hosted docker instance. **NetBird version** 0.26.2 across the board (this issue was present in previous versions) **NetBird status -d output:** Everything is connected when checking status -d. The traceroute to the resource works as expected. It hops through the netbird peer we have setup to route this network exactly as it should. Even the RDWeb webpage at the same address as the RDS gateway will load just fine for the user. The issue happens when attempting to connect with the RDP client. The RDP connection file is identical and distributed to the users so there is no variance there. All users have no problem accessing websites over the same NB connection. If the users connect to Wireguard the RDP connection works flawlessly every time. Does netbird do anything special with connections on port 443? The really weird thing is that it does work for some users (but sometimes not). I have tested this registry change https://github.com/netbirdio/netbird/issues/730 on some users laptops and it seems to resolve the problem some of the time. I'm uncertain if that is a red herring because it didn't fix it 100% of the time. I also tried changing some options in the /etc/sysconfig/netbird file on the router peer. Right now I've settled on these options: NB_ICE_KEEP_ALIVE_INTERVAL_SEC=15 NB_ICE_DISCONNECTED_TIMEOUT_SEC=45 NB_ICE_FORCE_RELAY_CONN=false Grasping at straws at this point.
Author
Owner

@nazarewk commented on GitHub (Apr 18, 2025):

@TSJasonH is this still an issue for you?

@nazarewk commented on GitHub (Apr 18, 2025): @TSJasonH is this still an issue for you?
Author
Owner

@TSJasonH commented on GitHub (Apr 18, 2025):

Yes it's a pervasive issue for many of my users. They can't use NB and instead have to depend on a full WG tunnel. We're still running on 0.28.4.

@TSJasonH commented on GitHub (Apr 18, 2025): Yes it's a pervasive issue for many of my users. They can't use NB and instead have to depend on a full WG tunnel. We're still running on 0.28.4.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/netbird#668