RD Gateway Connection Failures: Certificate, CAP, RAP and Transport Checks

Direct answer: If users can connect to a session host directly from inside the network but fail through RD Gateway, the fault is almost always in one of four layers, checked in this order:

1. The certificate the client sees on TCP 443 does not match the gateway name, or is not trusted.
2. The connection authorisation policy (RD CAP) does not admit this user, computer or authentication method. Gateway event 201.
3. The resource authorisation policy (RD RAP) does not include the host, in the form of the name the client asked for. Event 301.
4. The gateway admitted the user but could not reach the host. Event 304.

For slow or unstable sessions through the gateway, rather than refusals, the transport is one possibility to check: if UDP 3391 is blocked or mishandled, the session runs over HTTPS only, which may contribute. Network loss, latency and session-host load can look the same, so confirm which one applies before you change anything. The Gateway operational log tells you which layer it is in nearly every case. Read it before changing policies or certificates.

Why it matters

RD Gateway is the front door for remote desktop access from outside, and failures there look the same to users whatever the cause: "Remote Desktop can't connect to the remote computer". Administrators then change whatever they changed last time:

• re-importing a certificate;
• widening a policy to "any network resource";
• opening port 3389 on the firewall "just to test".

Each of those either hides the real fault or creates a new exposure.

This article is about the gateway path only, before a session reaches the session host. Licensing errors after the session is established are covered in the published licensing article. Session performance once connected is covered in the RDS optimisation article. Both are linked at the end.

How it works

The path a gateway connection takes

When a client is configured to use an RD Gateway, it does not connect to the session host directly:

1. TLS on TCP 443. The client opens HTTPS to the gateway's external name. The gateway presents its SSL certificate. The client checks the name and trust before sending credentials.
2. Authentication and RD CAP. The gateway authenticates the user and checks the RD CAP: who may connect, from which client computers (optional), and using which authentication method (password or smart card). Success is event 200; refusal is event 201.
3. RD RAP. The gateway checks whether this user may reach this resource. Success is event 300; refusal is 301.
4. Connection to the resource. The gateway connects to the session host on TCP 3389, or TCP and UDP 3389 for RDP. Success is 302; a policy pass that still could not connect is 304.
5. Transport. Alongside the HTTPS channel, the gateway can carry RDP over UDP on port 3391, which improves interactive performance over high-latency links.

Microsoft's NPS extension page states the rule plainly: users must meet the conditions in one RD CAP and one RD RAP. CAPs can live in a central NPS policy store. RAPs cannot; they are always processed on the gateway itself.

The certificate

Microsoft's RDS roles page says the certificate name must match the fully qualified domain name used to reach RD Gateway. That is the external DNS name, or the CNAME pointing at the public address. A released service needs a certificate from a trusted certification authority; self-signed certificates are for development and testing.

Microsoft's RDS certificate page lists requirements for an RDS server certificate:

• issued for Server Authentication (EKU 1.3.6.1.5.5.7.3.1);
• issued by a CA trusted by the servers and clients;
• issued with an exportable private key, so it can be deployed through Server Manager or Set-RDCertificate.

The RD Gateway role page recommends a publicly issued certificate. With a private CA, every client must be given the trust chain beforehand. That is a common reason a gateway works from managed laptops and fails from home PCs.

CAP and RAP logic

An RD CAP specifies:

• User group membership (required): a local or AD security group.
• Client computer group membership (optional): this is the computer the user connects from. Setting it excludes unmanaged devices.
• Supported authentication methods: password and/or smart card. The client must use one that the CAP allows.

An RD RAP specifies:

• User groups that may use the policy.
• The network resources they may reach. This is an AD security group of computers, an RD Gateway-managed computer group, or "any network resource".

The name the client requests matters here. Microsoft's archived event 301 guidance says:

• With an RD Gateway-managed computer group, the FQDN and the NetBIOS name are matched separately, so both must be added if users might type either.
• With an AD security group, both forms are supported automatically when the target is in the same domain as the gateway. For a target in another domain, users must use the FQDN.
• For a session host farm, the RAP must name the farm explicitly. Otherwise users cannot reach farm members.

This is the source of many "it works for this host but not that one" cases.

Central NPS

When CAPs are stored centrally, the gateway acts as a RADIUS client to an NPS server. That NPS server needs its own policies to authorise the request. Two consequences follow:

• NPS events matter. A CAP refusal may be explained only in the NPS Security log, as event 6273 (denied) or 6272 (granted), not in the gateway's own policy list.
• Timeouts matter with MFA. Microsoft's guidance for the Entra MFA NPS extension raises the RADIUS timeout on the gateway's remote RADIUS server group from the default 3 seconds to between 30 and 60 seconds. This gives time for the second factor. With the default, a user who takes longer to approve can fail; intermittent 201s have other causes too, so confirm with the NPS reason code before changing it.

