Probleme mit Remotedesktopverbindung (RDP) von Subnetz in lokals Netz

[Wuschelchen]

Moin,

ich habe derzeit folgende Konfiguration:
Server: 192.168.80.125
open VPN-Server: 10.8.0.1
Clients lokal (Windows 11): z.B. 192.168.80.106
Client VPN-Subnet: z.B. 10.8.0.2

Die Verbindung von außen auf den VPN-Server klappt ohne Probleme.
Die Verbindung wird hergestellt und die zugewiesene Subnetz-IP zugewiesen.

Nun kommt das Problem:
Auf einen der hier stehenden Rechner kann ich mich (wenn per VPN verbunden) nicht per RDP aufschalten (10.8.0.2 auf 192.168.80.106).
Das aufschalten von "innen" (z.B. 192.168.80.105 auf 192.168.80.106) funktioniert ohne Probleme.

Die Konfiguration der Rechner habe ich nun bereits mehrfach abgegelichen:

RDP ist aktiviert
in der Firewall freigegeben (UDP Regel)
die statische Route zum Subnetz ist ebenfalls hinterlegt

Virenscanner und Firewall auf dem betroffenen Client habe ich testweise auch mal komplett deaktiviert, hat nichts gebracht.

Die üblichen Googletipps bei RDP Problemen habe ich ebenfalls schon mehrfach durch und verzweifel ein wenig, da ich keinen Grund finde warum das ganze nur bei diesem einen Rechner nicht funktioniert ... hoffe jemand hat einen Tipp für mich.

Danke schonmal im Vorraus !

 

[till69]

Funktioniert ping in beide Richtungen?

 

[up.whatever]

Da musst du dir wohl den Router bzw die Firewalls zwischen dem VPN-Subnet und dem Server Subnet ansehen.

 

[Lawnmower]

Würde auch sagen erstmal gucken ob Ping geht, Firewall auf dem 192.168.80.106 deaktiviert lassen vorerst (wichtig: Für alle Zonen da der Zugriff vermutlich dann für Windows aus dem "öffentlichen Netzwerk" kommen wird) damit es am Schluss nicht auch noch an dem scheitert.
Wenn das nicht geht, dann wird es ein Routing Problem sein: Der VPN Client kommt dann zwar ins Netz, aber weiss nicht wie er ins andere Subnetz gelangt. Wo hast Du die statische Route definiert? Wird die auch am VPN Client mitgegeben?

 

[Wuschelchen]

Der betroffene Client kann hier wie folgt pingen:
192.168.80.106 <> 192.168.80.125 (Server lokal)
192.168.80.106 <> 192.168.80.105 (anderer Client lokal)
192.168.80.106 <> 10.8.0.1 (VPN-Server)

Alle Pings gehen ohne Verluste durch.

Ergänzung (26. September 2025)

Da musst du dir wohl den Router bzw die Firewalls zwischen dem VPN-Subnet und dem Server Subnet ansehen.

Der Router ist eine FritzBox, hier ist überhaupt nichts eingerichtet.
Die Routen sind statisch direkt auf den einzelnen Rechnern hinterlegt.

Ergänzung (26. September 2025)

Würde auch sagen erstmal gucken ob Ping geht, Firewall auf dem 192.168.80.106 deaktiviert lassen vorerst (wichtig: Für alle Zonen da der Zugriff vermutlich dann für Windows aus dem "öffentlichen Netzwerk" kommen wird) damit es am Schluss nicht auch noch an dem scheitert.
Wenn das nicht geht, dann wird es ein Routing Problem sein: Der VPN Client kommt dann zwar ins Netz, aber weiss nicht wie er ins andere Subnetz gelangt. Wo hast Du die statische Route definiert? Wird die auch am VPN Client mitgegeben?

Die statischen Routen sind auf jedem Rechner hinterlegt.
Über die VPN Config erhalten die Remote-Clients die entsprechende IP gepusht.

Mein Remote-Client kann ohne Probleme den VPN-Tunnel aufbauen, erhält die IP 10.8.0.2 und kann sich dann per RDP auf 192.168.80.105 oder .102 verbinden. Nur auf .106 funktioniert nicht

 

