Why is it that some windows 11 Computers will not respond to RDP requests coming from another subnet

Hello,

If your Windows 11 computer won't respond to RDP requests from another subnet, it could be a network issue.

First, you need to confirm whether Windows Defender Firewall or other firewalls allow RDP (Remote Desktop Protocol) traffic to pass through. You can check the firewall settings and make sure TCP port 3389 is open. Second, make sure that the routing between the different subnets is configured correctly. A router or intermediate device needs to be properly configured to be able to pass traffic from one subnet to another. Then you need to check if the network configuration of your Windows 11 computer, including the IP address, subnet mask, default gateway settings is correct.

So, here are some actions you can try:

1. Open Control Panel and select System & Security -> Windows Defender Firewall. In the left-hand menu, select Allow apps or features to pass through Windows Defender Firewall. Confirm that Remote Desktop is in the list and that it is checked under the network configuration you are using, such as private and public.

2. Make sure that the VPN is properly configured and that it is able to successfully connect to the destination network. Test the basic network connection to make sure that the IP address of the target computer can be pinged after the VPN connection.

3. Check that the routing between the VPN client and the remote computer is configured correctly, and that both the VPN server and the remote computer are able to communicate with each other. If you want, you can add the appropriate routing rules on the VPN server or router.
4. Check if the user account used to log in to Remote Desktop has remote access. You can add users to the Remote Desktop Users group. Press Win+R to open the "Run" dialog box, enter "sysdm.cpl" and press Enter. In the Remote tab, click Select User..., and then add the appropriate user.

I hope this information helps.

Best regards,

Karlie Weng

Thank you for the response, but I can't help but feel that some of the information I provided in the original post was ignored based on your suggestions.

You responded stating this could be a network issue. Well yes, but I let you know that I have 2 PCs on the same subnet, same network, behind the same equipment, and that one can connect, and one cannot. The fact that one of the 2 can connect should eliminate networking issues. You also suggest that I ping the target when in the original post I did state that I can ping AND browse the administrative share on both targets over the VPN.

I did not specifically get into the settings needed in general for RDP but since it works on one I thought it would be assumed that I had set up remote access correctly (I have compared settings on both)

Additionally, I provided packet captures that clearly show I can RDP to this machine on the same LAN (again proving that RDP is set up correctly) If you would be so kind as to look back at the post you can see in those captures the following

When the client tries to remote into the host computer when on the same LAN you can see a syn packet originating from the client computer that is answered by a SynAck packet from the host

This Packet Capture is being performed on the host itself.

When the client tries to connect over the VPN (from a separate LAN) You can see that the host receives the syn packet from the client PC, but the host just does not respond and it is followed by the client resubmitting the Syn request.

Since this packet capture is being done on the nic of the host I am trying to remote in on, there is no further networking. The host is simply not responding

Now if I create a rule in my firewall to set the source IP of the client on the VPN to look like it is coming from the Same LAN the system then responds and RDP is established.

This should irrefutably prove that what is happening here is that when an RDP request is received from any LAN other than the LAN that the machine itself is on. the machine simply does not respond to the request. If this is the case this needs to be a setting inside the Windows 11 machine itself that is preventing it from responding.

My workaround will work and that is good because my team has seen this randomly pop up on a handful of newer Windows 11 PCs with no rhyme or reason (meaning different models NICS and drivers), but this does not address what is actually happening here, its just a workaround that creates unneeded border firewall rules. if MS could tell me what in windows is doing this those rules would be unneeded

Also, Windows firewall is fully disabled for all networks during the troubleshooting and allow rules for 3389 TCP and UDP have been made for Private Public and Domain networks in the windows firewall on the problematic PC.

The suggestions above are too general, can be found in many other articles, and do not address what I have painted out in the original post.

I hope someone can take the information above and shed some light on what specific windows 11 settings would cause this type of behavior so we can find a fix.

Thank you.

