RDP-Zugriff auf Windows einrichten

Du willst auf einen Windows-PC (Büro-Desktop, Homeoffice-Laptop, Windows Server) von außen per Remote Desktop zugreifen. Diese Anleitung zeigt, wie du das über GateControl sauber aufsetzt — mit verschlüsselter Credential-Ablage, Wake-on-LAN, Maintenance-Fenstern und einem 1-Click-Launcher im GateControl-Desktop-Client.

RDP ist ein Pro-Feature. Im Community-Plan ist der Wizard gesperrt.

Zwei Varianten — welche willst du?

Variante A — Direkter Peer (VPN-Client auf dem Zielrechner)

Der Zielrechner hat den GateControl-Client installiert, baut einen eigenen WireGuard-Tunnel auf und bekommt eine VPN-IP (10.8.0.x).

Gut für: Laptops, die eh unterwegs ins VPN eingebunden sind, Homeoffice-Rechner mit dauerhaftem VPN-Profil.

Nicht gut für: Büro-PCs die du nicht anfassen willst, LAN-Geräte ohne installierbare Software, Windows Server wo du kein VPN-Client installieren sollst/willst.

Variante B — Via Home-Gateway (empfohlener Standardfall)

Der Windows-Rechner hat nichts installiert. Im selben LAN läuft ein Home-Gateway-Container (siehe first-gateway-setup.md), der den Tunnel zum Server hält und den RDP-Port ins LAN weiterreicht.

Gut für: alles Büro- und NAS-Umfeld. Keine Agent-Installation am Zielrechner.

Die weiteren Schritte unten gelten für beide Varianten — der Wizard fragt in Step 1 ab, welche du willst.

Nicht verwechseln: Unter RDP-Setting gibt es zusätzlich ein Feld für Microsoft RD-Gateway (TSGateway). Das ist eine Windows-Server-Rolle, kein GateControl-Feature, und nur relevant wenn du in einem Enterprise-AD sitzt, das RDP über einen MS-RDG-Proxy tunnelt. Für Heim- und kleine Büro-Setups ignorieren.

Vorbereitung am Windows-Rechner

Bevor du im Wizard was klickst:

RDP einschalten: Einstellungen → System → Remotedesktop → ein. Auf Home-Editionen von Windows 10/11 ist RDP gesperrt; entweder Pro aktivieren oder Drittlösung.
NLA (Network Level Authentication) aktiv lassen — die Wizard-Default ist NLA an.
Firewall: Die Windows-Firewall-Regel "Remotedesktop" ist automatisch aktiv, sobald RDP eingeschaltet wird. Falls eine 3rd-Party-Firewall (GData, ESET etc.) läuft: TCP 3389 freigeben.
Testzugriff im LAN: Von einem anderen Rechner im selben LAN mstsc /v:192.168.1.20 — wenn das schon nicht geht, wird's über GateControl erst recht nicht.
LAN-IP notieren (bei Variante B) bzw. VPN-IP notieren (bei Variante A, z.B. 10.8.0.23).
MAC-Adresse notieren, falls du Wake-on-LAN nutzen willst: getmac /v. Die MAC der kabelgebundenen Karte bevorzugen — WLAN-WoL ist zickig.

RDP-Route anlegen

In der Admin-UI auf RDP (Sidebar).
+ Neue RDP-Route oben rechts.
Der Wizard öffnet sich mit 6 Steps.

Step 1 — Verbindung

Name: pc-büro oder laptop-marco. Wird als Anzeigename im Client benutzt.
Beschreibung: freitext, optional.
Host: Bei Variante A die VPN-IP (10.8.0.23), bei Variante B die LAN-IP (192.168.1.20).
RDP-Port: 3389 (Default), oder custom wenn du den Windows-Port umgestellt hast.
Access-Mode:
- Nur VPN (intern) — Variante A, Client muss im VPN sein um zu connecten.
- Öffentlicher Port-Forward — Variante A, aber zusätzlich per Public-IP:Port erreichbar.
- Beide (intern + extern) — Variante A mit beiden Zugängen.
- Über Home-Gateway — Variante B. Zwei Zusatzfelder erscheinen:
  - Home-Gateway-Peer: dropdown mit allen Gateway-Peers.
  - Öffentlicher Listen-Port: Port auf dem Server, über den der Client zum Gateway kommt. Default 3389, aber falls der Server schon 3389 für einen anderen Rechner belegt hat, setz was anderes (z.B. 3390).