Ports

Microsoft's RDS ports reference lists, for inbound traffic from internet clients to the gateway:

• TCP 443: HTTP, including RPC over HTTP, over SSL.
• UDP 3391: RDP over UDP.

Both ports are configurable in RD Gateway Manager. From the gateway inward it lists:

• Kerberos (TCP 88);
• RPC endpoint mapper (TCP 135);
• LDAP (TCP/UDP 389);
• DNS (TCP/UDP 53);
• NPS RADIUS (UDP 1812/1813) when NPS is used;
• RDP to the resources on TCP and UDP 3389;
• HTTP (TCP 80), LDAP or FTP (TCP 21) for certificate revocation list checks, depending on where the CRL is published.

Microsoft also notes that firewalls doing directional UDP analysis must be configured to allow UDP "send receive".

Read-only checks

None of these was run for this article.

Privileges and side effects:

• Reading the Gateway operational log and RD Gateway Manager policies needs local administrator rights on the gateway, or delegated rights.
• Reading NPS logs needs the same on the NPS server.
• Testing from a client needs no server rights.
• Nothing below changes configuration. Opening a policy's Properties is read-only until you select OK after editing.

1. Read the Gateway operational log for the user's attempt

On the gateway, the log is Applications and Services Logs > Microsoft > Windows > TerminalServices-Gateway > Operational.

# Read-only. Set the window around the user's attempt; run on every gateway in the farm.
$log   = 'Microsoft-Windows-TerminalServices-Gateway/Operational'
$start = Get-Date '<attempt-time>' | ForEach-Object { $_.AddMinutes(-10) }
$end   = $start.AddMinutes(20)
Get-WinEvent -ListLog $log | Select-Object LogName, IsEnabled, RecordCount, LogMode
Get-WinEvent -LogName $log -MaxEvents 1 -Oldest | Select-Object TimeCreated   # oldest retained
try {
  Get-WinEvent -FilterHashtable @{ LogName = $log; StartTime = $start; EndTime = $end;
      Id = 200,201,300,301,302,303,304,305,306,307,309 } -ErrorAction Stop |
    Select-Object TimeCreated, Id, Message | Format-List
} catch {
  if ($_.FullyQualifiedErrorId -like 'NoMatchingEventsFound*') { 'No matching events in window' }
  else { "QUERY FAILED: $($_.Exception.Message)" }
}

Find the attempt by time, user and client computer name. The last event in the sequence for that attempt tells you which layer stopped it.

No event for the attempt is inconclusive on its own. It points at TLS or the path to the gateway only when all of these hold: the query succeeded on every gateway node, the log is enabled, the oldest retained event is older than the attempt, and the attempt time is known. Then correlate with the client's error, the load balancer or proxy logs, and the certificate check in step 2.

2. Check what certificate the client actually sees

From an outside network, open https://<gateway-external-name>/ in a browser and inspect the certificate. A 401 or error page is normal; you only need the certificate. Note:

• the subject and subject alternative names;
• the issuer chain;
• the expiry date.

On the gateway, compare that with what RD Gateway Manager shows: Properties > SSL Certificate. On a deployment managed through Server Manager, Get-RDCertificate (run where the RDS management tools are installed) lists the certificate set for each role.

If the names differ, or the client sees a different certificate, something else is answering on 443:

• a load balancer;
• a reverse proxy;
• a second gateway in a farm with a different certificate.

Microsoft's high-availability page expects the same certificate on each farm member.

3. Check the RD CAP the user should match

In RD Gateway Manager, open Policies > Connection Authorization Policies. For each enabled policy, note:

• the user groups;
• any client computer group;
• the allowed authentication methods.

Then check the user's group membership. Two read-only views answer different questions:

# Direct membership only (the memberOf attribute); nested groups are not expanded.
Get-ADUser <samAccountName> -Properties MemberOf | Select-Object -ExpandProperty MemberOf

# The security groups in the account's token, including nested groups. Needs a global catalog.
Get-ADAccountAuthorizationGroup -Identity <samAccountName> | Select-Object Name, SID

Use the second for the CAP decision when nested groups are involved. If the CAP names a local group on the gateway rather than a domain group, check that group's members on the gateway itself. After any membership change, the user must sign in again (a fresh authentication) before the new group is in the token.

If the gateway uses a central NPS store, the local list is not the decision. Check the NPS server's network policies and its Security log for 6272 and 6273 at the time of the attempt.

