RDP via L4-Gateway Route (Option A)

Alternative: Option B — RDP route with access mode gateway.

When to use

A good fit when you want to quickly tunnel an RDP endpoint from the internet through the Home Gateway into the LAN, without using the dedicated RDP feature (credential vault, resolution profiles, clipboard policy, etc.). Pure TCP forwarding — the user opens mstsc.exe and enters the public address + port.

Pros:

Works with any RDP client, regardless of OS.
Also works with other RDP-like protocols (XRDP, VNC over TCP, ThinLinc).

Cons:

No credential management in GateControl — the client has to enter username + password manually.
No resolution profiles, clipboard redirect policies, session timeouts, sharing, screenshot logging.
No Wake-on-LAN coupling to the RDP connect (only possible on the L4 route itself).
No health checks, tags, or user visibility.

If you need these convenience features → Option B.

Prerequisites

Home Gateway container is running in the home network and heartbeating
Pro license for L4 gateway routes
LAN device has RDP enabled (standard port 3389)

Setup

In the Admin UI: Routes → New route

Field	Value
Type	`L4`
Target type	`Home Gateway (LAN)`
Home Gateway	your gateway peer
LAN host	IP of the Windows machine on the LAN, e.g. `192.168.2.100`
LAN port	`3389`
L4 protocol	`TCP`
L4 listen port	`3389` — or an alternative if 3389 is already taken on the server (e.g. `13389`)
L4 TLS mode	`None`

Leave "Backend HTTPS" empty. Save. The route is active as soon as the gateway config sync has completed (~2 s).

Avoiding port conflicts

The server blocks some ports for the L4 listen port by default (22/53/80/443/2019/3000/51820). If your target port is one of them, you have to choose a different listen port externally. Often preferable anyway: rdp.example.com:13389 instead of default 3389 reduces brute-force noise in the logs.

Connecting from the client

Windows (Remote Desktop Connection):

Computer: rdp.example.com:3389

macOS (Microsoft Remote Desktop): host rdp.example.com:3389.

Linux (FreeRDP):

xfreerdp /v:rdp.example.com:3389 /u:Administrator

Android/iOS: Microsoft Remote Desktop app, host rdp.example.com:3389.

Data flow

RDP client ── TCP SYN ──▶ Server (VPS)
                             │
                             │ Caddy L4 plugin
                             │ forward → 10.8.0.8:3389 (WG tunnel)
                             ▼
                         Gateway container (home)
                             │
                             │ TcpProxyManager :3389
                             │ forward → 192.168.2.100:3389
                             ▼
                         Windows machine (RDP server)

Caddy's Layer-4 plugin performs pure TCP byte forwarding — the RDP handshake is not parsed. As a result, every TCP-based protocol passes through, not just RDP.

Attaching Wake-on-LAN to the route

Enable WoL on the L4 route. If the gateway receives ECONNREFUSED from the LAN target on connect, it fires a magic packet to the configured MAC. The RDP client usually retries the connection automatically — on the second attempt the machine is out of standby.

Requires: WoL enabled in BIOS + in the network adapter, gateway container in the same L2 segment as the target device.

Option A vs. Option B

Feature	Option A	Option B
Credential vault	✗	✓
Resolution profiles	✗	✓
Clipboard/drive/USB redirect policies	✗	✓
Audio mode	✗	✓
Network profile	✗	✓
NLA config	✗	✓
WoL on RDP connect event	✗	✓
Session timeout, admin session	✗	✓
Maintenance windows	✗	✓
Sharing modes, screenshot	✗	✓
Generated `.rdp` file	✗	✓
User/token visibility	✗	✓
Setup effort	Create 1 L4 route	Click through the wizard, L4 route is created automatically

Both do exactly the same thing on the network side — Option B creates the L4 route implicitly under the hood, but does not show it directly in the routes grid. Option A is more direct, Option B more convenient.

Troubleshooting

Client: "Connection refused"

Is the RDP service running? (PowerShell: Get-Service TermService)
Are remote connections enabled in the Windows system settings?
Firewall exception for port 3389 in Windows Defender Firewall

Client hangs at "Configuring remote session"

NLA mismatch. In the client tool under "Advanced" → disable CredSSP and try classic authentication. Option B solves this more cleanly because NLA can be set server-side.

Connection drops after a few seconds

MTU problem in the WG tunnel. The MTU/MSS clamp rules in the entrypoint.sh already address this; if dropouts still occur → set GC_WG_MTU=1280 in the .env.

I don't want to expose the default port 3389 externally

Set the L4 listen port to, for example, 13389. The LAN port stays 3389. The client then connects to rdp.example.com:13389.

RDP client access vs. MS RD-Gateway

Not to be confused:

Home Gateway (this project) — routes TCP byte streams into the LAN
Microsoft RD-Gateway (TSGateway) — Windows server role service that tunnels RDP over HTTPS. A standalone product. GateControl has separate fields for it on the RDP route (see Option B) in case an MS-RDG sits in front of your RDP server.