[till69]

Ganz absehen vom Routing, was ist der Grund für OpenVPN? Warum nicht Wireguard?

 

[up.whatever]

Die Routen sind statisch direkt auf den einzelnen Rechnern hinterlegt.

Trotzdem muss irgendwo ein Routing zwischen den Netzen stattfinden. Ich nehme an das macht dein VPN Server? Oder was trägst du auf dem RDP Server als Gateway ins 10er Netz ein?

 

[Wuschelchen]

Ganz absehen vom Routing, was ist der Grund für OpenVPN? Warum nicht Wireguard?

Weil openVPN seit ca. 10 Jahren zuverlässig funktioniert ;-)

Ergänzung (26. September 2025)

Trotzdem muss irgendwo ein Routing zwischen den Netzen stattfinden. Ich nehme an das macht dein VPN Server? Oder was trägst du auf dem RDP Server als Gateway ins 10er Netz ein?

Ja, das macht der Server/openVPN Server.

 

[up.whatever]

Ja, das macht der Server/openVPN Server.

Dann wirf dort Wireshark/tcpdump an und schau was beim Verbindungsversuch an Paketen vorbei kommt.

 

[till69]

Weil openVPN seit ca. 10 Jahren zuverlässig funktioniert

Das tut Wireguard auch seit vielen Jahren, nur deutlich schneller und problemloser

OpenVPN nimmt man nur noch, wenn man eine TCP Verbindung braucht.

 

[airwave]

OpenVPN nimmt man nur noch, wenn man eine TCP Verbindung braucht.

Irre ich mich oder ist bei Wireguard nicht einfach ein schalter: vpn AN/AUS ?
während bei openvpn so einstellbar ist, dass es beim connect nochmal ein passwort braucht oder sowas wie TOTP.
sprich ist die maschine mit wireguardclient kompromittiert, kommt man problemlos und sofort auch in die VPNs?
MFA/2FA geht laut kurzer suche bei wireguard auch, muss man sich aber mit befassen und ist nicht out of the box.

 

[qiller]

Mein Remote-Client kann ohne Probleme den VPN-Tunnel aufbauen, erhält die IP 10.8.0.2 und kann sich dann per RDP auf 192.168.80.105 oder .102 verbinden. Nur auf .106 funktioniert nicht

Aber 105, 102 und 106 haben auch alle die Fritzbox als Standardgateway eingestellt, oder? Und wenn der VPN-Server und das Standardgateway nicht derselbe Host ist, benötigt man entsprechende statische Routen für das Routing durch den VPN-Tunnel. Die hast du in der FB hinterlegt?

https://openvpn.net/community-docs/...es-on-either-the-client-or-server-subnet.html

Next, you must set up a route on the server-side LAN gateway to route the VPN client subnet (10.8.0.0/24) to the OpenVPN server (this is only necessary if the OpenVPN server and the LAN gateway are different machines).

Ensure you enable IP and TUN/TAP forwarding on the OpenVPN server.

 

[Wuschelchen]

@qiller Ja, die (192.168.80.105 / .125 / etc.) haben alle die FritzBox (192.168.80.11) als Gateway.

Der openVPN Server hat folgende Konfiguration [Auszug], also ebenfalls die FritzBox als Gateway:
mode server
local 192.168.80.125
port 1194
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.80.0 255.255.255.0 10.8.0.1"

Ergänzung (26. September 2025)

Irre ich mich oder ist bei Wireguard nicht einfach ein schalter: vpn AN/AUS ?
während bei openvpn so einstellbar ist, dass es beim connect nochmal ein passwort braucht oder sowas wie TOTP.
sprich ist die maschine mit wireguardclient kompromittiert, kommt man problemlos und sofort auch in die VPNs?
MFA/2FA geht laut kurzer suche bei wireguard auch, muss man sich aber mit befassen und ist nicht out of the box.

Ich bin mit openVPN, der Geschwindigkeit und der Sicherheit eigentlich zufrieden.

 

[qiller]

