asked on

RDS Gateway server address unreachable....help!

I'm feeling a sense of deja vu (all over again...). I have a Remote Desktop Services issue. I have two office locations, one in Florida, one in New Jersey. The network setup in both locations is identical (New Jersey is an "image copy" of the Florida setup). RDS works fine when attempting to connect to the Florida location. RDS is not working for the New Jersey location. Attempting to connect to New Jersey returns the following message:

Both systems are set up the same with the exception of the Gateway domain. The RDS Gateway setup for each includes an SSL Certificate which, of course, is different for each location (2 different domains). Both systems are running Windows Server 2016. The only other difference are two similar but unique Sonicwall firewall devices. The DNS setup is identical in both locations, on purpose to supposedly make the RDS setup easier which obviously has failed. The RDS Gateway server address is correct, but is apparently "unreachable". I'm testing this from the New Jersey location primarily, but I can remote into the Florida location and attempt to connect to the NJ location from there. If I check off the "Bypass RD Gateway server for local addresses" box, the remote connection to the NJ server (from the NJ workstation) works great. For obvious reasons I don't want to check off that option.

I've worked with this type of setup for roughly 10 years now but I'm not an RDS expert by any means and only have to deal with this occasionally, so I'm hoping that someone who works on RDS connections using Gateway servers who is more knowledgeable than I am will know exactly what needs to be done based on the error message I'm receiving.

David Johnson, CD

do a tracert to the gateway dns name
so both from florida to new jersey and local to new jersey fail?
and on NJ the sonicwall is configured to forward port 80/443 from the wan to the gateway server ip address (lan)?
It is probably your external dns that needs fixing. the tracert should show it going to your public ip NJ

Philip Elder

When you say "mirror" do you mean that the VMs are a direct copy?

When we have separate sites we have separate RD Broker/Gateway/Web servers set up as a rule. We don't bother with any Session Hosts. That gives us a "back door" if something goes sideways with the main site's RD Gateway.

For the problematic gateway in IIS:
--> Default --> Pages --> RDWeb --> App Settings --> tsremotegateway (Loose based on memory)
Set that setting to the remote.domain.com url that is required for that site.
Restart IIS. NOTE: RD Gateway will _not_ restart on its own so make sure to have a connection to Site 1's management server and a Services.msc remote or PowerShell Remote back to Site 2's gateway.

Is there an on-site DC with ADDS/DNS/DHCP set up at Site 2 (Jersey)?

Jim Klocksin

ASKER

do a tracert to the gateway dns name
so both from florida to new jersey and local to new jersey fail?

The tracert from local to NJ fails, from FL to NJ it appears to work. I'm not familiar with what this command actually does, but from FL to NJ it takes about 25 hops and reaches my IP in NJ.

and on NJ the sonicwall is configured to forward port 80/443 from the wan to the gateway server ip address (lan)?

The Sonicwall setup is basically the same in both locations and ALLOWS port 443 to go through (best way I know of describing it) but does not specifically port forward any ports. The ports are built into the access rules on the Sonicwall. I don't do (and never have done) anything for port 80 in any of my sonicwall rules (applies to the sonicwall in FL as well).

Hope this sheds some more light, if not, please let me know what else I can provide.

David Johnson, CD

most firewalls default rule is to block all ip's/all type from wan to lan

you have to allow via a port forward rule port 443/80 to the ip of the gateway server AND on the gateway server allow incoming port 80/443 tcp

Jim Klocksin

ASKER

That is my current setup. All IP addresses are blocked except my 2 static IPs (FL and NJ) as well as my client's IP addresses (1.2.x.x - not their actual IP of course). Port 443 is allowed thru via access rules. As stated before, port 80 is not explicitly allowed but restricted internet (via Group Policy) is allowed so I'm assuming that http traffic can get thru. I've never explicitly set up access for port 80 and this set up has worked in the past, so I'm not sure why port 80 should be an issue. FL has the same setup so again not sure why port 80 matters.

David Johnson, CD

