Endian OpenVPN Probleme mit RDP
Hallo zusammen,
kurz zu meinem Sachverhalt damit Ihr euch in mein Problem ein wenig reinversetzen könnt.
Habe extern eine Endian Firewall (Community Edition) im Server Housing und möchte diese als Gateway für ein virtuelles System nutzen. Ich möchte mich auf das Windows 7 per RDP aufschalten können, da hier einzelne Programme laufen die ich unterwegs benötige. Bisher ist der Port durch eine NAT-Regel einfach offen ->3389 auf interne IP 178.25.25.2
So jetzt habe ich an der Endian den OpenVPN Server aktiviert, das CA heruntergeladen und auch unten eingerichtet und dan gesagt "Push auf grüne Schnittstelle" (da befindet sich der CLient).
Hab auch meine ovpn Datei erstellt und mein System verbindet sich auch und erhält aus dem Adresspool auch eine interne IP Nummer. Kann dann über cmd auch mein Gateway anpingen 178.25.25.2
Wenn ich aber meinen Windows 7 Client anpingen will kommt erst FEHLER HOST NICHT ERREICHBAR.
Im Windows 7 habe ich icmp zugelassen und auch die RDP Einstellungen vorgenommen (von draußen per NAT komme ich ja drauf).
Hat jemand eine Idee? Die interne Schnittstelle meines VPN kann ich anpingen, aber komme auf keine anderen "Netzteilnehmer".
GLG
kurz zu meinem Sachverhalt damit Ihr euch in mein Problem ein wenig reinversetzen könnt.
Habe extern eine Endian Firewall (Community Edition) im Server Housing und möchte diese als Gateway für ein virtuelles System nutzen. Ich möchte mich auf das Windows 7 per RDP aufschalten können, da hier einzelne Programme laufen die ich unterwegs benötige. Bisher ist der Port durch eine NAT-Regel einfach offen ->3389 auf interne IP 178.25.25.2
So jetzt habe ich an der Endian den OpenVPN Server aktiviert, das CA heruntergeladen und auch unten eingerichtet und dan gesagt "Push auf grüne Schnittstelle" (da befindet sich der CLient).
Hab auch meine ovpn Datei erstellt und mein System verbindet sich auch und erhält aus dem Adresspool auch eine interne IP Nummer. Kann dann über cmd auch mein Gateway anpingen 178.25.25.2
Wenn ich aber meinen Windows 7 Client anpingen will kommt erst FEHLER HOST NICHT ERREICHBAR.
Im Windows 7 habe ich icmp zugelassen und auch die RDP Einstellungen vorgenommen (von draußen per NAT komme ich ja drauf).
Hat jemand eine Idee? Die interne Schnittstelle meines VPN kann ich anpingen, aber komme auf keine anderen "Netzteilnehmer".
GLG
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 331807
Url: https://administrator.de/contentid/331807
Ausgedruckt am: 22.11.2024 um 17:11 Uhr
11 Kommentare
Neuester Kommentar
über cmd auch mein Gateway anpingen 178.25.25.2
Wieso pingst du deine öffentliche IP, das ist beim OpenVPN doch unsinn, denn der Server wird üner seine interne OpenVPN IP erreicht. Das ist die IP Adresse diur du mit server xyz in der server.conf Datei definiert hast.Das sollte tunlichst eine RFC 1918 IP sein und natürlich keine öffentliche !
Warum also unsinigerweise die öffentliche Tunnel IP ??
Dein Problem ist vermutlich die per default deaktivieerte Client to Client Kommunikation. Dazu musst du ein client-to-client in der server.conf Datei hinzufügen und den OVPN Daemon neu starten.
Das sollte dein Problem fixen.
Beachte auch das die lokale Windows Firewall dein Netzwerk als öffentlich deklariert und damit dann jeglichen Connect Versuch von außen blockt !!
Du kannst also NICHT von außen via Tunnel Netz zugreifen auf den Client as die Firewall das im öffentlichen Profil strikt blockiert.
Hierfür musst du die Firewall zwingend anpassen. (Firewall mit erweiterten Eigenschaften...)
Hallo,
Meistens so
Gruß,
Peter
Meistens so
und wenn ich die mit rdp bisher anspreche komm ich wegen dem Forwarding auf das interne System 172.16.16.2
RDP direkt aus dem Internet auf den Server /Rechner ist eher tödlich, aber willst du jetzt per VPN abstellen.Die interne Schnittstelle der Firewall ist 172.16.16.1. Wenn ich jetzt mit OpenVPN eine Verbindung aufbaue wird mir die 172.16.16.3 zugewiesen und ich kann nach dem aufbauen die 172.16.16.1 einpingen aber nicht die 172.16.16.2.
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.
Gruß,
Peter
keine Ahnung was du wo und wie siuchst. Sorry.
Hab auch schon ausschau gehalten
Wonach?außer fleissig versuche per RDP über NAT draufzukommen wirklich nichts auffälliges
?!?Wireshark vom "Pingenden" PC übergibt nur rausgegangen aber keine Antwort bekommen.
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.Pinge ich von meinem Lokalen PC (172.16.16.3) das entfernte an 172.16.16.2 kommt: Antwort von: 172.16.16.3: Zielhost nicht erreichbar
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.RDp geht auch nicht
hast du nicht RDP die ganze zeit genutzt per Portweiterleitung? das geht nicht mehr?aber meine Firewall loggt auch nicht wirklich was`!`!
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:
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
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:
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.
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
Ü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 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.
Mich macht eben stutzig das ich nach Aufbau der VPN Leitung auf 172.16.16.1 von meinem PC aus zugreifen kann aber auf 172.16.16.2 weder ICMP Pakete senden noch auf RDP zugreifen kann.
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
Hallo,
https://technet.microsoft.com/de-de/library/cc731634%28v=ws.11%29.aspx
https://technet.microsoft.com/de-de/library/getting-started-wfas-firewal ...
https://www.windowspro.de/wolfgang-sommergut/firewall-windows-7-regeln-f ...
https://www.windows-7-forum.net/threads/windows-firewall-oeffentliches-p ...
http://www.tech-faq.net/windows-server/netzwerktyp-aendern-windows-serv ...
http://unsicherheitsblog.de/windows-10-netzwerk-von-offentlich-auf-priv ...
Gruß,
Peter
Zitat von @Sunny89:
Und die Firewall von Windows OS war auch Privat 3389 zulassen gesetzt daher kam ich dann auch nicht drauf.
Wenn 3389 (RDP) für Privat zugelassen war warum soll das dann nicht geklappt haben? Deine aussage RDP (3389) Privat zugelassen deshalb ging es nicht - widerspricht sich selbst...Und die Firewall von Windows OS war auch Privat 3389 zulassen gesetzt daher kam ich dann auch nicht drauf.
Nun meine Frage warum meint hier Windows OS "öffentlich"? Eigtl. sollte e ssich ja verhalten wie ein lokales Netz?
Wie hast du denn dein Netz bzw. die Firewall beim allerersten mal definiert bzw. eingerichtet als du dein Server System RDP das erstemal eingeschaltet hast?https://technet.microsoft.com/de-de/library/cc731634%28v=ws.11%29.aspx
https://technet.microsoft.com/de-de/library/getting-started-wfas-firewal ...
https://www.windowspro.de/wolfgang-sommergut/firewall-windows-7-regeln-f ...
https://www.windows-7-forum.net/threads/windows-firewall-oeffentliches-p ...
http://www.tech-faq.net/windows-server/netzwerktyp-aendern-windows-serv ...
http://unsicherheitsblog.de/windows-10-netzwerk-von-offentlich-auf-priv ...
Gruß,
Peter