Microsoft RD-Gateway (TSGateway) — nur ausfüllen wenn im Enterprise-AD ein TSGateway davor steht. Sonst leer lassen.

Step 2 — Authentifizierung

Hier landen die RDP-Login-Credentials (Windows-User + Passwort).

Benutzername: DOMAIN\user oder user@domain oder lokal nur user.
Passwort: wird E2EE im Client gespeichert (nicht im Klartext auf dem Server). Die Funktionsweise:
- Server hat ein Keypair (Public-Key ist öffentlich).
- Dein GateControl-Client holt den Server-Public-Key und verschlüsselt das RDP-Passwort damit.
- Server speichert nur den Ciphertext, kann ihn nie entschlüsseln.
- Beim Connect leitet dein Client aus ECDH-Shared-Secret das Passwort ab.
Credential-Rotation: optional. Wenn aktiv, fordert GateControl nach X Tagen einen neuen Passwort-Eintrag an (z.B. 90 Tage = Corp-Policy).

Step 3 — Session-Erfahrung

UI-Komfort-Einstellungen, die in der .rdp-Datei landen:

Auflösung (z.B. 1920x1080, Dynamic).
Farbtiefe (16/24/32 Bit).
Audio-Mode: lokal, Ziel, aus.
Clipboard-Sync: an/aus.
File-Sharing (lokale Laufwerke im RDP mounten): an/aus.
Printer-Redirect: an/aus.
Smartcard-Redirect: an/aus.
USB-Redirect: an/aus.

Für die meisten Setups: Defaults lassen, Clipboard an, Audio auf "lokal", Drives aus (sonst hängt der RDP-Host dein Laptop-C:\ ein).

Step 4 — Sicherheit & Verhalten

Session-Timeout: nach X Minuten Inaktivität beendet Server die Tracking-Session.
Bandbreiten-Limit: weich, Hint für den Client.
Health-Check: TCP-Check auf 3389. Route gilt erst als online wenn der Check läuft.
Screenshot bei Session-Start: optional, Audit-Feature.

Step 5 — WoL & Tags

Wake-on-LAN aktiv: Haken an wenn du WoL willst.
MAC-Adresse: aus getmac /v, Format AA:BB:CC:DD:EE:FF.
Maintenance-Fenster: Zeitfenster in denen die Route blockiert ist (Windows-Update-Reboots, Wartungsarbeiten). Der Server blockt aktiv — Client darf Connect trotzdem versuchen, Server antwortet mit 423 Locked. Der Client zeigt dann einen Hinweis.
Tags: für Gruppierung im Client-UI.

Step 6 — Zugriff & Zusammenfassung

Berechtigungen: welche Admin-User diese RDP-Route sehen und verwenden dürfen.
Peer-ACL: welche Peers (= Client-Geräte) die Route nutzen dürfen.
Review: letzte Kontrolle, dann Speichern.

Der Server legt beim Speichern zwei Dinge an:

Die RDP-Route selbst (mit dem Credential-Vault-Eintrag).
Bei Access-Mode "Über Home-Gateway": automatisch eine begleitende L4-Route (route_type=l4, target_kind=gateway), die den Listen-Port auf dem Server öffnet und zum Gateway forwarded.

Client-Seite: Verbindung aufbauen

Auf dem Admin-/User-Rechner brauchst du den GateControl-Desktop-Client (Windows, Pro-Edition). Download und Pairing-Anleitung siehe ../USER-GUIDE.md#desktop-client.

Sobald der Client mit dem Server gekoppelt ist:

Client zeigt unter RDP die neue Route.
Doppelklick → Client macht:
- Credential-Handshake mit Server (holt verschlüsseltes Passwort, leitet Shared-Secret ab).
- Prüft Maintenance-Window (würde bei 423 Locked abbrechen mit Hint).
- Prüft Reachability — wenn TCP-Connect fehlschlägt und WoL an ist: Magic-Packet → 15 Sek. warten → Retry.
- Generiert eine temporäre .rdp-Datei.
- Startet mstsc (auf Windows) bzw. den plattform-nativen RDP-Client.
RDP-Session läuft, .rdp-Datei wird nach dem Disconnect gelöscht.

Für Android/iOS-Clients ist der Flow analog, dort wird ein Drittanbieter-RDP-Client (RD Client, Remmina etc.) getriggert und vorbefüllt.

Sonderfall: Credential-Rotation nach Master-Key-Wechsel

