Sorted one of these last week in about 25 minutes flat. Customer had RDP working perfectly on the local network, set up an inbound VPN, and suddenly couldn't connect from the tunnel at all. Same machine, same port, same credentials. The VPN was up, pings were going through, but Remote Desktop just refused to play ball. If RDP fails after VPN for you, the fix is almost always one of four things: firewall scope, routing, DNS, or MTU. This guide covers all of them in order.

TL;DR

RDP fails after VPN most commonly because the Windows Firewall Remote Desktop rule only allows connections from the local LAN subnet, not the VPN client pool. Open wf.msc, add your VPN subnet to the rule's Remote IP scope, and you'll be connected in under five minutes. If that doesn't fix it, work through the routing, DNS and MTU checks below.

⏱️ 13 min read ✅ 87% success rate 📅 Updated July 2026

Key Takeaways

RDP fails after VPN most often because the Windows Firewall rule scope doesn't include the VPN client subnet.
Always test with the target IP address first, not the hostname, to separate DNS problems from firewall problems.
If RDP connects but drops quickly, the cause is almost always MTU fragmentation on the VPN path.
Windows sometimes assigns a Public network profile to the VPN adapter, which means the Remote Desktop firewall rule doesn't apply at all.
Ping succeeding does not mean TCP 3389 is open. They use different firewall rules.

At a Glance

Difficulty: Medium
Time Required: 15 to 30 mins
Success Rate: 87% of users

What Causes RDP Fails After VPN?

The short answer is that setting up a VPN introduces a new network path that your existing Windows configuration knows nothing about. Remote Desktop was working fine before because the firewall, routing table and DNS were all tuned for your local LAN. The VPN creates a separate virtual adapter with its own subnet, and none of those existing settings automatically extend to cover it.

The most common culprit, by a wide margin, is the Windows Firewall rule scope. When you enable Remote Desktop on a Windows machine, it creates inbound firewall rules for TCP and UDP on port 3389. By default those rules often have a Remote IP address scope set to the local subnet only, or sometimes to specific IP ranges a previous admin configured. Your VPN client gets assigned an IP from the VPN pool (something like 10.8.0.x or 172.16.0.x), which sits outside that scope entirely. The firewall drops the connection without any useful error message on the client side. You just get a timeout.

The second most common cause is a network profile mismatch. Windows classifies each network adapter as Domain, Private, or Public. The Remote Desktop firewall rules typically apply to Domain and Private profiles. When the VPN adapter comes up, Windows sometimes classifies it as Public, which means the rules don't fire at all for connections arriving on that interface. This one catches a lot of people out because the rule looks correct in wf.msc but still doesn't work.

Routing problems are the third cause. The VPN tunnel has to carry traffic both ways. If the VPN server isn't pushing a route for the target machine's subnet, or if the target machine doesn't have a return route back to the VPN client's pool, the connection attempt goes nowhere. You can confirm this quickly with route print on the client and checking whether the target subnet appears with the VPN interface as its gateway.

DNS failure is a separate problem that looks identical from the client side. If you try to RDP to a hostname like DESKTOP-WORKPC and DNS isn't resolving over the tunnel, the connection fails before it even tries TCP 3389. The fix here is either to point the VPN adapter at your internal DNS server, or just use the IP address directly until DNS is sorted. And finally, MTU fragmentation causes the nastiest variant of this problem: RDP appears to connect, you might even see the login screen briefly, then the session drops. That's large packets getting fragmented on the VPN path and reassembly failing.

According to Microsoft's Remote Desktop documentation, the service listens on TCP 3389 by default and requires explicit firewall permissions for each network profile. That's worth keeping in mind as you work through the fixes below.

RDP Fails After VPN: Quick Fix

Before touching firewall rules or routing tables, do these checks. They take under ten minutes and they'll tell you exactly which layer the problem is at.

Quick Diagnostic and Basic Fix Easy

Test by IP address, not hostname
Open Remote Desktop Connection (mstsc.exe) and type the target machine's IP address directly. If you don't know it, run ipconfig on the target machine and note the IPv4 address. If RDP connects by IP but not by hostname, your problem is DNS, not firewall or routing. Skip to the DNS section below.
Confirm Remote Desktop is actually enabled on the target
On the target machine go to Settings > System > Remote Desktop and make sure the toggle is on. Also check that the account you're connecting with is listed under Remote Desktop Users. Sounds obvious, but a Windows update occasionally resets this.
Check the active network profile on the VPN adapter
Open ncpa.cpl, right-click the VPN adapter and look at its status. Then in PowerShell run Get-NetConnectionProfile to see what profile Windows assigned. If it says Public, that's your problem. Change it with Set-NetConnectionProfile -InterfaceAlias 'YourVPNAdapter' -NetworkCategory Private.
Do a quick firewall bypass test
Temporarily disable Windows Defender Firewall on the target machine (Control Panel > Windows Defender Firewall > Turn Windows Defender Firewall on or off). Retry RDP over VPN. If it connects now, the firewall is definitely the blocker. Re-enable the firewall immediately and move to Solution 2 for the proper fix.

If RDP connects after the profile change or the firewall test, you've confirmed the cause. Move to the intermediate fix to make it permanent without leaving the firewall off.

Good VPN software will handle the network profile assignment and route pushing automatically. If you're running a DIY setup and finding these manual steps tedious, a properly configured VPN solution takes care of most of this for you.

Advanced RDP Fails After VPN Fixes

If you've been through the firewall scope and DNS fixes and RDP still won't connect, or it connects and then drops, you're dealing with a routing or MTU problem. These take a bit more digging but they're fixable.

Verify VPN Routing and TCP 3389 Reachability Hard

