RDP Gateway Firewall and Network Requirements
This page describes the network flows introduced or changed by RDP gateway mode. For direct RDP proxy network requirements, see RDP Proxy Technical Notes.
Traffic Summary
| Hop | Protocol | Direction |
|---|---|---|
| Client to gateway (Secret Server or distributed engine) | HTTPS | Inbound to Secret Server or DE |
| Gateway to target host | RDP / TCP | Outbound from Secret Server or DE |
| Client to direct RDP proxy (legacy) | RDP over TLS | Inbound to Secret Server or DE |
Gateway mode is additive. Enabling it does not disable the direct RDP proxy listener. To permit only gateway traffic, close the direct-proxy port at the firewall after verifying gateway sessions work.
Load Balancers and Reverse Proxies
The gateway listener accepts RDP over HTTPS. Most commercial load balancers can pass this traffic through to Secret Server or a distributed engine.
- Layer 4 (TCP) passthrough: Supported without caveats.
- Layer 7 with SSL re-encryption: Supported if the load balancer correctly forwards RPC-style HTTP methods and does not buffer streamed responses.
- Layer 7 with SSL termination at the load balancer: Supported if the load balancer presents the gateway certificate and Secret Server or the engine trusts the re-encrypted hop. In this topology the certificate lives on the load balancer, not in Secret Server.
Delinea recommends Layer 4 pass-through for initial deployments because it eliminates several failure modes that depend on Layer 7 configuration.
DNS and Hostname
The hostname clients use to reach the gateway must match the subject alternative name on the certificate presented by the gateway. Typical deployments use one hostname per site with DNS round-robin across engines in that site.
SSL Inspection for Firewalls and Proxies
Because client-to-gateway traffic is carried over HTTPS rather than as native RDP, any middle-box on the client-to-gateway path that performs SSL decryption and re-signs the TLS certificate with its own CA will break gateway sessions. The client sees the re-signed certificate instead of the one Secret Server presents. mstsc.exe either rejects the connection when the middle-box CA is not trusted or accepts a different certificate than the one Secret Server serves, and the session fails with a certificate or authentication error.
Options to resolve:
- Bypass SSL inspection for the gateway hostname on the middle-box. This is the recommended approach.
- If SSL inspection cannot be bypassed, ensure the middle-box's CA is installed in the client's trusted root-certification authorities store so the re-signed certificate is accepted. Note that this means clients no longer verify the actual Secret Server gateway certificate—the security posture depends entirely on the middle-box.
Direct RDP proxy is unaffected because its traffic is native RDP, which SSL-inspecting firewalls do not decrypt.
Client Requirements
The client must use an RDP client that implements the Remote Desktop gateway protocol. Delinea validates gateway mode against the Microsoft Remote Desktop connection client on currently supported Windows releases. Other compliant clients may work but are not part of Delinea's validated configuration.
Egress from Secret Server or Distributed Engine to Target Hosts
Unchanged from direct RDP proxy. When a gateway session arrives, Secret Server or the distributed engine initiates an outbound RDP/TCP connection to the target host advertised for the secret. Existing firewall rules for outbound RDP apply.
