RDP über pfSense zwischen zwei Netzen. TRANSIT (192.168.12.0 24) → VLAN30 (192.168.30.0 24)

Du willst von einem Windows-Client im Transit-Netz (192.168.12.2) per RDP (TCP/3389) auf einen Windows-Rechner im VLAN30 (192.168.30.100) zugreifen. pfSense routet dabei zwischen den Netzen und muss den Traffic auch firewalltechnisch erlauben.

Die Lösung besteht aus vier Bausteinen:

1. Client kennt den Weg ins Zielnetz (Route)

2. pfSense erlaubt den RDP-Traffic auf dem richtigen Interface (TRANSIT)

3. Zielhost lauscht auf 3389 und lässt es durch die Windows-Firewall

4. Benutzer ist für RDP berechtigt

1) Netzwerküberblick (Soll-Zustand)

• Client: 192.168.12.2 (TRANSIT)

• pfSense Transit-IP: 192.168.12.1

• Zielhost: 192.168.30.100 (VLAN30)

• pfSense VLAN30-IP (Default Gateway im VLAN30): 192.168.30.1

Wichtig: Der Zielhost muss als Gateway 192.168.30.1 haben, sonst geht die Rückantwort nicht sauber zurück.

2) Client: Route zum VLAN30 setzen (persistent)

Auf dem Windows-Client 192.168.12.2 als Admin:

route -p add 192.168.30.0 mask 255.255.255.0 192.168.12.1

Prüfen:

route print | findstr 192.168.30.0

Häufige Fehler

• Falsches Gateway: NextHop muss die pfSense-IP im Transit sein (192.168.12.1).

• Falsches Netz: Zielnetz ist 192.168.30.0/24, nicht 192.168.30.100/24.

3) pfSense: RDP auf TRANSIT erlauben (entscheidend)

pfSense filtert eingehend pro Interface. Da dein Client aus TRANSIT kommt, muss die Allow-Regel auf Firewall → Rules → TRANSIT liegen.

Regel anlegen

pfSense → Firewall → Rules → TRANSIT → Add (↑)

Einstellungen:

• Action: Pass

• Address Family: IPv4

• Protocol: TCP

Source

• Type: Network

• 192.168.12.0/24

Destination

• Type: Address or Alias (oder „Single host“, je nach UI)

• 192.168.30.100 (als Host, ggf. /32)

Destination port

• 3389 (RDP)

Optional: Log packets aktivieren (für Debugging).

Dann Save und Apply Changes.

Häufige Fehler

• Regel auf falschem Interface (z.B. VLAN30 statt TRANSIT). Dann greift sie nicht.

• Source „TRANSIT address“ gewählt: Das ist die pfSense-eigene IP, nicht dein Clientnetz.

• Ziel falsch geschrieben: Klassiker 192.16830.100 ohne Punkt. pfSense nimmt’s manchmal trotzdem an, hilft aber niemandem.

• Falsche Maske: 192.168.30.100/24 ist kein Netz. Host ist /32.

4) Zielhost: RDP läuft und Port 3389 ist offen

Auf dem Zielhost 192.168.30.100 (PowerShell als Admin):

Dienst prüfen

Get-Service TermService

Erwartung: Running

Port prüfen

netstat -an | findstr :3389

Erwartung: LISTENING auf 0.0.0.0:3389

5) Zielhost: Windows-Firewall für RDP erlauben

Zuerst Standard-RDP-Regeln aktivieren:

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Dann eine saubere, scoped Regel für Transitnetz hinzufügen (robust, Profil-unabhängig):

New-NetFirewallRule -DisplayName "Allow RDP from 192.168.12.0/24" ` -Direction Inbound -Action Allow -Protocol TCP -LocalPort 3389 ` -RemoteAddress 192.168.12.0/24 -Profile Any

Häufige Fehler

• Regel auf dem falschen Rechner ausgeführt (z.B. auf dem Client statt auf 192.168.30.100).

• Regel nur fürs Domain-Profil, Zielhost ist aber Private/Public (dann greift sie nicht).
  Prüfen:

  Get-NetConnectionProfile

6) Verbindung testen (bevor du mstsc startest)

Auf dem Client 192.168.12.2:

Test-NetConnection 192.168.30.100 -Port 3389

Erwartung:
TcpTestSucceeded : True

Wenn das False ist, brauchst du gar nicht erst mstsc probieren (es ist dann noch Firewall/Routing).

7) RDP starten (als Administrator)

Auf dem Client:

mstsc /v:192.168.30.100

Benutzername je nach Umgebung:

• AD\bauer (Domain\user)

• oder bauer@ad.rubinhood.de (UPN)

8) Typischer Login-Fehler: „not authorized for remote login“

Wenn Netzwerk passt (Porttest True), aber RDP sagt:

user account is not authorized for remote login

Dann fehlt dem User das RDP-Logon-Recht.

Fix: User in „Remote Desktop Users“

Auf 192.168.30.100:

• Computerverwaltung → Lokale Benutzer und Gruppen → Gruppen → Remote Desktop Users

• AD\bauer hinzufügen

Oder per PowerShell:

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "AD\bauer"

Wenn es trotzdem nicht geht

Dann kann eine GPO das Recht verweigern:

• secpol.msc → Local Policies → User Rights Assignment

  • Allow log on through Remote Desktop Services: muss passende Gruppe enthalten

  • Deny log on through Remote Desktop Services: darf den User/Gruppe nicht enthalten

Quick Troubleshooting Matrix (kurz & effektiv)

A) Ping geht, aber TcpTestSucceeded ist False

• pfSense-Regel auf TRANSIT fehlt/greift nicht

• Windows-Firewall blockt 3389

• Zielhost lauscht nicht auf 3389

B) TcpTestSucceeded ist True, aber RDP-Login wird abgelehnt

• User nicht in Remote Desktop Users / nicht Admin

• GPO „Deny log on through RDS“

C) Regel gesetzt, aber trotzdem kein Zugriff

• Zielhost hat falsches Gateway (muss 192.168.30.1 sein)

• Regel-Reihenfolge: Block-Regel über Allow (pfSense)

IPv4-Subnetting von /24 zu /26

15.10.2023

In diesem Beitrag zeige ich dir, wie du Subnetze berechnest und warum das „Leihen“ von Bits so wichtig ist.

BIG 2862

13.08.2023

Er ist keine Firewall, kein Switch, kein “Router fürs Wohnzimmer”.