Were you able to find anything more on this? It began taking place for me recently with a machine that I remote to.

Previously I had machines networked via ZeroTier, and an off-site Windows machine (connected to the ZT network) could not be connected to via RDP.

Then I tried setting up a Site-to-Site VPN from my home network (Unifi-based) to the remote network. Communication was fine via other protocols to other machines, but still couldn't connect to the Windows machine via RDP.

Next I tried setting up Wireguard on my Unifi gateway, with the remote Windows machine connecting directly in via the VPN.

Windows Firewall settings on the destination machine have RDP open, no source IP filtering.

Original setup:

192.168.10.0/24 - Network at Site A

192.168.192.0/24 - ZeroTier Network - Windows machine I need to connect to via RDP was connected to this

I had some routing taking place to allow the two networks to communicate with one another. All other connectivity was fine, but connections from 192.168.10.0/24 to the Windows machine on the 192.168.192.0/24 network via RDP stopped working.

A machine connected directly to the ZeroTier network on 192.168.192.0/24 was able to RDP over, lending support to the subnet being an issue.

Very simplified summary of current setup, several iterations were between the previous and this:

192.168.10.0/24 - Network at Site A

192.168.200.0/24 - Wireguard Network

Windows machine is now sitting in the 192.168.200.0/24 network (via Wireguard connection), along with a few others.

I can not connect via RDP to the windows machine from the 192.168.10.0/24 network.

I can connect to the windows machine from another machine in the wireguard 192.168.200.0/24 network.

Something has changed directly on the Windows machine to disallow these connections. I've disabled the firewall altogether, have tried multiple network configurations, have eliminated my own network as a potential issue as I've tested things from other networks.... whatever is different is on the destination Windows machine itself.

Someone, please help!

Unfortunately, and par for course for MS, this new behavior is not being addressed in any meaningful way I can find. People are throwing a lot of basic blanket RDP troubleshooting steps at it that focus primarily on the network and firewall without addressing what is happening on my original post.

The workaround I have in place does allow for RDP to work again on the affected machine. Sadly I can't find any known settings or events that lead me to resolve the actual behavior. As I mentioned before I have 2 Win 11 PCs same build one responds to RDP and works fine the other does not and all relevant RDP settings are the same on both. Not sure exactly what your firewall looks like but in your situation the rule might look as follows

Create a new firewall policy on the firewall that the destination PC is sitting behind, and give the destination computer an IP reservation on its network. Lets say 192.168.200.187. then the rule is basically

Any Traffic From: 192.168.10.0/24 to 192.168.200.187 on port 3389 allow and Set source IP to the Default Gateway of the firewall. On mine the last part looks like this and is under advanced settings in the firewall

Obviously replace the source with the DG of the 200 networks.

this seems to trick the destination computer into responding and dynamic NAT seems to take care of the rest, but I have only tested on Watchguard firewalls.
Hopefully this will help you until someone else smarter than me, and probably not MS support, finds out what is actually causing the destination system to only respond to RDP requests on the LAN it lives on.

Thanks - ended up doing something similar on this side. I also have used RDP through SSH tunneling to another machine on the same subnet with success.

No idea what changed, but I have another machine now showing the same symptoms on another network.

For anyone else that stumbles across this thread -

* Windows machines, for RDP specifically, appear to only want to accept / establish connections with IP addresses on a subnet the machine is directly connected to.

* The issue does not appear to be related to configuration of the underlying network.

* The same machine that won't accept an RDP connection from a remote network will happily accept connections from the same remote machine over other protocols - I've tested some quick examples of listening on a TCP port, connecting to that port, etc. -- all appear to work fine.

* Disabling Windows Firewall did not fix the issue.

Was this something that was broken in error?

Was this a well-intentioned change to RDP, to prevent remote hacking / connections for people that happen to have RDP accessible from the Internet and not via a secure network?

I don't have the answers - but I don't want anyone else to have to waste hours of time troubleshooting this issue as we have done.