10
OVPN mit IPCop 2.1.9 Verbindung steht, grünes Netz nicht erreichbar
Hallo zusammen !
Aufgrund von Festplattenproblemen musste ich einen laufenden IP Cop 2.1.9 neu installieren, der alte läuft noch zum Nachsehen der Einstellungen. Es war also leicht, die Einstellungen identisch abzuschreiben.
Folgende Situation:
Externe IP des Anschlusses ist pingbar.
Internet ausgehend OK.
Eingehend sind Portweiterleitungen für https, http sowie RDP eingerichtet. http wird nicht mehr benutzt. Via https wird auf verschiedenen Ports auf einen Webserver in der DMZ und damit webdav weitergeleitet. Dazu auf ein QNAP NAS in Grün. Alles erfolgreich. => externe IP funktioniert !
OVPN wurde eingerichtet "wie immer" (wir machen das nicht zum ersten Mal), Zertifikate wurden generiert und auf den Client SECUREPOINT importiert. => die VPN-Verbindung funktioniert. (Grüne Lampe)
Man sollte nun mit dem grünen Netz verbunden sein, was bedeutet, dass man IPs im grünen Netz pingen und RDP-Sitzungen aufbauen kann. Doch genau hier liegt der Hase im Pfeffer: beides geht NICHT !
Nota: Internetleitung => FritzBox => IP Cop RED, Ports sind weitergeleitet wie vorher auch.
Die alte IP Cop-Instanz mit ersichtlich denselben Einstellungen macht da keinerlei Probleme.
Ich habe ehrlich gesagt keine Ahnung, was die Ursache sein könnte. Die Pakete kommen anscheinend im OVPN-Subnetz an, denn der Tunnel wird ja aufgebaut, erreichen aber das grüne Netz nicht. Diese Weiterreichung macht der IP Cop normaerweise automatisch, ohne dass da irgendetwas speziell eingestellt werden muß. (Interner Traffic oder dergleichen)
Weiß jemand Rat ?
Gruß Walter
Aufgrund von Festplattenproblemen musste ich einen laufenden IP Cop 2.1.9 neu installieren, der alte läuft noch zum Nachsehen der Einstellungen. Es war also leicht, die Einstellungen identisch abzuschreiben.
Folgende Situation:
Externe IP des Anschlusses ist pingbar.
Internet ausgehend OK.
Eingehend sind Portweiterleitungen für https, http sowie RDP eingerichtet. http wird nicht mehr benutzt. Via https wird auf verschiedenen Ports auf einen Webserver in der DMZ und damit webdav weitergeleitet. Dazu auf ein QNAP NAS in Grün. Alles erfolgreich. => externe IP funktioniert !
OVPN wurde eingerichtet "wie immer" (wir machen das nicht zum ersten Mal), Zertifikate wurden generiert und auf den Client SECUREPOINT importiert. => die VPN-Verbindung funktioniert. (Grüne Lampe)
Man sollte nun mit dem grünen Netz verbunden sein, was bedeutet, dass man IPs im grünen Netz pingen und RDP-Sitzungen aufbauen kann. Doch genau hier liegt der Hase im Pfeffer: beides geht NICHT !
Nota: Internetleitung => FritzBox => IP Cop RED, Ports sind weitergeleitet wie vorher auch.
Die alte IP Cop-Instanz mit ersichtlich denselben Einstellungen macht da keinerlei Probleme.
Ich habe ehrlich gesagt keine Ahnung, was die Ursache sein könnte. Die Pakete kommen anscheinend im OVPN-Subnetz an, denn der Tunnel wird ja aufgebaut, erreichen aber das grüne Netz nicht. Diese Weiterreichung macht der IP Cop normaerweise automatisch, ohne dass da irgendetwas speziell eingestellt werden muß. (Interner Traffic oder dergleichen)
Weiß jemand Rat ?
Gruß Walter
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 41301973401
Url: https://administrator.de/contentid/41301973401
Ausgedruckt am: 24.11.2024 um 04:11 Uhr
10 Kommentare
Neuester Kommentar
moin...
allerdings brauchst du keine Portweiterleitungen für Dienste die über dein VPN laufen sollen.
mach mal die Portweiterleitungen raus...
Frank
Eingehend sind Portweiterleitungen für https, http sowie RDP eingerichtet.
uhhh, da wird mir ganz anders, wenn ich das Lese!Man sollte nun mit dem grünen Netz verbunden sein, was bedeutet, dass man IPs im grünen Netz pingen und RDP-Sitzungen aufbauen kann.
ok, also doch ein VPN allerdings brauchst du keine Portweiterleitungen für Dienste die über dein VPN laufen sollen.
mach mal die Portweiterleitungen raus...
Frank
Eingehend sind Portweiterleitungen HTTP, RDP eingerichtet.
Kollege @Vision2015 hat ja schon alles gesagt. Terminal Sessions und HTTP ungeschützt über das Internet ins lokale Netz zu übertragen ist ein NoGo. Sicherheit sieht, wie oben schon treffend kommentiert, anders aus aber egal...anderes Thema.Auffallend ist das nur HTTP, HTTPS und RDP in der Kaskade geforwardet ist, nicht aber UDP 1194 (OpenVPN). Wie sollen die OpenVPN Frames in so einer Router Kaskade die dahinter kaskadierte Firewall mit dem OpenVPN Server erreichen?
Siehe dazu auch HIER.
Es wäre natürlich, wie oben schon gesagt, barer Unsinn Port geforwardeten Traffic nochmals fürs VPN zu konfigurieren.
Wenn man vernünftigerweise ein VPN nutzt, muss rein gar nichts per Port Forwarding eingetragen werden mit einer Ausnahme und das ist das vom Tunnelprotokoll selber verwendeten Transportprotokoll und das ist bei OpenVPN bekanntlich UDP 1194 im Default.
Vielleicht auch mal ein Punkt das gesamte VPN Konzept grundsätzlich zu überdenken. Mit einer schon sehr in die Jahre gekommenen Firewall ein noch mehr in die Jahre gekommenes VPN mit mieser Skalierbarkeit zu betreiben ist ja etwas aus der Zeit gefallen.
Das geht einfacher und sinnvoller mit den in allen Endgeräten so oder so schon vorhandenen VPN Clients auf IKEv2 oder L2TP Basis:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
L2TP VPN Server mit Mikrotik Router / Firewall
Hallo Frank ! Danke, dass Du antwortest. Und natürlich auch Dank an die anderen Kollegen. Und ich sehe, dass sich unsere Nachrichten sogar überschneiden. Daher noch ein paar kleine Updates.
ein noch paar Worte der Erklärung:
Um es bösen Buben schwieriger zu machen, verwende ich auf dem IP Cop intern wegen Portscans gerne hohe Portadressen > 50000 für den Webserver und das NAS. Das klappt auch problemlos an allen Standorten. (Wir haben das mehrfach an unterschiedlichen Standorten.)
Interessanter sind die Portweiterleitungen, die wir an DIESEM Standort brauchen wegen der gesharten externen IP, welche die Deutsche Glasfaser dort verwendet. Die einzige Möglichkeit der Umsetzuing der Erreichbarkeit dieses Standorts ist, am Netzabschluß zunächst eine FritzBox anzuschließen. Diese erhält tatsächlich eine externe feste IP von einem Zusatzanbieter zugewiesen und ist daher sauber pingbar. Auf diese ext IP sind auch die webadressen bei IONOS geroutet, das funktioniert.
Der IP Cop steckt mit ROT in der Fritzbox (eigenes Subnetz für ROT)
In der FritzBox sind Portweiterleitungen eingetragen für http, https, rdp und vpn und natürlich der OVPN-Port Richtung IP Cop.
Das funktoniert auch, denn sonst kommen die Verbindungen nicht zustande.
Ziel ist beim jetzigen Problem ja, eine OVPN-Verbindung so aufzubauen, dass sie auch nutzbar ist.
Das Problem ist jetzt die OVPN-Verbindung: baut sich zwar erfolgreich auf, aber Grün ist nicht zu erreichen: interne IPs sind weder pingbar noch meldet sich der Anmeldebildschirm bei RDP.
Mit der alten IP Cop-Installation -die nach meinem Denken identisch ist- waren die internen IPs pingbar und RDP hat problemlos verbunden.
Also nochmals klar: INNERHALB des IP Cop gibt es für das GRÜNE Netz keine Portweiterleitungen.
Webserver und NAS stehen in der DMZ.
Sicherheit:
Natürlich sind nur die Webserver und das NAS über Internet erreichbar wegen Zweckbestimmung.
RDP ist nur über VPN möglich, der sich ja auch erfolgreich aufbaut. Bloss eben nicht die RDP-Session.
Gruss Walter
ein noch paar Worte der Erklärung:
Um es bösen Buben schwieriger zu machen, verwende ich auf dem IP Cop intern wegen Portscans gerne hohe Portadressen > 50000 für den Webserver und das NAS. Das klappt auch problemlos an allen Standorten. (Wir haben das mehrfach an unterschiedlichen Standorten.)
Interessanter sind die Portweiterleitungen, die wir an DIESEM Standort brauchen wegen der gesharten externen IP, welche die Deutsche Glasfaser dort verwendet. Die einzige Möglichkeit der Umsetzuing der Erreichbarkeit dieses Standorts ist, am Netzabschluß zunächst eine FritzBox anzuschließen. Diese erhält tatsächlich eine externe feste IP von einem Zusatzanbieter zugewiesen und ist daher sauber pingbar. Auf diese ext IP sind auch die webadressen bei IONOS geroutet, das funktioniert.
Der IP Cop steckt mit ROT in der Fritzbox (eigenes Subnetz für ROT)
In der FritzBox sind Portweiterleitungen eingetragen für http, https, rdp und vpn und natürlich der OVPN-Port Richtung IP Cop.
Das funktoniert auch, denn sonst kommen die Verbindungen nicht zustande.
Ziel ist beim jetzigen Problem ja, eine OVPN-Verbindung so aufzubauen, dass sie auch nutzbar ist.
Das Problem ist jetzt die OVPN-Verbindung: baut sich zwar erfolgreich auf, aber Grün ist nicht zu erreichen: interne IPs sind weder pingbar noch meldet sich der Anmeldebildschirm bei RDP.
Mit der alten IP Cop-Installation -die nach meinem Denken identisch ist- waren die internen IPs pingbar und RDP hat problemlos verbunden.
Also nochmals klar: INNERHALB des IP Cop gibt es für das GRÜNE Netz keine Portweiterleitungen.
Webserver und NAS stehen in der DMZ.
Sicherheit:
Natürlich sind nur die Webserver und das NAS über Internet erreichbar wegen Zweckbestimmung.
RDP ist nur über VPN möglich, der sich ja auch erfolgreich aufbaut. Bloss eben nicht die RDP-Session.
Gruss Walter
Was im Übrigen auch noch heute für den IP Cop spricht ist die wirklich SEHR einfache Handhabung bei der Inbetriebname von Clients bei Mitarbeitern oder Kunden:
Bewährt haben sich die Clients von SECUREPOINT.
Im IP Cop gibt es nach der Erzeugung des Zertifikats den Button "Client Paket herunterladen". Man erhält dann eine ZIP-Datei, welche eine .OVPN enthält.
Diese .OVPN liest man in den SECUREPOINT Client ein und drückt auf den Knopf und ist verbunden.
Keinerlei Gefummel mit irgendwelchen Einstellungen ! => das Ganze ist so einfach, dass auch Mitarbeiter nach Anleitung selbst installieren können. Und genau das ist ein ganz erheblicher Vorteil.
Bewährt haben sich die Clients von SECUREPOINT.
Im IP Cop gibt es nach der Erzeugung des Zertifikats den Button "Client Paket herunterladen". Man erhält dann eine ZIP-Datei, welche eine .OVPN enthält.
Diese .OVPN liest man in den SECUREPOINT Client ein und drückt auf den Knopf und ist verbunden.
Keinerlei Gefummel mit irgendwelchen Einstellungen ! => das Ganze ist so einfach, dass auch Mitarbeiter nach Anleitung selbst installieren können. Und genau das ist ein ganz erheblicher Vorteil.
Hallo,
Gruss,
Peter
Zitat von @MeinGottWalter:
Was im Übrigen auch noch heute für den IP Cop spricht ist die wirklich SEHR einfache Handhabung bei der Inbetriebname von Clients bei Mitarbeitern oder Kunden:
Einfach ist nur eine Frage der DefinitionWas im Übrigen auch noch heute für den IP Cop spricht ist die wirklich SEHR einfache Handhabung bei der Inbetriebname von Clients bei Mitarbeitern oder Kunden:
Keinerlei Gefummel mit irgendwelchen Einstellungen ! => das Ganze ist so einfach, dass auch Mitarbeiter nach Anleitung selbst installieren können. Und genau das ist ein ganz erheblicher Vorteil.**
Schon mal einen Kabelhai bemüht? Dann siehst du dann schwarz auf weiss wo was nicht mehr geht usw. KabelhaiGruss,
Peter
Sicherheit
Nochmals erklärend zum Sinn der Portweiterleitungen im IPCop: diese diene nur dazu, einen Externen zu zwingen, etwa https statt auf Standardport 445 über 56000 anzusprechen. Damit versteckt sich von außen der Anschluß zumindest für Standard-Portscans.
Merke: nach außen geöffnete Ports, die man nicht gefunden hat, können auch nicht angegriffen werden.
Daher sind bei mir nach außen nur "unmögliche" Ports offen, so ab 50000.
Das ist zwar keine Garantie, aber immer noch besser als die Standard-Ports zu verwenden, die -wie der Name sagt- natürlich auch im Range der Standard-Scans liegen.
Gruß an alle !
Walter
Nochmals erklärend zum Sinn der Portweiterleitungen im IPCop: diese diene nur dazu, einen Externen zu zwingen, etwa https statt auf Standardport 445 über 56000 anzusprechen. Damit versteckt sich von außen der Anschluß zumindest für Standard-Portscans.
Merke: nach außen geöffnete Ports, die man nicht gefunden hat, können auch nicht angegriffen werden.
Daher sind bei mir nach außen nur "unmögliche" Ports offen, so ab 50000.
Das ist zwar keine Garantie, aber immer noch besser als die Standard-Ports zu verwenden, die -wie der Name sagt- natürlich auch im Range der Standard-Scans liegen.
Gruß an alle !
Walter
Hallo,
Gruss,
Peter
Zitat von @MeinGottWalter:
Merke: nach außen geöffnete Ports, die man nicht gefunden hat, können auch nicht angegriffen werden.
Falsch Jeder geöffnete Port ist angreifbarMerke: nach außen geöffnete Ports, die man nicht gefunden hat, können auch nicht angegriffen werden.
Daher sind bei mir nach außen nur "unmögliche" Ports offen, so ab 50000.
Was nur eine Sekunde länger dauert diese zu finden. Wie schnell hat ein heutiger Rechner Ports TCP 1 bis 65536 und UDP 1 bis 65536 gescannt? Ernste Gegner wirst du damit nicht aufhalten eher nur SkripkiddiesGruss,
Peter
Hallo Peter !
Das ist mir auch klar. Viel mehr Schutz gibt das nicht. .-))
Ich mußte nur wegen der Vermutungen der Kollegen erklären, wozu es diese Portweiterleitungen im IP Cop überhaupt gibt. Denn das wurde mißverstanden.
Etwas anderes sind die Portweiterleitungen in der FritzBox Richtung IP Cop: diese werden benötigt, damit die entsprechenden Dienste den IP Cop überhaupt erreichen.
Gruß Walter
Das ist mir auch klar. Viel mehr Schutz gibt das nicht. .-))
Ich mußte nur wegen der Vermutungen der Kollegen erklären, wozu es diese Portweiterleitungen im IP Cop überhaupt gibt. Denn das wurde mißverstanden.
Etwas anderes sind die Portweiterleitungen in der FritzBox Richtung IP Cop: diese werden benötigt, damit die entsprechenden Dienste den IP Cop überhaupt erreichen.
Gruß Walter
Die Krux ist ja, dass das Ganze mit der alten IP Cop-Installation jahrelang anstandslos funktionierte !
Jetzt ist die Frage berechtigt: warum dann überhaupt eine neue Installtion ?
Antwort: die alte Installation ist anscheinend in der Auflösung begriffen: vorhandene OVPN-Zertifikate funktionieren zwar nach wie vor, werden aber in der Liste gar nicht mehr angezeigt. Und der Versuch, ein neuen Zertifikat zu erstellen, läuft auf einen Fehler.
Grund dafür könnte sein, dass der alte IP Cop als VM auf einem SSD-RAID5 unter VMware auf SuperMicro-Hardware installiert ist. Damit haben wir an einem anderen Standort bereits ganz üble Erfahrungen mit einem Emailserver 2008R2 gemacht: man installiert und alles läuft problemlos ... die ersten 14 Tage. Danach stellt man per chkdsk plötzlich fest, dass die VM Festplattenfehler bekommt, die man zu reparieren versucht ... und bei jedem chkdsk-Lauf hat man hinterher mehr Fehler als vorher. Bis die Instanz so instabil wurde, dass gar nichts mehr lief.
Und diesen Verdacht habe ich jetzt auch, was den IP Cop anbelangt. Daher eine Neuinstallation auf dem HDD-RAID10+Hotspare, welches die SuperMicro-Hardware auch hat als Haupt-DataStore.
Ich kann also beide Installationen, die alte und die neue, parallel laufen lassen, wenn ich auf der jeweils nicht scharfen Installation ORANGE und RED deaktiviere und GREEN eine andere IP verpasse und kann dann schön vergleichen.
Alles scheint zu passen und auf der neuen Installation kann ich natürlich auch wieder Zertifikate generieren und der OVPN verbindet auch. Bloss benutzen lässt er sich nicht .. hin zum grünen Netz.
Gruß Walter
Jetzt ist die Frage berechtigt: warum dann überhaupt eine neue Installtion ?
Antwort: die alte Installation ist anscheinend in der Auflösung begriffen: vorhandene OVPN-Zertifikate funktionieren zwar nach wie vor, werden aber in der Liste gar nicht mehr angezeigt. Und der Versuch, ein neuen Zertifikat zu erstellen, läuft auf einen Fehler.
Grund dafür könnte sein, dass der alte IP Cop als VM auf einem SSD-RAID5 unter VMware auf SuperMicro-Hardware installiert ist. Damit haben wir an einem anderen Standort bereits ganz üble Erfahrungen mit einem Emailserver 2008R2 gemacht: man installiert und alles läuft problemlos ... die ersten 14 Tage. Danach stellt man per chkdsk plötzlich fest, dass die VM Festplattenfehler bekommt, die man zu reparieren versucht ... und bei jedem chkdsk-Lauf hat man hinterher mehr Fehler als vorher. Bis die Instanz so instabil wurde, dass gar nichts mehr lief.
Und diesen Verdacht habe ich jetzt auch, was den IP Cop anbelangt. Daher eine Neuinstallation auf dem HDD-RAID10+Hotspare, welches die SuperMicro-Hardware auch hat als Haupt-DataStore.
Ich kann also beide Installationen, die alte und die neue, parallel laufen lassen, wenn ich auf der jeweils nicht scharfen Installation ORANGE und RED deaktiviere und GREEN eine andere IP verpasse und kann dann schön vergleichen.
Alles scheint zu passen und auf der neuen Installation kann ich natürlich auch wieder Zertifikate generieren und der OVPN verbindet auch. Bloss benutzen lässt er sich nicht .. hin zum grünen Netz.
Gruß Walter
Kaum macht man's richtig, klappt's auch schon !
Ich habe mein Problem gelöst !
In den "erweiteren OVPN-Servereinstellungen" des IP Cop gibt es tatsächlich Optionen, die darüber entscheiden, in welches Netz (grün, orange) die auf dem etablierten VPN hereinkommenden Pakete weitergeleitet werden sollen.
Wenn dort "Grün" nicht zur Durchreichung angeklickt ist, kommt in Grün auch nichts an ! => kein Pingen grüner Adressen und keinen RDP-Anmeldebeldschirm.
Klarer Vergleichsfehler von mir: ich hatte dort nicht reingekuckt und auswendig nicht mehr auf dem Schirm, dass dort diese Einstellung vorzunehmen ist.
Vielen Dank an die Kollegen, die sich Mühe gemacht haben !
Herzlicher Gruß
Walter
Ich habe mein Problem gelöst !
In den "erweiteren OVPN-Servereinstellungen" des IP Cop gibt es tatsächlich Optionen, die darüber entscheiden, in welches Netz (grün, orange) die auf dem etablierten VPN hereinkommenden Pakete weitergeleitet werden sollen.
Wenn dort "Grün" nicht zur Durchreichung angeklickt ist, kommt in Grün auch nichts an ! => kein Pingen grüner Adressen und keinen RDP-Anmeldebeldschirm.
Klarer Vergleichsfehler von mir: ich hatte dort nicht reingekuckt und auswendig nicht mehr auf dem Schirm, dass dort diese Einstellung vorzunehmen ist.
Vielen Dank an die Kollegen, die sich Mühe gemacht haben !
Herzlicher Gruß
Walter
