[GH-ISSUE #2797] Severe performance impact when using Win11 RDP to another Win11 session on v0.30.3 #6229

New Issue

@rihards-simanovics commented on GitHub (Oct 28, 2024):

here are the 0.30.3 debug logs for 5min as the RDP was extremely slow:
debug.zip

@rihards-simanovics commented on GitHub (Oct 28, 2024): here are the 0.30.3 debug logs for 5min as the RDP was extremely slow: [debug.zip](https://github.com/user-attachments/files/17544872/debug.zip)

saavagebueno commented

@Xeravax commented on GitHub (Oct 30, 2024):

While I don't have the debug logs with me. I can confirm the issue here, my remote server is currently on v0.30.2, I used .3 on my client device (Laptop) and my connection dropped so low that I coudn't even watch a video from Jellyfin. I was running with like, less then 1MB.

I downgraded the laptop to .2 and this fixed it, something might have broken in between versions or some version incompatibility.

@Xeravax commented on GitHub (Oct 30, 2024): While I don't have the debug logs with me. I can confirm the issue here, my **remote** server is currently on v0.30.2, I used .3 on my client device (Laptop) and my connection dropped so low that I coudn't even watch a video from Jellyfin. I was running with like, less then 1MB. I downgraded the laptop to .2 and this fixed it, something might have broken in between versions or some version incompatibility.

saavagebueno commented

@rihards-simanovics commented on GitHub (Oct 30, 2024):

I was running with like, less then 1MB.

Yes, seems to be specific to 0.30.3, after downgrading back to 0.30.2 RDP on both laptop and PC, the framerate is back to normal 30~35 fps.

@rihards-simanovics commented on GitHub (Oct 30, 2024): > I was running with like, less then 1MB. Yes, seems to be specific to 0.30.3, after downgrading back to 0.30.2 RDP on both laptop and PC, the framerate is back to normal 30~35 fps.

saavagebueno commented

@briemann commented on GitHub (Oct 30, 2024):

Seeing the same. Multiple reports of 0.30.3 users using RDP on windows 10/11 instances having issues. Downgrades to 0.30.2 confirmed as the fix.

@briemann commented on GitHub (Oct 30, 2024): Seeing the same. Multiple reports of 0.30.3 users using RDP on windows 10/11 instances having issues. Downgrades to 0.30.2 confirmed as the fix.

saavagebueno commented

@mlsmaycon commented on GitHub (Oct 30, 2024):

@briemann @Codixer can you please share your output from the command below when facing the issue?

netbird status -dA

It can be from the client. Please share the node where the connection is affected so we check its connection type.

@mlsmaycon commented on GitHub (Oct 30, 2024): @briemann @Codixer can you please share your output from the command below when facing the issue? ``` netbird status -dA ``` It can be from the client. Please share the node where the connection is affected so we check its connection type.

saavagebueno commented

@rihards-simanovics commented on GitHub (Oct 30, 2024):

@mlsmaycon I think at this point we can confidently say that 0.30.3 is the issue so perhaps a netbird debug for 5m -AS would be more relevant here so there is a more complete technical log?

@rihards-simanovics commented on GitHub (Oct 30, 2024): @mlsmaycon I think at this point we can confidently say that 0.30.3 is the issue so perhaps a `netbird debug for 5m -AS` would be more relevant here so there is a more complete technical log?

saavagebueno commented

@mlsmaycon commented on GitHub (Oct 30, 2024):

@rihards-simanovics, The debug command will help a lot as it contains logs and the status output, but we still need confirmation on which peer you are testing to confirm the connection type and versions.

Could you also share the operating system between the peers and the test you've done? Or was it an RDP connection among Windows nodes with no routing peer in between?

@mlsmaycon commented on GitHub (Oct 30, 2024): @rihards-simanovics, The debug command will help a lot as it contains logs and the status output, but we still need confirmation on which peer you are testing to confirm the connection type and versions. Could you also share the operating system between the peers and the test you've done? Or was it an RDP connection among Windows nodes with no routing peer in between?

saavagebueno commented

@Xeravax commented on GitHub (Oct 30, 2024):

@briemann @Codixer can you please share your output from the command below when facing the issue?
netbird status -dA
It can be from the client. Please share the node where the connection is affected so we check its connection type.

I'll be out of the house tomorrow, I'll be able to test it by then.

@Xeravax commented on GitHub (Oct 30, 2024): > @briemann @Codixer can you please share your output from the command below when facing the issue? > > ``` > netbird status -dA > ``` > > It can be from the client. Please share the node where the connection is affected so we check its connection type. I'll be out of the house tomorrow, I'll be able to test it by then.

saavagebueno commented

@roberthase commented on GitHub (Oct 31, 2024):

I would also like to confirm that after updating to 0.30.3 the RDP performance is very bad.

netbird controller selfhosted: version 0.30.3
Ubuntu routing-peers in ha: Version 0.30.3
Windows Clients: version 0.30.3

RDS-Server with Windows Server 2016

This does not impact all clients all the time.

@roberthase commented on GitHub (Oct 31, 2024): I would also like to confirm that after updating to 0.30.3 the RDP performance is very bad. netbird controller selfhosted: version 0.30.3 Ubuntu routing-peers in ha: Version 0.30.3 Windows Clients: version 0.30.3 RDS-Server with Windows Server 2016 This does not impact all clients all the time.

saavagebueno commented

@rihards-simanovics commented on GitHub (Oct 31, 2024):

The debug command will help a lot as it contains logs and the status output, but we still need confirmation on which peer you are testing to confirm the connection type and versions.

Hi @mlsmaycon, sure, sorry just thought you'd get the same from the bundled zip with debug.

Could you also share the operating system between the peers and the test you've done? Or was it an RDP connection among Windows nodes with no routing peer in between?

Sure, both Office PC and Laptop in my case are running a Business Win. 11.

Version 	23H2
Installed on	‎17/‎04/‎2023
OS build	22631.4391
Experience	Windows Feature Experience Pack 1000.22700.1047.0

The testing is the same as per my initial comment when opening the issue. Please See the steps under the To Reproduce. This testing was done on both local network and over internet.
With regards to connections: I've been doing remote work behind either NATed network i.e. cellular, or home network. There is no proxy of any sorts and the connection was not routed through any exit nodes. It was/is a direct connection from peer gws-rs-thinkpad.node.anon-RGEjv.domain to peer gws-rs-main-pc.node.anon-RGEjv.domain, again see the NetBird status -dA output for that one, I will update the comment with clearer labels for peers.

@rihards-simanovics commented on GitHub (Oct 31, 2024): > The debug command will help a lot as it contains logs and the status output, but we still need confirmation on which peer you are testing to confirm the connection type and versions. Hi @mlsmaycon, sure, sorry just thought you'd get the same from the bundled zip with debug. > Could you also share the operating system between the peers and the test you've done? Or was it an RDP connection among Windows nodes with no routing peer in between? Sure, both Office PC and Laptop in my case are running a Business Win. 11. ```Edition Windows 11 Pro Version 23H2 Installed on ‎17/‎04/‎2023 OS build 22631.4391 Experience Windows Feature Experience Pack 1000.22700.1047.0 ``` The testing is the same as per my initial comment when opening the issue. Please See the steps under the `To Reproduce`. This testing was done on both local network and over internet. With regards to connections: I've been doing remote work behind either NATed network i.e. cellular, or home network. There is no proxy of any sorts and the connection was not routed through any exit nodes. It was/is a direct connection from peer `gws-rs-thinkpad.node.anon-RGEjv.domain` to peer `gws-rs-main-pc.node.anon-RGEjv.domain`, again see the `NetBird status -dA output` for that one, I will update the comment with clearer labels for peers.

saavagebueno commented

@Xeravax commented on GitHub (Oct 31, 2024):

After reinstalling .3, it did not seem to replicate anymore. I am unable to reproduce the issue at this time. I will report back if it does happen again.

@Xeravax commented on GitHub (Oct 31, 2024): After reinstalling .3, it did not seem to replicate anymore. I am unable to reproduce the issue at this time. I will report back if it does happen again.

saavagebueno commented

@mlsmaycon commented on GitHub (Nov 1, 2024):

Hello folks, we found the issue that was causing slow speeds. Can you please test the 0.31.0 version?

@mlsmaycon commented on GitHub (Nov 1, 2024): Hello folks, we found the issue that was causing slow speeds. Can you please test the 0.31.0 version?

saavagebueno commented

@rihards-simanovics commented on GitHub (Nov 1, 2024):

Hello folks, we found the issue that was causing slow speeds. Can you please test the 0.31.0 version?

Thanks! Will test on Monday as I don't travel over the weekends.

@rihards-simanovics commented on GitHub (Nov 1, 2024): > Hello folks, we found the issue that was causing slow speeds. Can you please test the 0.31.0 version? Thanks! Will test on Monday as I don't travel over the weekends.

saavagebueno commented

@rihards-simanovics commented on GitHub (Nov 4, 2024):

can confirm, when using RDP along with version 0.31.0 does indeed fixes the issue with slow connection!

Thank you Netbrid Team!

@rihards-simanovics commented on GitHub (Nov 4, 2024): can confirm, when using RDP along with version 0.31.0 does indeed fixes the issue with slow connection! # Thank you Netbrid Team!

saavagebueno commented

@roberthase commented on GitHub (Nov 4, 2024):

Seems to be fixed, thanks for the quick update.

@roberthase commented on GitHub (Nov 4, 2024): Seems to be fixed, thanks for the quick update.

saavagebueno commented

@rihards-simanovics commented on GitHub (Nov 4, 2024):

@roberthase, @Codixer, @briemann, do any of you use web login (i.e. Microsoft Login) to authenticate? I have a wired issue where the "Securing Remote Session" takes for ever though after connecting the speed is fine. I never really measured but it usually is stuck on "Securing remote session" for a solid minute or two. I would open a new issue about this here, but I don't know if it's related to Netbird or just my setup, That said, on version 0.27.x it used to be fast, around a few seconds.

@rihards-simanovics commented on GitHub (Nov 4, 2024): @roberthase, @Codixer, @briemann, do any of you use web login (i.e. Microsoft Login) to authenticate? I have a wired issue where the "Securing Remote Session" takes for ever though after connecting the speed is fine. I never really measured but it usually is stuck on "Securing remote session" for a solid minute or two. I would open a new issue about this here, but I don't know if it's related to Netbird or just my setup, That said, on version 0.27.x it used to be fast, around a few seconds.

saavagebueno commented

@roberthase commented on GitHub (Nov 4, 2024):

this is something i experienced on my windows pc at home (self-registered with entra idp), but never on our work-laptops (setup-key), so i thought this related to some update/security setting on my device.

i can test this with another vpn client and report back.

@roberthase commented on GitHub (Nov 4, 2024): this is something i experienced on my windows pc at home (self-registered with entra idp), but never on our work-laptops (setup-key), so i thought this related to some update/security setting on my device. i can test this with another vpn client and report back.

saavagebueno commented

@Xeravax commented on GitHub (Nov 4, 2024):

@roberthase, @Codixer, @briemann, do any of you use web login (i.e. Microsoft Login) to authenticate? I have a wired issue where the "Securing Remote Session" takes for ever though after connecting the speed is fine. I never really measured but it usually is stuck on "Securing remote session" for a solid minute or two. I would open a new issue about this here, but I don't know if it's related to Netbird or just my setup, That said, on version 0.27.x it used to be fast, around a few seconds.

I experience this on my phones, it takes a solid minute for other devices to popup (Might be related to #2158) but not sure. Apart from that, most of my devices connect instantly. At most 10 seconds.

@Xeravax commented on GitHub (Nov 4, 2024): > @roberthase, @Codixer, @briemann, do any of you use web login (i.e. Microsoft Login) to authenticate? I have a wired issue where the "Securing Remote Session" takes for ever though after connecting the speed is fine. I never really measured but it usually is stuck on "Securing remote session" for a solid minute or two. I would open a new issue about this here, but I don't know if it's related to Netbird or just my setup, That said, on version 0.27.x it used to be fast, around a few seconds. I experience this on my phones, it takes a solid minute for other devices to popup (Might be related to #2158) but not sure. Apart from that, most of my devices connect instantly. At most 10 seconds.

saavagebueno commented

@roberthase commented on GitHub (Nov 4, 2024):

@rihards-simanovics

hi there, connecting to a remote session with forticlient was indeed quicker.
i ended up connecting to range of different systems and only one was taking longer on "securing remote session".

i cleared the rdp-cache, like mentioned on this website : https://tachytelic.net/2019/01/clear-rdp-cache/ , then rebooted a few times to test and "securing remote sessions" took only 3-5 seconds each time.

@roberthase commented on GitHub (Nov 4, 2024): @rihards-simanovics hi there, connecting to a remote session with forticlient was indeed quicker. i ended up connecting to range of different systems and only one was taking longer on "securing remote session". i cleared the rdp-cache, like mentioned on this website : https://tachytelic.net/2019/01/clear-rdp-cache/ , then rebooted a few times to test and "securing remote sessions" took only 3-5 seconds each time.

saavagebueno commented

@rihards-simanovics commented on GitHub (Nov 5, 2024):

Hey @roberthase thanks. Though I don't think this is the case here. I've been using node's hostname to RDP into it, in this case gws-rs-main-pc.node.anon-RGEjv.domain, but after I went back to its IP, "securing the connection" step in Windows RDP client got fast as expected. My assumption is the address resolution is somehow messing with the speed.

@rihards-simanovics commented on GitHub (Nov 5, 2024): Hey @roberthase thanks. Though I don't think this is the case here. I've been using node's hostname to RDP into it, in this case `gws-rs-main-pc.node.anon-RGEjv.domain`, but after I went back to its IP, "securing the connection" step in Windows RDP client got fast as expected. My assumption is the address resolution is somehow messing with the speed.

saavagebueno commented

@rihards-simanovics commented on GitHub (Nov 5, 2024):

I'm closing this issue as the issue appears to be resolved for me and others with v0.31.0.

@rihards-simanovics commented on GitHub (Nov 5, 2024): I'm closing this issue as the issue appears to be resolved for me and others with v0.31.0.

saavagebueno commented

@rihards-simanovics commented on GitHub (Nov 5, 2024):

I've been using node's hostname to RDP into it, in this case gws-rs-main-pc.node.anon-RGEjv.domain, but after I went back to its IP, the "securing the connection" step in the Windows RDP client got faster as expected. My assumption is the address resolution is somehow messing with the speed.

@mlsmaycon, do you have any idea what this could be?

If this has the potential to be a Netbird issue, I'd like to open an issue so it can be tracked.

Just to note that on my DNS server side, node.anon-RGEjv.domain has A and AAAA records pointing to the Netbird Management server IPs, and *.node.anon-RGEjv.domain wildecard are canonically linked to node.anon-RGEjv.domain via a CNAME record.

@rihards-simanovics commented on GitHub (Nov 5, 2024): > I've been using node's hostname to RDP into it, in this case gws-rs-main-pc.node.anon-RGEjv.domain, but after I went back to its IP, the "securing the connection" step in the Windows RDP client got faster as expected. My assumption is the address resolution is somehow messing with the speed. @mlsmaycon, do you have any idea what this could be? If this has the potential to be a Netbird issue, I'd like to open an issue so it can be tracked. Just to note that on my DNS server side, `node.anon-RGEjv.domain` has `A` and `AAAA` records pointing to the Netbird Management server IPs, and `*.node.anon-RGEjv.domain` wildecard are canonically linked to `node.anon-RGEjv.domain` via a CNAME record.

saavagebueno commented

@b00nish commented on GitHub (Sep 3, 2025):

I have a wired issue where the "Securing Remote Session" takes for ever though after connecting the speed is fine. I never really measured but it usually is stuck on "Securing remote session" for a solid minute or two.

@rihards-simanovics

Did you ever get to the bottom of this issue?

We see the same behaviour when computers/laptops with Netbird connect to our RDS server. The step "securing remote session" takes about 30 to 90 seconds but after this the connection works well.

It doesn't matter if we connect using the Netbird IP, the Netbird FQDN or the Hostname.

On the local network or using a VPN client that the firewall vendor provides, the same RDP connections happen instantly.

@b00nish commented on GitHub (Sep 3, 2025): > I have a wired issue where the "Securing Remote Session" takes for ever though after connecting the speed is fine. I never really measured but it usually is stuck on "Securing remote session" for a solid minute or two. @rihards-simanovics Did you ever get to the bottom of this issue? We see the same behaviour when computers/laptops with Netbird connect to our RDS server. The step "securing remote session" takes about 30 to 90 seconds but after this the connection works well. It doesn't matter if we connect using the Netbird IP, the Netbird FQDN or the Hostname. On the local network or using a VPN client that the firewall vendor provides, the same RDP connections happen instantly.

saavagebueno commented