RDP über L4-Gateway-Route (Option A)

Alternative: Option B — RDP-Route mit Access-Mode gateway.

Wann nutzen?

Passt wenn du schnell einen RDP-Endpunkt vom Internet durch den Home-Gateway ins LAN tunneln willst, ohne das dedizierte RDP- Feature (Credential-Vault, Auflösungsprofile, Clipboard-Policy etc.) zu nutzen. Pures TCP-Forwarding — der User öffnet mstsc.exe und gibt die öffentliche Adresse + Port ein.

Vorteile:

Funktioniert mit jedem RDP-Client, egal welches OS.
Funktioniert auch mit anderen RDP-ähnlichen Protokollen (XRDP, VNC über TCP, ThinLinc).

Nachteile:

Keine Credential-Verwaltung in GateControl — der Client muss Benutzer
- Passwort selbst eingeben.
Keine Auflösungsprofile, Clipboard-Redirect-Policies, Session-Timeouts, Sharing, Screenshot-Protokollierung.
Keine Wake-on-LAN-Kopplung an den RDP-Connect (nur auf der L4-Route selbst möglich).
Keine Health-Checks, Tags oder User-Visibility.

Wenn du diese Komfort-Features brauchst → Option B.

Voraussetzungen

Home-Gateway-Container läuft im Heimnetz und heartbeatet
Pro-Lizenz für L4-Gateway-Routen
LAN-Gerät hat RDP aktiviert (Standard-Port 3389)

Einrichten

Im Admin-UI: Routes → Neue Route

Feld	Wert
Type	`L4`
Ziel-Typ	`Home Gateway (LAN)`
Home Gateway	dein Gateway-Peer
LAN-Host	IP des Windows-Rechners im LAN, z.B. `192.168.2.100`
LAN-Port	`3389`
L4-Protokoll	`TCP`
L4-Listen-Port	`3389` — oder Alternative wenn 3389 auf dem Server schon belegt ist (z.B. `13389`)
L4-TLS-Mode	`None`

„Backend HTTPS" leer lassen. Speichern. Die Route ist sofort aktiv sobald der Gateway-Config-Sync durchgelaufen ist (~2 s).

Port-Konflikte vermeiden

Der Server blockiert per Default einige Ports für den L4-Listen-Port (22/53/80/443/2019/3000/51820). Falls dein Ziel-Port einer davon ist, musst du einen anderen Listen-Port nach außen vergeben. Oft besser sowieso: rdp.example.com:13389 statt Standard-3389 reduziert Brute-Force-Rauschen in den Logs.

Vom Client verbinden

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.

Datenfluss

RDP-Client ── TCP SYN ──▶ Server (VPS)
                             │
                             │ Caddy-L4-Plugin
                             │ forward → 10.8.0.8:3389 (WG-Tunnel)
                             ▼
                         Gateway-Container (Heim)
                             │
                             │ TcpProxyManager :3389
                             │ forward → 192.168.2.100:3389
                             ▼
                         Windows-Rechner (RDP-Server)

Caddy's Layer-4-Plugin macht pure TCP-Byte-Forwarding — der RDP- Handshake wird nicht geparst. Dadurch läuft jedes TCP-basierte Protokoll durch, nicht nur RDP.

Wake-on-LAN an die Route hängen

Auf der L4-Route WoL aktivieren. Wenn der Gateway beim Connect ECONNREFUSED vom LAN-Ziel bekommt, feuert er ein Magic-Packet an die konfigurierte MAC. Der RDP-Client retriert die Connection meist automatisch — im zweiten Anlauf ist der Rechner aus dem Standby.

Erfordert: WoL im BIOS + im Netzwerkadapter aktiviert, Gateway-Container im selben L2-Segment wie das Zielgerät.

Option A vs. Option B

Feature	Option A	Option B
Credential-Vault	✗	✓
Auflösungsprofile	✗	✓
Clipboard/Drive/USB-Redirect-Policies	✗	✓
Audio-Modus	✗	✓
Network-Profile	✗	✓
NLA-Config	✗	✓
WoL am RDP-Connect-Event	✗	✓
Session-Timeout, Admin-Session	✗	✓
Maintenance-Windows	✗	✓
Sharing-Modes, Screenshot	✗	✓
Generierbares `.rdp`-File	✗	✓
User-/Token-Visibility	✗	✓
Setup-Aufwand	1 L4-Route anlegen	Wizard durchklicken, L4-Route wird automatisch erzeugt

Beide machen netzwerkseitig exakt dasselbe — Option B legt die L4-Route implizit unter der Haube an, zeigt sie aber nicht direkt im Routes-Grid. Option A ist direkter, Option B komfortabler.

Troubleshooting

Client: „Connection refused"

Läuft der RDP-Dienst? (PowerShell: Get-Service TermService)
Remoteverbindungen in den Windows-Systemeinstellungen aktiviert?
Firewall-Ausnahme für Port 3389 in der Windows-Defender-Firewall

Client hängt bei „Authentifizierung wird eingerichtet"

NLA-Mismatch. Im Client-Tool „Erweitert" → CredSSP deaktivieren und klassische Authentifizierung testen. Option B löst das sauberer weil NLA serverseitig gesetzt werden kann.

Verbindung bricht nach Sekunden ab

MTU-Problem im WG-Tunnel. Die MTU/MSS-Clamp-Regeln im entrypoint.sh adressieren das bereits; falls trotzdem Dropouts → GC_WG_MTU=1280 in der .env setzen.

Standard-Port 3389 will ich nach außen nicht öffnen

L4-Listen-Port auf z.B. 13389 setzen. LAN-Port bleibt 3389. Client verbindet dann mit rdp.example.com:13389.

Zugriff auf den RDP-Client vs. MS RD-Gateway

Nicht verwechseln:

Home-Gateway (dieses Projekt) — routet TCP-Byte-Streams ins LAN
Microsoft RD-Gateway (TSGateway) — Windows-Server-Rollen-Dienst der RDP über HTTPS tunnelt. Eigenständiges Produkt. GateControl hat dafür am RDP-Route separate Felder (siehe Option B), falls MS-RDG vor deinem RDP-Server steht.