4. Check the RD RAP against the exact name requested

From the 301 or 304 event, take the resource name the user asked for, exactly as logged. Then, in Policies > Resource Authorization Policies, confirm:

• the user's group is on the User Groups tab;
• the resource is in the policy's computer group, in the same form: FQDN versus short name, and the farm name for a session host farm;
• if the target is in another domain, the user is connecting by FQDN.

5. Test the resource leg from the gateway (for 304)

From the gateway itself:

Test-NetConnection <session-host-fqdn> -Port 3389
Resolve-DnsName <session-host-fqdn>

A 304 with a failed test here is not a policy problem. It is a name resolution or network problem between gateway and host, or on the host itself: the Remote Desktop service not listening or the host firewall blocking 3389. On the host, read-only checks are Get-NetTCPConnection -LocalPort 3389 -State Listen and Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | Select-Object DisplayName, Enabled, Profile.

6. Check the UDP transport (for slow sessions)

On the client, in a gateway session, the connection information bar shows whether UDP is in use. Microsoft does not document a single command for this on all client versions, so treat the client's display as the evidence.

On the gateway, confirm in RD Gateway Manager's server properties that the UDP transport is enabled (Microsoft's ports page says the UDP port is configured there), and that it is listening:

Get-NetUDPEndpoint -LocalPort 3391

Then confirm UDP 3391 is allowed inbound at every firewall and NAT in front of the gateway, including any directional UDP inspection.

Interpreting the results

Event IDs and messages above come from Microsoft's archived Windows Server 2008 R2 reference. Current versions log under the same source, but always read the message text on your server. Microsoft's archived parent and per-event pages are not perfectly consistent, and the event's own message is the authority.

Decision guidance

Each fix belongs in the layer the evidence points to. All policy and certificate changes on a gateway affect every user of it, so make them in a maintenance window, one at a time.

Certificate wrong or untrusted

• Change: issue or renew a certificate whose name matches the external FQDN, from a CA all clients trust. Import it through RD Gateway Manager, or for a managed deployment through Server Manager's deployment properties or Set-RDCertificate. In a farm, use the same certificate on every gateway.
• Verification: from outside, the browser shows the new certificate and chain. A test user's connection produces event 200.
• Rollback: keep the previous certificate (with private key) available until the new one is proven, and re-select it if needed.

The published IIS certificate renewal article covers checking the live endpoint after a change.

CAP refusal (201 or 305)

• Change: add the user to the group the CAP names, or correct the client-side authentication method. If the CAP itself is wrong, edit only that policy's requirement, or add a narrowly scoped CAP for the intended group.
• Do not replace the user group with "Domain Users" or remove the client computer group without a decision from whoever owns remote access policy.
• For intermittent MFA failures, first confirm the timeout: NPS 6273 reason codes and timings showing the request dropped while the user was still approving. Only then raise the RADIUS timeout on the gateway's server group as Microsoft documents, keeping the "seconds between requests when unavailable" value at or above the timeout, as the same page says.
• Verification: a fresh attempt logs 200, and NPS logs 6272 if central.
• Rollback: reverse the group or policy edit. Record the policy's previous settings (screenshots of each tab are enough) before editing.

RAP refusal (301)

• Change: add the resource to the RAP's computer group in the form users use, or both forms for a gateway-managed group. For farms, add a RAP naming the farm. Add the user's group to the RAP's user groups if missing.
• Do not switch to "Allow users to connect to any network resource" as a fix. That turns the gateway into a path to every host that answers on 3389.
• Verification: a fresh attempt logs 300 then 302.
• Rollback: remove the added entries.

Policies pass, connection fails (304)

The fix is between the gateway and the host:

• DNS on the gateway;
• the firewall between gateway and host on TCP/UDP 3389;
• the host's Remote Desktop setting;
• the user's right to sign in through Remote Desktop on that host. Microsoft's archived guidance calls it the right to log on locally; on current systems check "Allow log on through Remote Desktop Services" and the Remote Desktop Users group.

Change the specific blocking item, verify with Test-NetConnection from the gateway and a fresh attempt, and roll back by reversing that one change.

Slow sessions (UDP not in use)

UDP not in use is an observation, not a diagnosis. Before changing anything, rule out packet loss and latency on the client's path and load on the session host, either of which also makes sessions slow.

• Change: allow inbound UDP 3391 to the gateway at the perimeter and NAT, with return traffic permitted, and enable UDP transport on the gateway if it is off.
• Verification: the client's connection information shows UDP in use, and users confirm responsiveness.
• Rollback: remove the firewall rule; sessions continue over HTTPS only. Note that UDP improves interactive performance but is not required for the gateway to work.