Wenn der Server-seitige Master-Key rotiert wird (z.B. nach Security-Incident, geplante Rotation): alle gespeicherten RDP-Credentials werden ungültig. Die Ciphertext-Blobs in der DB wurden mit dem alten Public-Key verschlüsselt und lassen sich nach Rotation nicht mehr herleiten.

Symptome:

Client zeigt bei Connect "Credential Error".
Admin-UI-Dashboard zeigt den Block "Home Gateway benötigt Re-Pairing" (gilt auch für RDP-Creds).

Fix-Flow für RDP:

RDP → die betroffene Route öffnen → Bearbeiten.
Der Wizard zeigt am Anfang "Rotation pending — Passwort neu eingeben". Technisch: GET /api/v1/rdp/rotation/pending listet die betroffenen Routen.
Passwort-Feld in Step 2 neu befüllen.
Speichern triggert POST /api/v1/rdp/:id/rotation/ack und schreibt den neuen Ciphertext (unter dem neuen Master-Key).
Route funktioniert wieder.

Troubleshooting

"Verbindung hängt nach Login, bricht dann ab"

Klassisches MTU/MSS-Problem. Symptomtyp: RDP-Handshake klappt, NLA geht durch, dann nach 2–5 Sekunden Abbruch. Ursache: innerhalb des WireGuard-Tunnels passen RDP-Frames nicht in die MTU, und irgendwo fehlt TCP-MSS-Clamping.

Prüfschritte:

Am Gateway-Host (Variante B): MTU der WG-Interface prüfen:
```
ip link show wg0 | grep mtu
```
Sollte 1380 oder niedriger sein (nicht 1500).

MSS-Clamping auf dem Gateway aktiv?

iptables -t mangle -L FORWARD -v -n | grep TCPMSS

Am Windows-Rechner RDP-"WAN optimization" mal ausschalten (Registry-Key fDisableUDPTransport=1), um die UDP-Fallback-Transporte zu zwingen.

Bei bekanntem Verbindungsabbruch beim App-Connect (Signaturen wie "Verbindung getrennt — kein Lizenzserver"): WG-MTU 1380, TCP-MSS auf 1280 clampen, dann testen.

"Credential Error" obwohl Passwort stimmt

Master-Key rotiert? Siehe Abschnitt oben — Passwort neu eingeben.
Benutzer-Format falsch? DOMAIN\user vs. user@DOMAIN — RDP ist da zickig, probier beide.
"Anmeldung nur für Administratoren" in Windows-Policy? Nur Admins dürfen RDP nutzen, es sei denn Remote Desktop Users-Gruppe ist gepflegt.

WoL triggert nicht

MAC-Adresse korrekt? Format mit : oder - getrennt, keine Leerzeichen. Nochmal mit getmac /v prüfen.
Layer-2-Connectivity: Der Gateway-Host muss im selben Subnetz wie der Ziel-PC sein — Magic-Packet ist Broadcast und passiert keinen Router.
BIOS: WoL muss im BIOS/UEFI aktiv sein, ebenso im Netzwerktreiber ("Wake on Magic Packet" an).
Stromsparmodus: Windows fährt manche Netzwerkkarten im S5 (Shutdown) hart aus. Fast-Startup ausschalten (Systemsteuerung → Energieoptionen).
ARP-Cache am Gateway: Nach Reboot muss der Gateway die IP des Zielrechners in seiner ARP-Tabelle haben. Wenn er nur die MAC kennt aber keine IP, funktioniert unsere Magic-Packet-Logik trotzdem — wir broadcasten auf die LAN-Broadcast-Adresse 255.255.255.255:9.

"Route ist down" obwohl RDP intern läuft

Health-Check in Step 4 deaktiviert? Dann ist "down" der Default.
Firewall blockt den Health-Probe vom Server-Host zur VPN-IP / vom Gateway zur LAN-IP.
NLA-Strict-Mode — manche Windows-Versionen lehnen den TCP-Connect ohne vollständigen NLA-Handshake ab, dann scheint die Route "down" obwohl sie läuft. Lösung: Health-Check-Typ auf "TCP-Probe only" setzen, nicht "RDP-Handshake".

Weiterführend

first-gateway-setup.md — Vorstufe für Variante B.
adding-a-route.md — die allgemeine Routen- Anleitung, falls du zusätzlich eine HTTP-Route auf denselben Windows-Rechner willst (Webmin, IIS etc.).
../CLIENT-API.md — Endpoints, die der Desktop-Client spricht (Credential-Holen, Rotation-Ack, Reachability-Probe).
../USER-GUIDE.md#11-rdp-routen — vollständige RDP-Section mit allen Feldern im Detail.