RDP-Zugriff auf Windows-Terminal-Server durch UTM/VPN-Netzwerk schlägt fehl

Allgemeine Fragen zu Problemen. Keine Fehlerberichte oder Feature-Anfragen

Moderator: Securepoint

Antworten
Karl_Kunze
Beiträge: 19
Registriert: Di 14.04.2020, 11:25

RDP-Zugriff auf Windows-Terminal-Server durch UTM/VPN-Netzwerk schlägt fehl

Beitrag von Karl_Kunze »

Moin,

mit dem ersten Start des OpenVPN-Client hat dieser ein TAP-Device eingerichtet, d.h. auf dem PC bestehen nun zwei Netzwerkverbindungen mit normal 10.0.0.35 und zusätzlich durch das TAP-Device 192.168.5.2.. Letztere IP-Adresse korrespondiert mit dem IP4-Pool 192.168.5.0/24 auf dem UTM. Der VP-Tunnel wird aufgebaut nach 192.168.5.1 und steht soweit laut OpenVPN-Client einwandfrei.

Auf dem UTM habe ich in der SSL/VPN-Verbindung zusätzlich unter "Servernetzwerke-Freigeben" 172.16.1.8/32 eingetragen zur Verbindung auf den internen Terminal-Server. Ergänzend dazu kommt noch die nachstehende Firewall-Regel:

Aktion "ACCEPTt"
Logging "LONG"
Gruppe "VPN-NETWORK"
Quelle "VPN_NETWORK"
Ziel "INTERNAL-NETWORK"
Dienst "MS-RDP"
Nat "NONE"
Extras " "
Beschreibung " "

Trotzdem gelingt keine RDP-Verbindung, wobei dabei schon die erste Frage für mich jetzt ziemlich dämlich klingt, nämlich welche IP-Adresse x.x.x.x:3389 ich im RDP-Client überhaupt eintragen soll. Ich habe natürlich alle in Frage kommenden durchprobiert, ohne Erfolg, für die weitere Problemlösung wäre es aber natürlich sinnig, im RDP-Client gleich die richtige einzutragen. Um dann mit der zweiten Frage weiter zu klären, wo hier etwas falsch konfiguriert wurde.

Vielen Dank vorab.

Gruß

karl Kunze

Benutzeravatar
NETworks-IT
Beiträge: 19
Registriert: Mi 11.06.2014, 12:13
Wohnort: Hehlen
Kontaktdaten:

Beitrag von NETworks-IT »

In den RDP Client muss natürlich die IP des Servers. Das 192.168.5.0/24 Netz ist ja nur das Transportnetz für die VPN Verbindung.
Gibt es Portfilter, die regeln was aus dem VPN-Netz in Richtung des Servers erlaubt / verboten ist?

pl85
Beiträge: 34
Registriert: Di 13.03.2012, 14:54

Beitrag von pl85 »

Netzwerke in der VPN-Verbindung freigegeben? (sieht man auch im Log desn VPN-Clients, dass er Routen dort hin erstellt)
Regeln müssen natürlich auch erstellt werden

Karl_Kunze
Beiträge: 19
Registriert: Di 14.04.2020, 11:25

Beitrag von Karl_Kunze »

NETworks-IT hat geschrieben:In den RDP Client muss natürlich die IP des Servers. Das 192.168.5.0/24 Netz ist ja nur das Transportnetz für die VPN Verbindung.
Gibt es Portfilter, die regeln was aus dem VPN-Netz in Richtung des Servers erlaubt / verboten ist?
Moin,

IP des Terminalservers mit 172.16.1.8 gehört also in den RDP-Client, allerdings gibt das wie auch schon davor keine Verbindung (auch mit einfach mal abgeschalteter Windows-Firewall nicht).
An welche Portfilter müsste ich da denken? Der Terminalserver wird auch bisher schon über RDP angesprochen. Oder gibt es noch zusätzliche Regeln für die UTM-Firewall, ergänzend zu der bereits eingerichteten Regel, die erforderlich sind? Muss ich an irgendetwas Richtung NAT in der UTM-Firewall denken?

Gruß

Karl Kunze

Karl_Kunze
Beiträge: 19
Registriert: Di 14.04.2020, 11:25

Beitrag von Karl_Kunze »

pl85 hat geschrieben:Netzwerke in der VPN-Verbindung freigegeben? (sieht man auch im Log desn VPN-Clients, dass er Routen dort hin erstellt)
Regeln müssen natürlich auch erstellt werden
Moin,

im Log des VPN-Clients finde ich:
"Wed Apr 22 13:49:30 2020 PUSH: Received control message: 'PUSH_REPLY,route 172.16.1.8 255.255.255.255,route-gateway 192.168.5.1,topology subnet,ping 10,ping-restart 120,ifconfig 192.168.5.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'".

Welche weiteren "Netzwerke in der VPN-Verbindung freigegeben"-Einstellungen wären anzusteuern bzw. an welche weiteren Reglen an welcher Stelle hätte ich zu denken.
Danke und Gruß

Karl Kunze

Andreas
Securepoint
Beiträge: 124
Registriert: Di 18.03.2008, 15:56
Wohnort: Wrestedt
Kontaktdaten:

Beitrag von Andreas »

Moin,
schauen Sie einfach mal ins Log ob da was geblockt wird. Gleichzeitig bitte die Regel vom Transportnetz der VPN-Clients auf den Server mit Logging versehen. Im Wiki gibt es eine hervorragende Anleitung zur Fehlersuche innerhalb einer SSL-VPN-Verbindung:

https://wiki.securepoint.de/UTM/VPN/SSL ... leshooting

Edith:

Ich habe gerade Ihren anderen Beitrag gelesen. Wenn die BD nicht Default-Gateway des Netzwerkes dahinter ist, dann liegt das Problem mit an Wahrscheinlichkeit grenzender Sicherheit daran, dass ein sog. asynchrones Routing vorliegt, so dass der Terminalserver die Antwort an sein Defaultgateway schickt (welches NICHT die BD ist) und dieses wiederum mit dem Transportnetz des Routers nichts anfangen kann. 

Ich kann zwei Lösungen vorschlagen:
1. auf dem Terminalserver eine Route für das Transfernetzwerk der SSLVPN-Clients eintragen (auf die interne IP des BD)
oder 
2. auf dem BD die Firewall-Regel von den SSLVPN-Clients ins interne Netzwerk bzw. auf den Terminalserver um ein HideNAT über das INTERNE Interface ergänzen.

Karl_Kunze
Beiträge: 19
Registriert: Di 14.04.2020, 11:25

Beitrag von Karl_Kunze »

Andreas hat geschrieben: 2. auf dem BD die Firewall-Regel von den SSLVPN-Clients ins interne Netzwerk bzw. auf den Terminalserver um ein HideNAT über das INTERNE Interface ergänzen.
Moin,

das war es, das hat geholfen. Genial.

Vielen Dank für die Unterstützung.

Karl Kunze

Antworten