Endian OpenVPN Probleme mit RDP

Hallo,

Meistens so

RDP direkt aus dem Internet auf den Server /Rechner ist eher tödlich, aber willst du jetzt per VPN abstellen.

Was sagen denn deine Logs deiner Endian dazu? da wird doch sicherlich erkennbar sein was und wo dort dein ICMP (Ping) blockiert. Genauso wird es dann mit TCP 3389 sein oder jedes andere Protokoll. Entweder blockt deine Endian oder aber der Rechner 172.16.16.2 nimmt deine ICMP requests gar nicht erst an (Lokale Firewall) oder schickt die ICMP Echos an das falsche Gateway. Ebian sagen dir Logs was dort passiert und am Rechner einfach mal den Wireshark mitlaufen lassen und nach deiner (VPN) IP ausschau halten lassen.

Gruß,
Peter

Hallo,

keine Ahnung was du wo und wie siuchst. Sorry.

Wonach?

?!?

Das ist blödsinn, denn das eine Antwort auf deine Ping Requests ausbleiben weisst du ja schon. jetzt gilt es in dein Logs deiner Endian Firewall zu schauen. Entweder wird dort dein Ping aufgezeichnet, dessen ablehnung oder welche Regel angewendet wird usw. Vielleicht hast ja auch nicht erlaubt das ICMPs (Ping) durch deine Firewall dürfen. Du kannst aber auch auf den Rechner den du per RDP später erreichen willst den Wireshark laufen lassen und schauen ob dort deine ICMP Requests überhaupt ankommen und ICMP Echos auch rausgehen.

Dein Lokaler PC ist wo? In dein LAN daheim oder was? Und wieso ist der 172.16.16.2 Entfernt? Die IP deutet doch daraufhin das beide sich im gleichen IP Netz befinden - am gleichen Switch. Oder ist dem nicht so? Vielleicht mal auf ein stück papier dein netzaufbau m it allen IPs, GWs Subnetzmeasken an ihren Ports (Anschlüssen) aufmalen und hier mal rein stellen. natürlich die WAN IP verschleieren.

hast du nicht RDP die ganze zeit genutzt per Portweiterleitung? das geht nicht mehr?

Das Erzähl mal die Jungs und Mädels die deine Endian bauen - die lachen dich aus....

Gruß,
Peter

Was da irgendwie verwirrend ist ist die Tatsache das "Mein PC" 2mal vorhanden ist und die gleiche IP Adresse hat. Das ist so unmöglich wenn man davon ausgeht das das 2 VPN Clients sind. Diese müssen 2 unterschiedliche IP Adressen haben.
Ebenso Das System "Endian" und "RDP". Wenn man davon ausgeht das das auch 2 VPN Endgeräte sind, dann sind hier wieder 2mal die gleiche IP Adresse was so niemals sein kann.
Irgendwie ist das alles recht wirr, da man nicht wirklich weiss WO der VPN Server rennt und wo der Client.
Was man so aus den verwirrenden Fakten zusammenkluben kann ist das es einen öffentlichen Server irgendwo gibt mit einer 82er IP auf dem wohl ein OpenVPN Server rennt.
Der OpenVPN Server hat die interne VPN IP 172.16.16.0 /24 (server 172.16.16.0 255.255.255.0 in der server.conf Datei)
Wo aber dieser Server rennt auf dem System "Endian" oder "RDP" ist unklar
Möglich auch das Endian und RDP ein und dieselbe HW sind, die Vermutung liegt auch nahe.
Möglich aber auch das Endian und RDP 2 MVs sind die auf einem Hypervisor laufen, denn Endian ist ja bekanntermaßen eine Firewall. Frage dann hier ob das dann 2 VMs sind oder ob Endian eine OpenVPN Option hat wie die pfSense z.B.
Was das ganze dann noch völlig verwirrend macht ist die Angabe von NAT, sprich das das Sytem RDP irgendwie über NAT erreichbar ist was der größte Unsinn ist, denn bei OpenVPN sind Clients und Server immer direkt über das interne OpenVPN IP Netzwerk erreichbar. NAT oder so ein Unsinn ist da vollkommen überflüssig.
Es mag aber sein das sich die NAT Aussage jetzt auf einen direkten Zugang über die öffentliche 82er IP bezieht, das hier direkt Port Forwarding auf den Server gemacht wird. Nur wozu ?? Denn der Server macht ja gar kein NAT wenn er eine öffentliche IP hat.
Irgendwie ist das ganze Konstrukt vollkommen wirr und unverständlich von der IP Adressierung...sorry ?!

Eigentlich ist die Welt ganz einfach bei OpenVPN:

