Has anyone come across an issue where an external Remote Desktop Connection (or RemoteApp) fails via RD Gateway when “Bypass RD Gateway server for local addresses” is enabled, even though the expected server is not resolvable or routable internally?
From troubleshooting, this seems to be limited to a domain-joined machine, but only when it’s connected to the internal network (including VPN, albeit split-tunnel VPN). Trying externally with VPN disconnected works. With VPN connected, it fails, even though the split-tunnel config means that the connection attempt should not touch VPN, except for DNS resolution. Excluding the device and user from all GPOs does not help.
Unticking “Bypass RD Gateway server for local addresses” (forcing RD Gateway) works.
An Azure/Entra device (not Hybrid-joined) on the same internal network, same domain user, same VPN when external, same DNS, works no problem.
We do not have access to the external servers/service to troubleshoot server-side, and other clients of the host are supposedly not having this issue.
Testing with another service that uses RD Gateway gives the same results, and works with the same workaround - Get the initial authentication prompt for the Gateway, and then it fails to connect to the expected server (“An internal error occurred” 0x4)
Using procmon, it shows connections to the RD Gateway, then a single attempt to a random private IP, which I assume is the expected server. I assume this should not be visible when routing via the Gateway, as it is not visible in procmon when it works.
Assuming some things here since I’m having a hard time understanding your post on your different test scenarios.
How are you doing split-tunnel?
If you are using Dynamic client routing trying to route *.mydomain.com over the vpn tunnel. This worked for me so long as I didn’t have a hostname that was in public DNS and internal DNS. Of course the RD GW is for both internal and public DNS. Connection attempts would go back and forth from the internal IP address and the public IP address of the GW. Tested with the bypass enabled and disabled. It would work sporadically.
I changed to only send traffic going to these destinations and listed out the internal networks I wanted vpn to be used for. Since changing to this, no issues at all.
Seems like you need to look into how you have your split-tunnel set up. HTH
A few things to consider:
-
In all situations where the connection FAILS, what happens when you ping the RD Gateway server by name or IP?
-
In all situations where the connection WORKS, what happens when you ping the RD Gateway server by name or IP?
I believe above results can shed a light on the cause of the problem.
Depending on how tied you are to the current solution, if you prefer a zero trust RDP solution with no need for VPN and all the split-tunneling headaches and zero firewall exposure, you may want to take a look at TruGrid SecureRDP. It does RDS farm without any of the complexities of RDS roles and also includes RemoteApp. It also supports AD, Entra ID, and Hybrid AD / Entra ID.
Thanks for the response. Apologies for the confusing description.
This issue isn’t limited to VPN, but to answer your question re split tunnel config - We’re using Always On VPN via Microsoft RRAS, config deployed via Intune. The tunnel routing is an explicit list of IP ranges, primarily the internal network ranges and other things that ‘have’ to route back via HQ, none of which include the problematic RD GW.
The RD GW in question is hosted by a 3rd party. Users login via the web front end, download the appropriate RDP that is pre-configured for the expected RemoteApp, including the expected RD GW bits. However, trying to connect when on our internal network from a domain-joined machine (doesn’t happen with a non-domain machine), RDC seems to ignore the RD GW, which I assume is because it thinks it can route to the remote server without the GW, which in turn makes no sense because it can’t, leading to our confusion/frustration :-/
The RD GW consistently works, pings fine, resolves to the same public IP. Access to it has been whitelisted, bypassing any SSL inspection web filtering etc. When the connection fails is when RDC decides to bypass the RD GW, but we can’t figure out why it does so given that the Broker is not available without it.
Thanks for the tip re TruGrid, but this isn’t our solution, it’s a 3rd party.
On your computer in the office what does tracert show you for a route to connection broker and gateway?
What does DNS show you for the connection broker and the gateway?
GW: Resolves as expected to the public IP of the 3rd party. Tracert as expected.
CB: No DNS, and therefore no tracert.
Removing the “Bypass Gateway for local addresses” option forces it to work, but leaving it on for some reason continues to fail, despite the CB not resolving to anything.
That is very strange that you would need to go into the advanced and uncheck the bypass gateway for local addresses since you are resolving to the public IP
Indeed! Really scratching our heads on this one.
Where VPN comes in, is that when working remote we get the same while VPN is connected (even though tracert takes you out of your own internet due to split tunnel and DNS resolves the same). Disconnecting VPN helps it work. You’d think it might be something weird with domain/internal DNS or something, but other devices using the same DNS are fine. Maybe GPO? Can’t find anything obvious, and exclusions haven’t helped 
The only similar situation I’ve found online is a bit dated and the fix suggests issue with LmCompatibility, but ours are all good as far as I can tell.
I’m not sure how you have structured your AD but assume you have a test OU that is blocked by any GPO being applied?
If you do, get a computer and join to the domain, move to that blocked OU where no GPOs are. Also create a test user and move to OU where all GPOs are blocked. From there see if it works as you would expect. If it does start adding in a GPO to the computer one at a time. If all works, then start adding in user GPOs (though would think it would computer GPO causing the issue vs user).
When you figure out the resolution, post up here so I can learn something.