if you have setup to only use https then port 80 isn't needed. I just include it in case

Jim Klocksin

ASKER

Given that my NJ server is an image copy of the FL server (based on backup from 6/18/2022), and that the FL Gateway server is working as expected, the issue must be in my Sonicwall firewall? I've gone over all the settings I can think of on both servers and, as expected, they're identical. I had to overwrite the SSL certificate in the NJ server since the backup contained the Florida SSL Cert, but that's the only difference between the two servers. That said I don't see anything in the Sonicwall that should cause the issue but I'm not an expert on that either.

Jim Klocksin

ASKER

Still not working but, I added a firewall rule that appears to have affected something and added the SSL Certificate in a couple additional places, so I have made some changes. Difference is that now the tracert command works from both the local and the FL network and the RDP link is now working from the local and is going thru the Gateway (shows up on Gateway Manager monitor). That said, I'm still at a loss as to what else to do to get it working?

David Johnson, CD

Ok, refresh my memory what isn't working now?

Jim Klocksin

ASKER

Connecting from FL to NJ via RDP is not working. Also, I've been using the PSPING utility to ping the NJ IP and listening port (I'm using 4011, not 3389) which also does not work from FL attempting to connect to NJ network. Since the tracert works from FL, I'm assuming that the traffic is being routed normally, just not being processed correctly at the NJ end!? Again, connecting to the FL network from NJ is working fine, both Server OSs are an image copy of each other, but I can't connect to the NJ network from FL. I'm leaning in the direction of some type of TCP issue as opposed to any problem with the RDS setup, especially since it's working from my local workstation, via the Gateway server, to connect to the NJ server "remotely" (currently working from NJ, local workstation in NJ).

David Johnson, CD

Connecting from FL to NJ via RDP is not working. Also, I've been using the PSPING utility to ping the NJ IP and listening port (I'm using 4011, not 3389)

WTF you aren't using the RDP Gateway? DO NOT expose RDP to the internet. Security via obscurity is a fools game.
the gateway will do the port 3389 work behind the scene and the traffic will be via port 443

Jim Klocksin

ASKER

I realize that it doesn't matter which port I use for the listening port, 4011 is no more secure than 3389, don't really care about that, the Sonicwall is providing the security. PSPING fails with both port 4011 and 443, so again, I'm guessing that the TCP traffic is the culprit.

David Johnson, CD

you're really confusing me here.. USE the GATEWAY or at minimum RDWEB and not try and connect to the session broker.

You have the RDS Gateway.. USE it..

Jim Klocksin

ASKER

You're confusing me now. Why do you think that I'm not using the Gateway? That's exactly what I'm trying to do. The Gateway isn't working as noted in the error message in my original post. I've tried to be as clear as possible.

David Johnson, CD

when connecting from the WAN you do not use port 3389/4011 you connect to the gateway and let the gateway manage connecting to the session broker which connects to the hosts

i.e.
public internet
https://remote.example.com
or in your case
https://remote.nj.exmple.com
https://remote.fl.example.com

<<isp> <--> fortinet <--> gateway

so why changing the port to 4011?

Philip Elder

RD Gateway won't work with an alternate port. That messes with the HTTPS over RDP tunnel setup.

Leave things at the default.

RD Gateway is secure in and of itself based on the way it tunnels the connections.

As mentioned above, we have plenty of sites with an RD Gateway set up at each site for access with nary an issue.

There is no reason to take the RD Gateway setup out of spec.

Jim Klocksin

ASKER

I'm still looking for suggestions on this. If anyone has any thoughts that might help me diagnose this situation I'd be grateful. Honestly, what I don't need are "this is the way we do it" comments. I'm looking for suggestions for things I can try to, hopefully, figure out why this remote connectivity is working for my Florida network and not working for my New Jersey network.

David Johnson, CD

it could be DNS misconfiguration.
using a web browser can you connect to the rdp gateway?
NJ and FL ?

ASKER CERTIFIED SOLUTION

Jim Klocksin

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial