Help fixing annoying issue with RD Gateway and internal vs external connection policies

Forums › Microsoft Windows › Help fixing annoying issue with RD Gateway and internal vs external connection policies

pomtom44

128 posts

Master Geek

#295780 22-Apr-2022 16:18

Hi all

As usual I have posted in multiple places, but seeing as you guys managed to help solve a interesting bug I had with exchange a while ago, im back again hoping someone can help

At work we use HP Thin Clients, and a RDS cluster with RD Gateway

Previously we had two profiles for our thin clients, one set to connect to the cluster directly (for internal machines) and one set to use the gateway (for external machines)
It wasn't an issue as we didnt have many machines moving between office and home, and when we did, we just pushed the changed profile to it
As a security step, we have a policy on our gateway which only allows certain users to connect remotely

However because of all the lockdowns over the past 2 years, we changed to all our machines having the gateway enabled, and just using a local DNS to point the domain to the gateway internally
(so doesnt matter if your external or internal, you use the domain name to connect)

We set everyone to have remote access, just to make it a little easier on us, rather than having to enable and disable people as they worked from home, either lockdown, or isoloations

We had a incident the other day where a user didnt have remote access enabled (as they were a new starter and didnt have any work from home equipment yet)
but they were unable to log in
I had a look and because we were still using the gateway, they were hitting our policy for remote access
The fix was either to change their machine to not use the gateway, or to enable them for remote access

we fixed it, but now want to try solve the problem so we can go back to enabling and disabling remote access based on the gateway settings

The quick fix would be to either have "bypass gateway for local connections" which windows based RDP clients have, but I cant find this on our thin client settings
(I have asked HP but no reply as of yet)
The other fix is to have IP filtering on our policies, so our internal IP range doesnt hit the policy, but that doesnt seem to be a option in the gateway settings

Does anyone know of a way we can have local machines bypass the gateway policies, without having to go back to having two thin client profiles?

Thanks in advance :)

fearandloathing

503 posts

Ultimate Geek

ID Verified

Lifetime subscriber

#2905485 22-Apr-2022 21:18

Quite often we architect our environments without taking into account how applications are architected to run. We implement them based on our security architecture, which the application architecture doesn't know about or work properly with.

My expectation is the setting 'Bypass RD Gateway server for local addresses' is simple as when the client connects to the farm, the client will try to connect to the session host directly, if it can't connect to the session host directly it will use the gateway instead.

This is almost certainly a name resolution issue and or a certificate issue.

So make sure your DNS is working correctly. make sure you use FQDN's throughout your farm and network. Don't use NetBIOS names, don't use IP's. Don't use non-internet routable domains, e.g. internal.local (Even if the farm is not publically routable) Place your clients in the same DNS zone, when using internally, if you want to bypass the Gateway.

i.e From a terminal 'terminal1.corp.example.co.nz' when your ping 'sessionhost' ping will resolve to 'sessionhost.corp.example.co.nz' and the correct internal IP address. With 'sessionhost.corp.example.co.nz' being the correct internal hostname for that session host, and the correct FQDN in Windows sysdm.cpl on the server.

Understand the following about the certificate on the farm.

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn781533(v=ws.11)#certificate-contents

I would recommend:

Assuming your farm is called rds.corp.example.co.nz

Your certificate should be as follows

CN=rds.corp.example.co.nz

DNS=rds.corp.example.co.nz

DNS=*.corp.example.co.nz

*.corp.example.co.nz

should cover your session hosts

sessionhost.corp.example.co.nz

sessionhost1.corp.example.co.nz

sessionhost2.corp.example.co.nz

This not being true may prevent your clients from failing 'Bypass RD Gateway server for local addresses' I'm not sure, to be honest.

If you have a mix of FQDNs like:

rds.corp.example.co.nz

sessionhost1.internal.local

If the certificate doesn't cover all the session host FQDNs.

Things won't work properly, it will work but not properly.

pomtom44

128 posts

Master Geek

#2905488 22-Apr-2022 21:33

The problem from what I can see is the thin clients we use (HP linux based) are forcing the gateway to be used
there is no "Bypass for local" option
"Bypass RD Gateway server for local addresses" works as expected if we are connecting from a windows based machine

I dont think its DNS as you have pointed out, the FQDN is the same externally as internally (Internal uses internal dns and points to the local IP where external points to our public IP)
And the cert as you say is using wildcard all the way though