Der betroffene Client kann hier wie folgt pingen:
192.168.80.106 <> 192.168.80.125 (Server lokal)
192.168.80.106 <> 192.168.80.105 (anderer Client lokal)
192.168.80.106 <> 10.8.0.1 (VPN-Server)

Nagut, dass netzintern die Pings funktionieren, davon geht man ja aus^^. Hier fehlt mir die Info, ob denn auch ein Ping von einem Remote OpenVPN Client durch den Tunnel durch die 192.168.80.102, 192.168.80.105 und 192.168.80.106 erreicht. Ich vermute dann mal, dass bei der 102 und 105 der Ping durchkommt, aber bei der 106 nicht? Hast du das mal getestet?

 

[redjack1000]

Zeige mal das Routing, nutze dafür tracert.exe, poste das Ergebnis vollständig in das Forum.

CU
redjack

 

[Wuschelchen]

@redjack1000 Werde ich heute Abend machen und dann hier posten 👍

 

[Wuschelchen]

Also mein RemotePC sagt bei tracert:
C:\>tracert 10.8.0.1
Routenverfolgung zu Jaxxxs_Serv [10.8.0.1]
über maximal 30 Hops:
1 28 ms 28 ms 27 ms Jaxxxs_Serv [10.8.0.1]
Ablaufverfolgung beendet.

Und bei ping:
C:\>ping 10.8.0.1
Ping wird ausgeführt für 10.8.0.1 mit 32 Bytes Daten:
Antwort von 10.8.0.1: Bytes=32 Zeit=26ms TTL=128
Antwort von 10.8.0.1: Bytes=32 Zeit=26ms TTL=128
Antwort von 10.8.0.1: Bytes=32 Zeit=27ms TTL=128
Zeitüberschreitung der Anforderung.
Ping-Statistik für 10.8.0.1:
Pakete: Gesendet = 4, Empfangen = 3, Verloren = 1
(25% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 26ms, Maximum = 27ms, Mittelwert = 26ms

C:\>ping 192.168.80.125
Ping wird ausgeführt für 192.168.80.125 mit 32 Bytes Daten:
Antwort von 192.168.80.125: Bytes=32 Zeit=27ms TTL=127
Antwort von 192.168.80.125: Bytes=32 Zeit=28ms TTL=127
Antwort von 192.168.80.125: Bytes=32 Zeit=35ms TTL=127
Antwort von 192.168.80.125: Bytes=32 Zeit=29ms TTL=127
Ping-Statistik für 192.168.80.125:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 27ms, Maximum = 35ms, Mittelwert = 29ms

Ping 192.168.80.105 bekommt er TimeOut, RDP Verbindung geht aber trotzdem. Verbindung zu .106 klappt nicht ...

Ergänzung (26. September 2025)

C:\>tracert 192.168.80.125

Routenverfolgung zu Jaxxxs_Serv [192.168.80.125]
über maximal 30 Hops:

1 28 ms 26 ms 25 ms Jaxxxs_Serv [10.8.0.1]
2 28 ms 29 ms 27 ms Jaxxxs_Serv [192.168.80.125]

Ablaufverfolgung beendet.

 

[qiller]

Verbindung zu .106 klappt nicht ...

auch mit deaktivierter Windows-Firewall?

 

[redjack1000]

Also mein RemotePC sagt bei tracert:
C:\>tracert 10.8.0.1
Routenverfolgung zu Jaxxxs_Serv [10.8.0.1]
über maximal 30 Hops:
1 28 ms 28 ms 27 ms Jaxxxs_Serv [10.8.0.1]
Ablaufverfolgung beendet.

Das Routing verstehe ich nicht.

CU
redjack

 

[qiller]

Das Routing verstehe ich nicht.

Naja, der Host mit dem OpenVPN Client (mit irgendeiner 10.8.0.X IPv4 auf dem TUN-Adapter) ist halt direkt mit dem anderen Ende des OpenVPN Tunnels (dem OpenVPN Server mit der IPv4 10.8.0.1) verbunden. Da gibts halt nichts zu routen :>.