• Server hat öffentliche 82er IP und die Clients sprechen diese IP als Tunnelendpunkt an
• Wenn der Client / Tunnel aktiv ist kann man mit route print nachsehen ob das interne 172.16.16.0 /24 Netz aktiv ist und muss dann den Server direkt über das 172er Netz erreichen
• Gefahr droht nur wenn das Server OS ein Winblows OS ist Dann schlägt hier die lokale Winblows Firewall am virtuellen VPN Adapter zu ((ipconfig -all) denn der wird durch die fehlende Gateway Detektierung dann immer in das Profil Öffentliches Netz gezwungen ! Das bewirkt dann das man auf nichts beim Server zugreifen kann...klar.
• Hier muss man zwingend das Profil der Firewall auf Privat umstellen oder die Firewall durchlässig machen für seinen Dienst wie z.B. TCP 3389 (RDP)
• Das gleiche gilt natürlich auch für einen Windows Client und dessen Firewall

Eigentlich alles ganz einfach und wenn man das alles beachtet kommt das auch sofort zum Fliegen. Das ist ein simpler Klassiker. Hilfreich wären hier wie immer Logauszüge vom Server und Client um mal zu sehen das die OVPN Verbindung sauber aufgebaut wird. Ist das der Fall ist der Rest zu 98% Firewall Customizing der lokalen Windows Firewall aus dem o.g. Gründen.

OK, das bringt etwas Klarheit... Das bedeutet also das dann das 172.16.16.0 /24er Netz quasi dein lokales LAN ist, richtig ?
Über das netzwerk hast du dann die Endian FW und den RDP Host verbunden...soweit so gut.
Dazu dann 2 Fragen:

• Was ist denn dein internes OpenVPN netzwerk was in der OVPN Server Konfig Datei mit server y.y.z.a definiert ist ??
• Hast du in selbiger Datei auch dann entsprechend ein push route 172.16.16.0 Kommando um das interne LAN an den Client zu ünertragen
• WAS sagt dann ein route print wenn der Tunnel aktiv ist ?? Kannst du da sehen das das interne OVPN Netzwerk und auch das lokale LAN 172.16.16.0 /24 an den OVPN Server in den Tunnel geroutet werden ???

Das wäre erstmal der erste Schritt um das Routing im VPN richtig zu machen !

Das du die Firewall aufrufen kannst ist schon mal ein erster Schritt in die richtige Richtung. Das Problem sind dann vermutlich die Firewall Regeln. Ich vergleiche es mal mit der pfSense, das dürfte bei der Endian ähnlich wenn nicht gleich sein.
Das VPN Tunnelinterface hat ebenso ein regelwerk wie das lokale LAN. An beiden Firewall Interfaces müssen zwangsweise entsprechende Regeln definiert sein die das interne IP Netz von OpenVPN passieren lassen via lokalem LAN. Auch wenn das lokale LAN bei dir ja quasi nur virtuell im Hypervisor abläuft ist es doch aus Firewall Sicht wie ein lokales IP Segment zu sehen.
Hier müssen entsprechende Firewall Regeln definiert sein für IP und ICMP oder was auch immer du freigeben willst.
Am Anfang macht es sicher Sinn hier erstmal etwas großzügiger zu sein für den Testbetrieb. Also das interne OVPN Netzwerk und das lokale LAN müssen auf alle Fälle passieren dürfen.
Zu 98% hast du hier deinen Fehler gemacht ! Da fehlen ganz sicher Firewall regeln die das interne OVPN Netzwerk auf die 172.16.16.0 passieren lassen und vice versa.
Genau das sind die fehlenden Regeln auf der Endian..!
Hier müssten 2 IP Netze vorhanden sein. Welches interne OVPN Netz (server x.y.z.a Satetemnt in der Konfig Datei !) du benutzt erwähnst du mit keinem Wort Das ist aber essentiell wichtig zu wissen.
Das Verhalten zeigt die fehlenden Regeln eindeutig. Hier solltest du nochmals dein Firewall Logg ansehen. Das zeigt nämlich irgendwie nur immer Broad- und Multicast Pakete die es forwardet.
Das darf so oder so niemals sein, des lässt vermzten das du einen grundsätzlichen Kardinlsfehler begangen hast und Bridging statt Routing im OVPN aktiviert hast.
Das wäre tödlich und davon kann man dir nur dringenst abraten sollte das der Fall sein. OVPN selber empfiehlt hier dringenst auf Routing zu setzen und KEIN Bridging zu machen.
Auch das solltest du in deinem Setup überprüfen.
Das hiesige OVPN Tutorial hilft dabei:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router