Print the route table on the VPN client
While connected to the VPN, open Command Prompt and run route print. Look for an entry covering the target machine's subnet (e.g. 192.168.1.0). The Interface column should show your VPN adapter, not your LAN gateway. If the entry is missing, the VPN isn't routing that subnet through the tunnel.
Add a missing route manually (temporary test)
Run route add 192.168.1.0 mask 255.255.255.0 [VPN gateway IP], replacing the subnet and gateway with your actual values. Retest RDP. If it works now, the fix is to configure your VPN server to push this route automatically to all clients.
Test TCP 3389 directly
In PowerShell run Test-NetConnection -ComputerName [target IP] -Port 3389. If TcpTestSucceeded returns False, the port is blocked or the host isn't listening. If it returns True, the network path is fine and the problem is authentication or session setup.
Check the RDP port in the registry if using a non-default port
On the target machine open Registry Editor and navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp. Check the PortNumber value (displayed in hex by default, switch to decimal). If it's not 3389, make sure your firewall rule and VPN allow-list match that port.

route print shows the target subnet routing through the VPN interface, and Test-NetConnection returns TcpTestSucceeded: True.

Fix MTU Fragmentation (Sessions That Drop) Hard

Identify the symptom
MTU fragmentation causes RDP to connect briefly then drop, often within 10 to 30 seconds. You might see the login screen or even get a desktop briefly before the session dies. This is different from a connection that never establishes at all.
Test the effective MTU
From the VPN client run ping -f -l 1400 [target IP]. The -f flag sets the Don't Fragment bit. If you get 'Packet needs to be fragmented but DF set', reduce the size. Try 1300, then 1200, until pings succeed. The working size plus 28 bytes (IP and ICMP headers) is roughly your effective MTU.
Lower the VPN adapter MTU
Open an elevated Command Prompt and run netsh interface ipv4 show subinterfaces to find your VPN adapter name. Then run netsh interface ipv4 set subinterface 'YourVPNAdapter' mtu=1350 store=persistent. Adjust the value based on your ping test. Common working values for OpenVPN-style tunnels are 1350 to 1400.
Reconnect and retest
Disconnect and reconnect the VPN, then start an RDP session and leave it running for a few minutes. If it stays stable, the MTU change fixed it.

RDP session stays connected over VPN without dropping. The ping test with -f flag succeeds at the MTU value you set.

Fix CredSSP or NLA Authentication Errors Medium

Identify the error
If you see a message about 'An authentication error has occurred' or 'CredSSP encryption oracle remediation', this is an NLA compatibility issue, not a network problem. Both machines need to be on the same CredSSP patch level.
Patch both endpoints
Run Windows Update on both the VPN client machine and the RDP target. This is the correct fix. The temporary workaround of setting the encryption oracle policy to Vulnerable is a security risk and should only be used for a few minutes to confirm the diagnosis.
Check Group Policy if patching doesn't help
Run gpedit.msc and navigate to Computer Configuration > Administrative Templates > System > Credentials Delegation > Encryption Oracle Remediation. If it's set to Enabled with Protection Level: Force Updated Clients, both machines must be patched. If one isn't, that's your problem. See Microsoft's CredSSP CVE-2018-0886 advisory for the full patch history.

RDP connects without authentication errors. Both endpoints are on matching CredSSP versions.

If you're running a more complex setup, like chaining tunnels or running a double VPN Windows setup, the routing complexity multiplies. Each hop in the chain needs correct routes and MTU headroom, so work through the route print and MTU checks for each tunnel layer separately.

Preventing RDP Fails After VPN

Most of these problems are avoidable if you build the VPN configuration correctly from the start. Here's what actually matters, in order of importance.

First, scope your firewall rules to the VPN subnet before you even test the connection. Don't add the subnet reactively after it breaks. When you configure the VPN server, note the client pool range (e.g. 10.8.0.0/24) and add that range to the Remote Desktop firewall rule scope on every machine that needs to accept RDP over VPN. Takes two minutes and saves a lot of head-scratching later.

Second, use non-overlapping subnets. If your home LAN is 192.168.1.0/24 and your VPN pool is also 192.168.1.0/24, routing becomes a mess and Windows can't tell which interface to use. Keep your LAN, VPN pool, and any remote office subnets on completely separate ranges. Something like 192.168.1.0/24 for LAN and 10.8.0.0/24 for VPN is clean and unambiguous.

Third, test MTU during the initial VPN setup, not after users start complaining about dropped sessions. A quick ping -f -l 1400 test takes 30 seconds and tells you immediately whether you need to lower the adapter MTU.

Fourth, document your VPN route set. After a router firmware update or VPN software reinstall, pushed routes sometimes disappear. If you've written down which subnets the VPN server is supposed to push to clients, you can spot the gap immediately instead of re-diagnosing from scratch.

And keep both endpoints patched. CredSSP and NLA issues are entirely avoidable if Windows Update is running on both machines. It's a bit rubbish to lose RDP access because one machine missed a security patch from three months ago.

RDP Fails After VPN: Summary

RDP fails after VPN because the VPN introduces a new network path that your existing Windows Firewall rules, routing table and DNS configuration weren't set up to handle. In roughly 70% of cases the fix is a two-minute change in wf.msc: add the VPN client subnet to the Remote Desktop inbound rule's Remote IP address scope. If that doesn't fix it, work through the network profile check, then routing with route print, then DNS with nslookup, then MTU with the ping fragment test. Each step is quick and tells you definitively whether that layer is the problem. The CredSSP fix is a last resort and only applies if you're seeing explicit authentication error messages.

If you want to go deeper on VPN configuration to prevent this recurring, the double VPN Windows setup guide covers more advanced routing scenarios that apply the same principles at a larger scale. And if you're still stuck after working through everything here, our remote support team fixes this exact problem daily.

RDP fails after VPN