What not to do

• Do not publish TCP 3389 to the internet to "test without the gateway". It bypasses every control the gateway enforces.
• Do not widen a RAP to any network resource, or a CAP to all users, to clear one user's error.
• Do not reimport certificates repeatedly without first checking which certificate the client actually receives; often it is a proxy's.
• Do not change NPS policies on a server used by VPN or Wi-Fi without checking which connection request and network policies those services rely on.
• Do not judge a gateway by an internal test. Internal RDP that bypasses the gateway proves nothing about the gateway path.

Limitations

• The event reference is archived. Microsoft's per-event documentation for RD Gateway is from the Windows Server 2008 R2 library. It is an archived reference: confirm the provider name, event ID and message text on your own server, because the descriptions are not maintained for current releases.
• Client behaviour varies. The Windows App, the classic Remote Desktop Connection client and third-party clients show transport and certificate information differently.
• Load balancers and proxies in front of the gateway can terminate TLS, alter source addresses or drop UDP. Their configuration is outside this article.
• Azure Virtual Desktop and Windows 365 use a different gateway service. This article does not apply to them.
• Untested. No procedure here was tested for this article.

Acceptance checklist

• [ ] The failing attempt found in the Gateway operational log by time, user and client name, or its absence recorded with the coverage checks (every node, log enabled, retention covers the attempt, query succeeded).
• [ ] Certificate seen from outside matches the external FQDN, chains to a trusted root on the affected clients and is in date; same certificate on every farm member.
• [ ] The CAP the user should match identified; effective (token) group membership, client computer group and authentication method confirmed; NPS 6272/6273 checked if central.
• [ ] RAP includes the user's group and the resource in the exact name form requested (and the farm name for farms).
• [ ] For 304: name resolution and TCP 3389 from the gateway to the host confirmed.
• [ ] For slow sessions: the cause established first (UDP not in use, network loss or latency, or host load). Only where the evidence shows UDP not in use and loss, latency and host load are ruled out: UDP 3391 listener and perimeter rules confirmed, and the client then shows UDP in use with the slowness gone.
• [ ] Each change recorded with its previous value, made one at a time, and verified with a fresh attempt.
• [ ] No 3389 published to the internet; no "any resource" RAP introduced.

References

All accessed 2 November 2026.

• Microsoft Learn, "Remote Desktop Services roles" (RD Gateway section: ports 443 and 3391, certificate name): https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-roles
• Microsoft Learn, "Set up the Remote Desktop Gateway role" (updated 24 June 2025): https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-gateway-role
• Microsoft Learn, "Use certificates in Remote Desktop Services" (updated 14 July 2025): https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-services-certificates
• Microsoft Learn, "Ports that are used by Remote Desktop Services": https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/ports-used-by-rds
• Microsoft Learn, "Add high availability to the RD Web and Gateway web front" (updated 3 July 2024): https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-rdweb-gateway-ha
• Microsoft Learn, "Integrate your Remote Desktop Gateway infrastructure using the NPS extension and Microsoft Entra ID" (updated 4 March 2025): https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-nps-extension-rdg
• Microsoft Learn (previous versions, Windows Server 2008 R2), "RD Gateway Server Connections" (event list): https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee891388(v=ws.10)
• Microsoft Learn (previous versions), "Event ID 201 — RD Gateway Server Connections": https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee891053(v=ws.10)
• Microsoft Learn (previous versions), "Event ID 301 — RD Gateway Server Connections": https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee890850(v=ws.10)

Related articles

• Remote Desktop Licensing Errors: Grace Period and CAL Mode
• How to optimise Windows Server and Remote Desktop on VMware
• Renew IIS TLS Certificates and Verify the Live Endpoint

• Firewall Rules Stopped After a Move? Check the Profile

• Before Restricting NTLM: Inventory Who Uses It and Why Kerberos Was Not Used

Learning notes

1. A gateway connection passes four gates in order: certificate, CAP, RAP, connection to the host. The last Gateway event for the attempt names the gate that stopped it.
2. CAP decides who may use the gateway; RAP decides which hosts. Both must be met, and RAPs are always evaluated on the gateway itself.
3. RAP matching depends on the name the user typed: FQDN and NetBIOS forms, other-domain targets and farm names are the usual traps.
4. With central NPS and MFA, a short RADIUS timeout can produce intermittent CAP failures; confirm with NPS reason codes and timings, then raise it as Microsoft documents (30–60 seconds).
5. Slow but working sessions are not a policy problem; UDP 3391 not in use is one possible contributor, alongside network loss, latency and host load. Never "test" by publishing 3389 directly.