OpenVPN Installation Routing Problem

Mitglied: intane

intane (Level 1) - Jetzt verbinden

08.02.2018 um 13:31 Uhr, 3360 Aufrufe, 48 Kommentare

Huhu,

ich habe Schwierigkeiten bei der Installation von OpenVPN auf einen Win10 Rechner.
Auf dem Rechner ist eine Software installiert, die dann auch von außerhalb bedient werden soll.

Ich habe laut den alten Anleitungen von datasearch und dem HOWTO auf der Seite, die Installation durchgeführt mit den jeweiligen Zertifikaten (ca,vars, server.ovpn, client.ovpn, dh).

Auch OpenSSL installiert, da es laut den Anleitungen auch mir nicht ganz klar war wie ich die openssl.cnf konfigurieren soll.

Beigefügt das Netzwerk in dem der Rechner ist und das Log von dem Rechner außerhalb der darauf zugreifen soll.

network - Klicke auf das Bild, um es zu vergrößern

log - Klicke auf das Bild, um es zu vergrößern

Ich vermute der Fehler liegt beim Routing bzw. bei der Portfreigabe bei den beiden Routern.

Auf der Fritzbox hab ich den UDP Port freigeben aber kann leider nicht die Route zum 10.8.8.1 OVPN Netzwerk freigeben (Fehlermeldung: Die Route ist nicht zulässig).

Müsste ich beim Zyxel Router auch den UDP Port freigeben bzw. auch die Route zum OVPN Netzwerk?


Danke für die Rückmeldungen schon mal.


Gruß
intane
48 Antworten
Mitglied: walle1979
08.02.2018 um 14:21 Uhr
Hallo intane,

wenn du eine Routerkaskade hast (so sehe ich das zumindest im Bild), musst du auf beiden Routern den Port durchreichen...

Gruß Walle
Bitte warten ..
Mitglied: intane
08.02.2018 um 15:06 Uhr
Alles klar, also bei beiden den UDP Port.

Dachte aber, dass auch die Route wichtig ist, so habe ich zumindest bei anderen Konfigurationen gesehen.


Gruß
intane
Bitte warten ..
Mitglied: orcape
09.02.2018 um 16:24 Uhr
Hi,
handelt es sich um einen OpenVPN-Client auf dem Win10-PC, ist ein durchreichen des UDP-Ports nicht notwendig. Bei einem OpenVPN-Server schon und das auf beiden Routern.
...mit den jeweiligen Zertifikaten.
...hier wird wohl Dein Problem liegen. (selbst erstellt?) Du kannst an den Log-Einträgen einen TLS-Fehler erkennen, der wohl ein Problem mit Deinen Zertifikaten vermuten lässt.
Gruss orcape
Bitte warten ..
Mitglied: aqui
09.02.2018, aktualisiert um 17:47 Uhr
Sieh dir doch mal dein Log an !
Dein TLS Key Handshake scheitert beim VPN Aufbau !!
Es kommt also erst gar kein VPN Tunnel zustande ! Kollege orcape hats oben schon gesagt: Da stimmt also was mit deinen Zertifikaten nicht.
Port Forwarding scheint zu gehen, denn sonst würdest du die Log Einträge gar nicht erst sehen !

Ggf. hilft dir dieses Tutorial weiter was die Zertifikatsgenerierung anbetrifft. Die ist auf allen OVPN Plattformen immer gleich !
https://www.administrator.de/wissen/openvpn-server-installieren-dd-wrt-r ...
Bitte warten ..
Mitglied: intane
14.02.2018 um 11:10 Uhr
handelt es sich um einen OpenVPN-Client auf dem Win10-PC, ist ein durchreichen des UDP-Ports nicht notwendig. Bei einem OpenVPN-Server schon und das auf beiden Routern.

ah ok das ist schon mal gut zu wissen.


...hier wird wohl Dein Problem liegen. (selbst erstellt?) Du kannst an den Log-Einträgen einen TLS-Fehler erkennen, der wohl ein Problem mit Deinen Zertifikaten vermuten lässt.

Zertifikate noch einmal neu erstellt, leider Fehler besteht.

Dein TLS Key Handshake scheitert beim VPN Aufbau !!
Es kommt also erst gar kein VPN Tunnel zustande ! Kollege orcape hats oben schon gesagt: Da stimmt also was mit deinen Zertifikaten nicht.

Ggf. hilft dir dieses Tutorial weiter was die Zertifikatsgenerierung anbetrifft. Die ist auf allen OVPN Plattformen immer gleich !
https://www.administrator.de/wissen/openvpn-server-installieren-dd-wrt-r ...

Zertifikate noch einmal neu erstellt, leider der selbe Fehler.
Anbei diesmal auch das Server Log.

Options error: --cert fails with 'c://programm eopenvpneasy-rs akeys server(Name geändert).crt': No such file or directory (errno=2)
WARNING: cannot stat file 'c://programm eopenvpneasy-rs akeysserver.key': No such file or directory (errno=2)
Options error: --key fails with 'c://programm eopenvpneasy-rs akeysserver.key'
Options error: Please correct these errors.

Außerdem..pkcs11_protected_authentication = DISABLED
Tue Feb 13 13:37:43 2018 us=303614 Could not determine IPv4/IPv6 protocol. Using AF_INET
Tue Feb 13 13:37:43 2018 us=303614 Socket Buffers: R=[65536->65536] S=[65536->65536]
Tue Feb 13 13:37:43 2018 us=303614 TCP/UDP: Socket bind failed on local address [AF_INET]192.168.188.105:1194
Tue Feb 13 13:37:43 2018 us=303614 Exiting due to fatal error


Der CN muss bei der CA und beim Server Zertifikat gleich sein, richtig?
Muss die CA irgendwie signiert werden? Weil nur beim Server Zertifikat am Ende gefragt wird..

Bevor ich das Server Zertifikat erstelle, kommt der folgende Hinweis:
Using configuration from ...\easy-rsa\openssl.cnf

Diese config habe ich nicht selber erstellt..

Sonnst habe ich die die dh2048 in dem Config Ordner gespeichert zusammen mit der server.ovpn Datei, das Server und Client Zertifikat im Ordner keys gelassen

Vermute ob ich mit SSL etwas noch einstellen muss...


Danke für die Beiträge bisher !
Bitte warten ..
Mitglied: aqui
14.02.2018, aktualisiert um 16:03 Uhr
TCP/UDP: Socket bind failed on local address
Das zeugt NICHT von einem Zertifikatsproblem !
Da stimmt irgendwas grundsätzlich mit dem Zugriff auf die Adapter Hardware nicht !
Kann das sein das du den OVPN ohne Admin Rechte laufen lässt ?? Das scheitert dann natürlich da der unzureichende Rechte für die Systemkomponenten besitzt !
Vermute ob ich mit SSL etwas noch einstellen muss...
Nein ! Zertifikatsfehler tauchen ja laut Log nicht auf.
Nur wenn der OVPN Server hinter einem NAT Router steht musst du UDP 1194 auf die lokale OVPN Server LAN IP am Router forwarden. Guckst du auch hier:
https://www.administrator.de/wissen/openvpn-server-installieren-dd-wrt-r ...
Bitte warten ..
Mitglied: intane
15.02.2018 um 15:14 Uhr
Da stimmt irgendwas grundsätzlich mit dem Zugriff auf die Adapter Hardware nicht !
Kann das sein das du den OVPN ohne Admin Rechte laufen lässt ?? Das scheitert dann natürlich da der unzureichende Rechte für die Systemkomponenten besitzt !

Beim Client richte ich grundsätzlich immer ein, dass OVPN als Administrator gestartet werden soll.

Der Tunneladapter ist auf der Host Seite mit "openvpn" gekennzeichnet und auf Client Seite mit "TAP" auf der Server.ovpn dann dementsprechend mit "dev tap" und "dev-node openvpn".

noch ein aktueller Ausschnitt vom Serverlog
Bitte warten ..
Mitglied: aqui
15.02.2018, aktualisiert um 16:40 Uhr
Das Problem "Could not determine IPv4/IPv6 protocol. Using AF_INET" resultiert daraus das deine Server Konfig nicht sauber ist in der Beziehung das du NICHT genau spezifiziert hast welches Protokoll v4 oder v6 OVPN binden soll. Siehe auch:
https://forums.openvpn.net/viewtopic.php?t=23451

Dazu gibt es 2 Lösungen:
1.) Du entfernst komplett den IPv6 Support von den Interfaces
2.) Du spezifizierst genau welche Protokoll du verwenden willst im Server. proto udp4

Letzterer ist natürlich die saubere Variante. Bei dir weiß OVPN nicht welches Protkoll es nehmen soll und nimmt dann das was das OS bevorzugt wenn du mit Dual Stack arbeitest. Bei Winblows ist das dann IPv6 wofür dir dann aber wiederum weitere Konfig Parameter fehlen.
Deshalb geht das Binding bei dir schief und damit dann das ganze VPN.
Bitte warten ..
Mitglied: intane
16.02.2018 um 11:19 Uhr
2.) Du spezifizierst genau welche Protokoll du verwenden willst im Server. proto udp4

Auf der server.ovpn und client.ovpn eingerichtet, leider immer noch nicht weiter gekommen.

Die server.ovpn

Die client.ovpn

Bei Server und Client Adaptern die ipv6 Option deaktiviert.

Beim Server Client ist allerdings der Adapter entfernt, ist das normal wenn da keine Verbindung besteht?
9 - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: orcape
17.02.2018 um 08:19 Uhr
Nun kennen wir erst einmal die Server- und Client.conf von OpenVPN, gibt es da vielleicht auch schon Routing-Protokolle, die auf ein Zustande kommen eines Tunnels hinweisen?
Im übrigen baust Du mit "client-to-client einen Multiclienttunnel auf, ist das so beabsichtigt? Wenn nicht, ist das kontraproduktiv.
Einen ccd-Eintrag, der auf ein File hinweist, dessen Inhalt auf ein zu erreichendes Netz hinter der Fritzbox verweist, gibt es in der Server.conf auch nicht.
Du hast hier wohl nicht nur ein Problem, warum das ganze nicht funktioniert.
Auch wenn Dein Windows10 OpenVPN kann, würde ich das über die Routerkaskade etwas anders angehen, es sei denn, es ist ein Laptop mit dem die Verbindung auch unterwegs notwendig wäre. Ich würde den OpenVPN-Client auf dem, der Fritte vorgelagerten Router terminieren und den Zugriff auf den Win10 per Routing und Firewall sicherstellen.
Die Frage stellt sich nur, ob der Zyxel das kann oder ob er per alternativer Firmware (DD-WRT / OpenWRT) dazu gebracht werden kann.
Gruss orcape
Bitte warten ..
Mitglied: intane
19.02.2018 um 16:39 Uhr
Nun kennen wir erst einmal die Server- und Client.conf von OpenVPN, gibt es da vielleicht auch schon Routing-Protokolle, die auf ein Zustande kommen eines Tunnels hinweisen?
Leider noch nicht

Im übrigen baust Du mit "client-to-client einen Multiclienttunnel auf, ist das so beabsichtigt? Wenn nicht, ist das kontraproduktiv.
Die Server.conf wurde von einer bestehenden funktionierenden OVPN Verbindung übernommen und halt angepasst..
Bei der bestehenden Verbindung ist der Unterschied, dass sie mittels WinServer zustande kommt.

Einen ccd-Eintrag, der auf ein File hinweist, dessen Inhalt auf ein zu erreichendes Netz hinter der Fritzbox verweist, gibt es in der Server.conf auch nicht.
Wie würde so ein Eintrag in der conf aussehen?

Auch wenn Dein Windows10 OpenVPN kann, würde ich das über die Routerkaskade etwas anders angehen, es sei denn, es ist ein Laptop mit dem die Verbindung auch unterwegs notwendig wäre.
Ne ist ein Standrechner.
Was wäre optimierungsbedürftig?

Ich würde den OpenVPN-Client auf dem, der Fritte vorgelagerten Router terminieren und den Zugriff auf den Win10 per Routing und Firewall sicherstellen.
Die Frage stellt sich nur, ob der Zyxel das kann oder ob er per alternativer Firmware (DD-WRT / OpenWRT) dazu gebracht werden kann.
Leider darf ich den Zyxel nicht allzu viel konfigurieren, außer halt das nötige Routing, da er von einer anderen Firma bereitgestellt wird.
Routing wurde aber bisher auf dem Zyxel noch nicht vorgenommen. Also wäre ein Routing vom Zyxel zur Fritzbox bzw. zum Rechner dann doch sinnvoll.
Bitte warten ..
Mitglied: aqui
20.02.2018, aktualisiert um 16:45 Uhr
Die Server.conf wurde von einer bestehenden funktionierenden OVPN Verbindung übernommen und halt angepasst..
Die Konf und die Änderungen wären sehr hilfreich für einen zielführende Hilfe hier !
Leider darf ich den Zyxel nicht allzu viel konfigurieren,
Ein Port Forwarding des OVPN Ports UDP 1194 ist da aber zwingend notwendig !!
Routing ist nicht erforderlich wenn die Kaskade 2maliges NAT macht, also doppelte Adress Translation.
Routen muss man nur wenn der Kaskaden Router kein NAT macht.
Hier werden dir diese beiden Szenarien und die Unterschiede der Konfig genau erklärt:
https://www.administrator.de/wissen/routing-2-ip-netzen-windows-linux-ro ...
Also wäre ein Routing vom Zyxel zur Fritzbox bzw. zum Rechner dann doch sinnvoll.
Einzig nur dann wenn der kaskadierte Router KEIN NAT macht am WAN Port der zum Zyxel geht !!! Nur dann (und wirklich nur dann !) ist ein Routing auf dem Zyxel erforderlich.
Macht er NAT ist ein Routing am Zyxel überflüssig und auch Unsinn !
Siehe Tutorial !! (Thema ICS)
Bitte warten ..
Mitglied: intane
28.02.2018 um 17:07 Uhr
Die Konf und die Änderungen wären sehr hilfreich für einen zielführende Hilfe hier !

anbei die "funktionierende Server conf, folgend von deren client.conf

Windows Server 2008r2

Die neu erzeugte server.conf mit ihrer client.conf.

Windows 10 x64

Die Änderungen sind lediglich, dass die Domain wegfällt und proto udp4..
Bitte warten ..
Mitglied: orcape
28.02.2018 um 18:49 Uhr
Was ein tun/tap-Device ist, solltest Du wissen.
https://www.thomas-krenn.com/de/wiki/OpenVPN_Grundlagen
Ich glaube hier ist in den configs so einige im argen.
Du musst Dich entscheiden, ob Du das tap-Device verwenden möchtest, welches eine Verbindung auf Layer 2 Basis darstellt, oder ob Du routen willst und das tun-Device nimmst.
Beides in einem Tunnel wird wohl nicht funktionieren.
Gruss orcape
Bitte warten ..
Mitglied: aqui
01.03.2018, aktualisiert um 09:22 Uhr
Von tap kann man nur dringenst abraten. Das ist dann Layer 2 Bridging und damit holt man sich den gesamten Broad- und Unicast Traffic des Netzes mit auf den VPN Tunnel was dann zu massiven Performance Problemen führen kann.
Selbst das offizielle OpenVPN HowTo rät deshalb dringenst davon ab und es nur dann einzusetzen wenn man es wirklich zwingend muss und das ist so gut wie nie der Fall.
Bitte warten ..
Mitglied: intane
15.03.2018, aktualisiert um 10:20 Uhr
Sry für die späte Antwort, in der letzten Zeit bisschen mit FritzVPN beschäftigt und da die Möglichkeiten recherchiert.

Von tap kann man nur dringenst abraten. Das ist dann Layer 2 Bridging und damit holt man sich den gesamten Broad- und Unicast Traffic des Netzes mit auf den VPN Tunnel was dann zu massiven Performance Problemen führen kann.

Die OpenVPN Verbindung klappt nun nach paar Modifikationen (Zyxel Router rausgenommen, FritzBox direkt ans Netz gehängt).
Leider halt mit TAP. Da ich noch keine Erfahrung mit TUN bisher hatte.

Wie realisiert sich der Umstieg auf TUN, einfach im Editor, TUN aktivieren und den Adapter umbenennen?

Anbei nun der funktionierende Log.

Server

Client
Auffälig ist der Fehler: PID_ERR replay-window backtrack occurred
und dhcp-option: unknown option type.
Bitte warten ..
Mitglied: aqui
16.03.2018, aktualisiert um 18:39 Uhr
Bridging mit tap ist tödlich für die Performance. Ist auch klar, denn dann belastet der gesamten Broad- und Multicast Traffic beider Seiten massiv den VPN Tunnel.
Deshalb rät auch OpenVPN immer vom Bridging ab und empfiehlt grundsätzlich ein Routing über tun Interfaces.
Es gilt die alte Regel: "Route where you can, bridge where you must" !
Wie realisiert sich der Umstieg auf TUN, einfach im Editor, TUN aktivieren und den Adapter umbenennen?
Ja !
Halte dich an dies Tutorial:
https://www.administrator.de/wissen/openvpn-server-installieren-dd-wrt-r ...
Die OVPN Konfig ist auf allen Plattformen immer gleich.
Bitte warten ..
Mitglied: intane
20.03.2018 um 16:10 Uhr
Ja !
Alles klar, werde mal angehen.

Die OVPN Konfig ist auf allen Plattformen immer gleich.

Alles klar, mir sind ein paar Änderungen aufgefallen auf deinem Tutorial.

Auf der Server Konfig
Fehlt bei dir, ist das nicht notwendig in einem Netzwerk ohne Server?

Fehlt auch, bei TUN nicht notwendig?

Fehlt auch, denke nicht erforderlich.
Client Konfig
Fehlt denke auch weil du bei der Server Konfig es weggelassen hast.
Fehlt ebenfalls wie auch oben bei der Server Konfig.


Seit gestern habe ich auch die neue OVPN Version 2.4.5 installiert allerdings konnte keine Verbindung aufbauen, deswegen wieder auf die ältere zurückgesetzt.

Die Fehlermeldungen waren:
Müsste ich die CA neu erstellen mit einer neueren OpenSSL Version?
Bitte warten ..
Mitglied: aqui
20.03.2018 um 17:06 Uhr
Fehlt bei dir, ist das nicht notwendig in einem Netzwerk ohne Server?
Was genau meinst du mit "Netzwerk ohne Server" ??? Ohne VPN Server ? Sowas gibts ja nicht ?
Aber was für einen "Server" meinst du denn ??
VPNs gehören eigentlich auch niemals ins Netz sondern auf die Peripherie wie Router oder Firewall. Logisch, denn mit einem internen Server musst du Löcher in die Firewall bohren um Internet Traffic (VPN) auf den Server zu lassen.
Immer ein suboptimales Design wie du dir denken kannst !
Die TLS Role Zuweisung kann man machen...muss es aber nicht. In eine klassische Konfig muss es nicht zwingend rein:
https://jankarres.de/2013/05/raspberry-pi-openvpn-vpn-server-installiere ...
Der dev-node ist überflüssig wenn man empfohlenermaßen routet mit tun, kann also ersatzlos entfallen.
client-to-client muss nur rein wenn man auch eine direkte Kommunikation der VPN Clients untereinander will.
Bei einem rein zentralisierten VPN also Client immer auf Server kann das natürlich entfallen. Ist auch immer eine Security Frage und muss man nach Anwendung und Sicherheit immer individuell entscheiden.

Die CA muss normalerweis enicht neu wenn du Root Zert. sowie Server und Client Zert gesichert hast. Es kann aber nicht schaden.
Deinen Fehlermeldung sagt das das Zertifikat gar nicht geladen werden konnte. Entweder weil es fehlt oder der Pfad dahin unbekannt oder verboten ist.
Da ist natürlich klar das eine Verbindung sofort scheitert wenn es schon an solchen einfachen Basics hapert
Das Karres Tutorial beschreibt diese Schritte ja auch nochmals genau.
Bitte warten ..
Mitglied: orcape
20.03.2018 um 19:02 Uhr
Die OVPN Konfig ist auf allen Plattformen immer gleich.
Richtig, das Prinzip ist gleich, nur ist bei den Pfaden nicht immer alles identisch. Hier bestehen Unterschiede, z.B. zwischen Linux und FreeBSD-Plattformen, wie beispielsweise zwischen einem DD-WRT Router und einer pfSense.
Bei der Übernahme einer Fremd-config ist also Vorsicht geboten. Also nicht vergessen die Pfade zu prüfen.
Hier einmal als Vergleich die Server.conf eines pfSense (FreeBSD) OpenVPN unter /var/etc/openvpn/server1
Dabei verweist folgende Zeile auf ein File, welche Informationen für den Client übergibt.
client-config-dir /var/etc/openvpn-csc/server1
Hier die Config eines dazu gehörigen OpenVPN-Client, eines Linux-Routers auf OpenWRT-Basis, bei dem OpenVPN unter /etc/openvpn zu finden ist. Die Pfade bei einer DD-WRT sind dann z.B. unter /tmp/zu finden.
Bei Dir scheint ein TLS-Fehler vorzuliegen, also poste noch einmal die aktuelle config. So bald Du den Tunnel zum laufen gebracht hast, wären auch die Routing-Protokolle interessant.
Gruss orcape
Bitte warten ..
Mitglied: intane
21.03.2018, aktualisiert 12.04.2018
Was genau meinst du mit "Netzwerk ohne Server" ??? Ohne VPN Server ? Sowas gibts ja nicht ?
Mit Server meinte ich eher, ein Netzwerkdomäne, was bei mir ja nicht der Fall ist, auf der neuen Konfiguration.
Von da wo ich die Einstellungen übernommen habe war es eine Netzwerkdomäne.


Deinen Fehlermeldung sagt das das Zertifikat gar nicht geladen werden konnte. Entweder weil es fehlt oder der Pfad dahin unbekannt oder verboten ist.
Das interessante ist, dass mit der Version 2.4.4 die Verbindung zustande kommt mit den folgenden Fehlermeldungen:
Nach dem update auf 2.4.5
dann die folgenden, wie oben gepostet und die Verbindung mit den selben Konfigs klappt nicht:
Da ist eine Änderung mit dem Update die, die Passwort Abfrage verhindert, bei unveränderten Konfigs.
Bitte warten ..
Mitglied: intane
21.03.2018 um 17:21 Uhr
Bei Dir scheint ein TLS-Fehler vorzuliegen, also poste noch einmal die aktuelle config. So bald Du den Tunnel zum laufen gebracht hast, wären auch die Routing-Protokolle interessant.
Ok, komischerweise, wie erwähnt erst ab der 2.4.5 Version

Die Konfigs sind gleich geblieben wie oben gepostet:

Server
Gruß
intane
Bitte warten ..
Mitglied: aqui
22.03.2018, aktualisiert um 09:40 Uhr
Von da wo ich die Einstellungen übernommen habe war es eine Netzwerkdomäne.
Das ist für OpenVPN eh uninteressant, da es nichts von MS und "Domänen" kennt, diese also quasi ignoriert.
dass mit der Version 2.4.4 die Verbindung zustande kommt mit den folgenden Fehlermeldungen:
Das ist schon mal gut !
Nach dem update auf 2.4.5
OK, er meckert das 128Bit Schlüssel etwas schwach sind und empfiehlt dir hier 256 was ja heute Standard ist. Das ist aber nur ne Warnung.
Gravierender ist "Cannot load certificate file C:\\Program Files\\OpenVPN\\config\\Tzanoudakis.crt"
Denn das sagt ja ganz klar das er auf das Zertifikat NICHT zugreifen kann.
Entweder gibt es also
  • den Pfad dahin "C:\Program Files\OpenVPN\config\" gar nicht bzw. die Verzeichnisse existieren nicht
  • die Zugriffsrechte dahin fehlen
  • die Zert Datei Tzanoudakis.crt fehlt
  • oder die Leserecht darauf fehlen.
Da ist die Fehlermeldung eindeutig ! und DA solltest du auch ansetzen.
Und...
Lass doch mal den ganz überflüssigen Unsinn mit local, dev-node, ifconfig, ifconfig-pool-persist, push "dhcp-option, mssfix, crl-verify, ip-win32 usw. weg ! Das verschlimmbessert alles nur und OpenVPN hat dort sinnvolle Default Settings. Keep it simple and stupid...!
Außerdem arbeitest du hier ja schon wieder mit dem üblen tap Interfaces also Bridging
Du willst doch jetzt sinnvolles und empfohlenes Routing machen, oder ?
Da sind tun Kommandos wie tun-mtu dann so oder so Unsinn. 1500 Byte im Tunnel sowieso da es eh Dewfault ist und das Kommando entfallen kann. Abgesehen davon ist es auch falsch !!:
http://wohnzimmerhostblogger.de/archives/1563-OpenVPN-und-MTU-1500.html
Bitte warten ..
Mitglied: orcape
22.03.2018 um 10:29 Uhr
Hi intane,
wie das Dir @aqui gerade so schön, wohl zum wiederholten mal erzählt hat, machst Du grundlegende Fehler.
Auf Tipps gehst Du überhaupt nicht ein und verwendest wohl immer noch die ursprüngliche .config.
Entscheide Dich für das tun-Device, lass unnötige Sachen, die nicht benötigt werden weg, so zum Beispiel auch das client-to-client. Das kreiert Dir nur einen Multiclienttunnel und bringt die nächsten Probleme mit sich.
Überprüfe die Pfade und checke Fehlermeldungen die in den logs auftauchen, dann sollte das auch klappen.
Gruss orcape
Bitte warten ..
Mitglied: intane
12.04.2018 um 11:49 Uhr
Huhu, sry wieder für die lange Abwesenheit.
Hab mich wieder an dem Thema rangesetzt und eure Lösungsvorschläge auf tun angeschaut und angewandt.

Leider bekomme ich eine Fehlermeldung, beim Versuch ins richtige Netz zu kommen.

Das interessante ist, dass ich ifconfig und dhcp option etc. alles rausgeschmissen habe, es scheint mir als ob er die Konfiguration, noch irgendwo außerhalb der server config gespeichert hat.


Anbei noch die neuen configs.

Server
Client

Ich hab auch beim Server mit verschiedenen push Einstellungen getestet, wie im HOWTO oder in deiner Anleitung zu stehen sind, aber glaube der Fehler liegt, dass er nicht die richtige config öffnet beim Verbindungsaufbau.
Die Server config liegt unter C:\Program Files\OpenVPN\config und da liegt keine andere config, kann es sein, dass er noch die alte config von irgendwo lädt?
Also die Verbindung wird bis dahin aufgebaut.


Gruß
intane
Bitte warten ..
Mitglied: intane
12.04.2018 um 11:50 Uhr
Entscheide Dich für das tun-Device, lass unnötige Sachen, die nicht benötigt werden weg, so zum Beispiel auch das client-to-client. Das kreiert Dir nur einen Multiclienttunnel und bringt die nächsten Probleme mit sich.

Wurde weggelassen leider klappt die Verbindung mit tun noch nicht.

Gruß
intane
Bitte warten ..
Mitglied: aqui
12.04.2018, aktualisiert um 12:11 Uhr
Ja, das scheint zu stimmen. Die Server Konfig Datei die gestartet wird ist scheinbar NICHT die die du konfiguriert hast.
Das ist sicher, denn das zeigen die Parameter im Log die es in deiner Konfig Datei gar nicht mehr gibt !
Der holt die Konfig Datei irgendwo anderes her !!! Jedenfalls ist das nicht die von dir erstellte.
leider klappt die Verbindung mit tun noch nicht.
Das ist dann logisch wenn die Konfig Datei falsch ist !
fragment 1472 solltest du erstmal entfernen !

Normal liegt die Konfig Datei in /etc/openvpn . Wenn du sie woanders hast findet OpenVPN sie nicht.
Wo das Default Verzeichnis ist, ist in /etc/default/openvpn festgelegt also ggf. mal kontrollieren !
Du kannst aber OVPN auch mal manuell mit der dedizierten Angabe der Konfig Datei starten.

Dazu musst du den OVPN Prozess erst stoppen mit systemctl stop openvpn (bei systemd) oder mit /etc/init.d/openvpn stop oder auch service openvpn stop.
Danach kannst du mit openvpn /pfad/config.datei oder openvpn --config /pfad/config.datei händisch starten und das erzwingt dann das Laden deiner spezifischen Konfig Datei /pfad/config.datei mit dem kompletten Pfad dorthin.
Bitte warten ..
Mitglied: intane
12.04.2018 um 13:33 Uhr
Das ist dann logisch wenn die Konfig Datei falsch ist !
fragment 1472 solltest du erstmal entfernen !
ok hab ich, das war noch drin, weil das fürs bridging notwendig war, sonnst kam da ne Fehlermeldung mit:
Bad LZO decompression header byte
Aber wir bridgen ja nicht mehr ;)


Danach kannst du mit openvpn /pfad/config.datei oder openvpn --config /pfad/config.datei händisch starten und das erzwingt dann das Laden deiner spezifischen Konfig Datei /pfad/config.datei mit dem kompletten Pfad dorthin.

Das hat irgendwie über cmd nicht geklappt, die cmd spuckte raus, dass sie openvpn als Befehl bzw. --config nicht kennt, aber nicht allzu schlimm hab den Dienst über "Dienste" neugestartet" und es scheint, dass er die neue konfig übernommen hat.
Das icon wird grün, allerdings bin ich glaube nicht im Subnetz des Servers, kann den Server über RDP nicht erreichen, was über bridging ging.
Müsste ich da noch eine Route festlegen?



Außerdem benutzt er immer noch den TAP Adapter, oder ist normal auch bei tun, dass er über den Adapter die Verbindung aufbaut?
Bitte warten ..
Mitglied: intane
12.04.2018, aktualisiert um 14:27 Uhr
in der konfig die Zeile :
push "route 192.168.188.0 255.255.255.0"

aber klappt die Verbindung per RDP zum Server klappt noch nicht.


Gruß
intane
Bitte warten ..
Mitglied: aqui
12.04.2018 um 15:51 Uhr
dass sie openvpn als Befehl bzw. --config nicht kennt,
Mit doppeltem Bindestrich - - ! Kannst es aber wie gesagt auch so machen das du nach dem openvpn Kommando den Pfad nur durch ein Blank (Leerschritt) separierst.

Server sieht aber jetzt mit "Initialization Sequence Completed " sehr gut aus !!
benutzt er immer noch den TAP Adapter,
Ist der Server nu gruselige Winblows Gurke ? Dann ist das normal.
CONNECTED,SUCCESS,10.8.8.6,93.226.128.143,1194,,
Der Client sieht auch sehr gut aus !! Mit Open VPN selber ist also alles bestens
aber klappt die Verbindung per RDP zum Server klappt noch nicht.
Wenn der Server und auch der Client Winblows ist hast du noch 2 Hürden zu nehmen !!
Wegen der auf dem virtuellen OVPN Adapter fehlschlagenden Netzwerk Erkennung dekalriert Windows den Adapter als öffentliches Interface in seiner lokalen Firewall. Damit sind dann alle Verbindungen von außen blockiert.
Hier bleibt also Ping, RDP usw. schon mal per se stecken.
Du musst also zwingend den Adapter im Firewall Setup in ein Privates Netzwerk Profil umkonfigurieren.
(Firewall mit erweiterten Eigenschaften im Suchfeld)
Das wäre der erste Schritt.
Für Ping (ICMP) musst du zusätzlich noch den Zugriff generell in der Firewall erlauben:
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Auch der RDP Prozess blockiert den Zugriff von fremden Netzen in der Firewall !
Auch hier musst du zwingend das 10er VPN Netz (oder alle) zulassen.
Ohne das wird dir die Firewall alles blocken auf Server und Client Seite.
Das ist deine letzte Hürde zum Erfolg !
Bitte warten ..
Mitglied: intane
12.04.2018 um 16:25 Uhr
Das ist deine letzte Hürde zum Erfolg !

Das hört sich schon mal gut an werde gleich versuchen die Einstellungen durchzuführen.

Gruß
intane
Bitte warten ..
Mitglied: intane
13.04.2018 um 11:57 Uhr
Konnte leider die letzten zwei Hürden noch nicht bezwingen.

Du musst also zwingend den Adapter im Firewall Setup in ein Privates Netzwerk Profil umkonfigurieren.
o1 - Klicke auf das Bild, um es zu vergrößern
o2 - Klicke auf das Bild, um es zu vergrößern
Somit erledigt.

Für Ping (ICMP) musst du zusätzlich noch den Zugriff generell in der Firewall erlauben
o4 - Klicke auf das Bild, um es zu vergrößern
Ebenso
Der Ping klappt allerdings nur bis zum 10er Netz:
o7 - Klicke auf das Bild, um es zu vergrößern
Das 192.168.188.0er findet er dagegen nicht.

Auch der RDP Prozess blockiert den Zugriff von fremden Netzen in der Firewall !
o5 - Klicke auf das Bild, um es zu vergrößern
Sieht denke auch gut aus.

Auch hier musst du zwingend das 10er VPN Netz (oder alle) zulassen.
o6 - Klicke auf das Bild, um es zu vergrößern
Neue Regel erstellt, wo das 10er Netz komplett frei ist.

Ohne das wird dir die Firewall alles blocken auf Server und Client Seite.
Auf dem Client hab ich jetzt bei meiner Firewall bei den ausgehenden Regeln nichts gravierendes dagegen gefunden.
Eventuell beim Client, doch was erlauben?
Beim Bridging war es bis jetzt nicht nötig, aber ist ja ein anderes Verfahren.

Was mir auffiel ist es auch, dass es kein Unterschied macht bei dem Verbindungsaufbau ob die Zeile bei der Server Konfig da ist oder nicht: push "route 192.168.188.0 255.255.255.0"
Bitte warten ..
Mitglied: aqui
13.04.2018, aktualisiert um 15:27 Uhr
ob die Zeile bei der Server Konfig da ist oder nicht: push "route 192.168.188.0 255.255.255.0"
WIE hast du das getestet ??
Das kannst du nur sehen wenn du bei aktivem VPN Client dir mal die Routing Tabelle mit route print ansiehst !
Ohne das push route.. Kommando sollte das Netzwerk 192.168.188.0 /24 logischerweise fehlen in der Routing Tabelle. Pakete dahin gehen dann über die Default Route...und damit ins Nirwana.

"Nicht identifiziert" oben ist eher Öffentlich, was dann wieder Blocking heisst.
Bei den ICMP Regeln musst du aufpassen, oft sind die auf lokal gesetzt und sollten aber auf Beliebig stehen:

icmp-firewall - Klicke auf das Bild, um es zu vergrößern

Deshalb solltest du auch oben in den Eigenschaften alles erstmal auf Beliebig einstellen um sicherzugehen das nicht gefiltert wird.
Dichtmachen kann man das später imme rnoch.
Es ist nur noch die Win Firewall !
Bitte warten ..
Mitglied: intane
16.04.2018 um 17:18 Uhr
Das kannst du nur sehen wenn du bei aktivem VPN Client dir mal die Routing Tabelle mit route print ansiehst !
Ohne das push route.. Kommando sollte das Netzwerk 192.168.188.0 /24 logischerweise fehlen in der Routing Tabelle. Pakete dahin gehen dann über die Default Route...und damit ins Nirwana.

ohne push Route:
Client
rout_ohne_push_client - Klicke auf das Bild, um es zu vergrößern

Server
rout_ohne_push_server - Klicke auf das Bild, um es zu vergrößern


Mit Push
Client
rout_mit_push_client - Klicke auf das Bild, um es zu vergrößern

Server
rout_mit_push_server - Klicke auf das Bild, um es zu vergrößern

"Nicht identifiziert" oben ist eher Öffentlich, was dann wieder Blocking heisst.
o9 - Klicke auf das Bild, um es zu vergrößern
Erledigt




Bei den ICMP Regeln musst du aufpassen, oft sind die auf lokal gesetzt und sollten aber auf Beliebig stehen:
o8 - Klicke auf das Bild, um es zu vergrößern
Unter den GPOs das öffnetliche zu privat deklariert


Leider komme ich immer noch nicht durch, damit ich pingen kann bzw. RDP benutzen kann.
Eventuell eine zusätzliche Route hinzufügen?

Gruß
intane
Bitte warten ..
Mitglied: aqui
16.04.2018, aktualisiert um 17:50 Uhr
Wie erwartet. Die 192.168.188.0 wird sauber injiziert in die Routing Tabelle am Client auch via Adapter Nummer "35" was der virtuelle Tunnel Adapter ist. Siehst du ja auch selber.
Das ist also alles OK. Ein Traceroute (tracert) sollte also bei aktivem VPN immer den Weg via 10.8.8.0 dahin wählen.
Zeigt das das Routing korrekt funktioniert. Daran liegt es nicht.
Das die Route in der Routing Tabelle steht zeigt zudem das der Tunnel fehlerfrei aufgebaut wurde also auch das VPN an sich fehlerfrei funktioniert.
Eventuell eine zusätzliche Route hinzufügen?
Nein. Warum denn auch ? Das interne VPN Netz ist ja in der Tabelle und das remote lokale LAN werden auch sauber propagiert zum Client. Kannst du ja selber sehen in der Routing Tabelle ! Welche IP netze solltest du also noch routen wollen ? Gibt ja keine mehr wenn alle da sind !

Frage: Kannst du denn wenigstens das lokale LAN Interface 192.168.188.105 des Servers vom Client pingen ?
Ein Ping des direkten Server interfaces 10.8.8.5 klappt aber, oder ?

Das kann eigentlich nur noch an der lokalen Windows Firewall liegen !
Denk dran das du diese Firewall Einstellungen auf BEIDEN Seiten machen musst ! Also Server UND Client wenn beide Seiten Winblows sind.
Die Adapter Identifikation schlägt auf beiden Seiten fehl muss bei Winblows also beidseitig angepasst werden. Ebenso die Firewall Einstellungen und Profile.
Denk dran den IP Adressbereich bei ICMP lokale UND remote auf "Beliebig" zu stellen ! Das konnte man deinem "Erledigt" Screenshot nicht entnehmen. Wie bereits gesagt: Beide Seiten ! Server und Client.
Das gleiche gilt in der FW auch für den RDP Dienst !
Bitte warten ..
Mitglied: orcape
16.04.2018 um 19:44 Uhr
Nun, ich weis ja nicht, ob das hier weiter hilft? Wenn nur ein Client pro Tunnel gewünscht wird, dann solltest Du einen Multiclienttunnel vermeiden.
Ich hatte auch schon diese "Multiclienttunnel" am laufen, zu erkennen an den virtuellen IP 's 10.8.8.1 - 10.8.8.6/7 und immer Probleme mit dem Routing auf die Netze dahinter.
Ich habe hier mehrere Tunnel am laufen, die über eine pfSense, den gegenseitigen Zugriff über die OpenVPN-Server gewähren. Die Clients laufen auf den unterschiedlichsten Plattformen und Verbindung besteht in die Serverseitigen Netze und auch in die remoten Clientnetze ohne Probleme.
Dabei haben die Server "immer" eine CCD mit Client-Spezifischen Anweisungen und KEINEN "client-to-client" Eintrag. Die Routen sind in den Servereinstellungen mit "route" bzw. "push route" definiert.
Die tun-IP im Server ist immer die xxx.xxx.xxx.1 und die des Clients immer die xxx.xxx.xxx.2 und nur diese virtuellen IP 's für das virtuelle TUN-Device.
Hier das IPv4-Routing Protokoll der pfSense, klar zu sehen die "ovpns X" IP 's des Servers xxx.xxx.xxx.1 und des Clients xxx.xxx.xxx.2.
Gruss orcape
Bitte warten ..
Mitglied: aqui
17.04.2018 um 10:06 Uhr
Ich hatte auch schon diese "Multiclienttunnel" am laufen,
Du hast Recht !
Wurde dem TO oben auch schon mehrfach gesagt das er das NICHT machen soll.
Die Routing Table Screenshots mit den P2P "Leichen" zeigt aber klar das er das, wie du zu Recht bemerkst, leider nicht umgesetzt hat...
Da er aber (geraten) die OVPN Adresse des Servers pingen kann ist fraglich ob es das letztlich ist.
Hier wäre die Klärung der Frage ob er den LAN Adapter des Servers pingen kann sehr hilfreich. Aber die Antwort steht ja noch aus...?!
Bitte warten ..
Mitglied: orcape
17.04.2018 um 10:29 Uhr
@aqui
Da er aber (geraten) die OVPN Adresse des Servers pingen kann ist fraglich ob es das letztlich ist.
Abgesehen von... (geraten). Wenn sich die Tunnel-IP 's pingen lassen, ist bei seiner config noch lange nicht gesagt, das es auch mit den lokalen oder remoten Netzen funktioniert.
Das hier noch mehrere Faktoren eine Rolle spielen, die dem TO als gute Ratschläge mit auf den Weg gegeben wurden, sollte klar sein. Ob dann ordentlich umgesetzt, ist dann ein anderer Fall.
Wenn er die ganze Lektüre, die Du ja zweifelsohne, ordentlich verlinkt hast, dann duchgearbeitet und verstanden hat, sollte es ja zu einem Ergebnis kommen.
Gruss orcape
Bitte warten ..
Mitglied: intane
17.04.2018 um 16:18 Uhr
Frage: Kannst du denn wenigstens das lokale LAN Interface 192.168.188.105 des Servers vom Client pingen ?
Ein Ping des direkten Server interfaces 10.8.8.5 klappt aber, oder ?

Leider beides nicht:
Nur der Ping auf den 10.8.8.1 wie unten zu sehen.
Auf 10.8.8.5 nicht.
Die Konfiguration ist jetzt mit der Push Route s.o. auch ohne den Multiclienttunnel

Client
o12 - Klicke auf das Bild, um es zu vergrößern

Server
o11 - Klicke auf das Bild, um es zu vergrößern

o10 - Klicke auf das Bild, um es zu vergrößern
Das kann eigentlich nur noch an der lokalen Windows Firewall liegen !
Denk dran das du diese Firewall Einstellungen auf BEIDEN Seiten machen musst ! Also Server UND Client wenn beide Seiten Winblows sind.

Alles klar, muss dann eben noch schauen, dass ich beim Client auch die vornehme und nochmal probiere.

Die Adapter Identifikation schlägt auf beiden Seiten fehl muss bei Winblows also beidseitig angepasst werden. Ebenso die Firewall Einstellungen und Profile.
Denk dran den IP Adressbereich bei ICMP lokale UND remote auf "Beliebig" zu stellen ! Das konnte man deinem "Erledigt" Screenshot nicht entnehmen. Wie bereits gesagt: Beide Seiten ! Server und Client.

Aso ja, beim Server sind alle auf "beliebig", müssen wohl dann beim Client auch geschehen.
Bitte warten ..
Mitglied: intane
17.04.2018 um 16:31 Uhr
Nun, ich weis ja nicht, ob das hier weiter hilft? Wenn nur ein Client pro Tunnel gewünscht wird, dann solltest Du einen Multiclienttunnel vermeiden.

Multiclienttunnel müsste eigenlich deaktiviert sein.
Der Eintrag client-to-client ist auf der server Konfig entfernt worden.


Gruß
intane
Bitte warten ..
Mitglied: intane
17.04.2018 um 16:36 Uhr
Die Routing Table Screenshots mit den P2P "Leichen" zeigt aber klar das er das, wie du zu Recht bemerkst, leider nicht umgesetzt hat...

Komisch der Eintrag client-to-client ist eigentlich nicht mehr da.
Wie werden diese "Leichen" dann erzeugt.
Bitte warten ..
Mitglied: intane
17.04.2018 um 16:40 Uhr
Wenn er die ganze Lektüre, die Du ja zweifelsohne, ordentlich verlinkt hast, dann duchgearbeitet und verstanden hat, sollte es ja zu einem Ergebnis kommen.

Habe die Links größtenteils durchgeschaut, daraus die beiden Konfigs bzw. Einstellungen durchgeführt, es müssten eigentlich Kleinigkeiten sein, wieso die Verbindung nicht ganz klappt.
Da OVPN schon mal sich verbinden lässt.


Gruß
intane
Bitte warten ..
Mitglied: aqui
17.04.2018, aktualisiert um 17:28 Uhr
Müsste, könnte, sollte. Bischen viel Konjunktiv....
Und 4 Einzelthreads im Minutenrythmus könnte man auch sinnvoll in einen zusammenfassen...nur mal so OT.
Wie werden diese "Leichen" dann erzeugt.
Wenn man KEIN Multiclient macht.
Sollte aber auch raus sein aus deinen Konfigs wenn die obigen noch stimmen. Das fragment, keepalive und persist-tun sollte noch raus so das wirklich nur das drin ist was man wirklich braucht.
Persist-tun bewirkt vermutlich das die Tunnel Netz nicht abgebaut werden und als Inaktiv in der Routing Tabelle verharren..
Die 10.8.8.1 sollte eigentlich gar nicht pingbar sein wenn der Server selber die .2 hat. Dann müsste die .2 vom Client pingbar sein.
Der Tunnel selber rennt also aber das das LAN Interface nicht pingbar ist zeigt klar das irgend etwas mit dem IPv4 Forwarding (Routing) am Server nicht klappt.
Hast du mal in der Registry überprüft ob das wirklich aktiv ist ??
Oder eben die lokale Firewall. Eins von beiden oder beides ist es....
Das ist die Pest mit Microsoft. Mit einem Linux würde das schon seit 3 Tagen laufen...
Bitte warten ..
Mitglied: orcape
17.04.2018 um 17:39 Uhr
Das ist die Pest mit Microsoft.
Na ja, man kann es sich, man muss es sich ja nicht an tun.
Der Möglichkeiten und Alternativen gibt es da wohl mehrere.
Bitte warten ..
Mitglied: intane
18.04.2018 um 13:42 Uhr
Sollte aber auch raus sein aus deinen Konfigs wenn die obigen noch stimmen. Das fragment, keepalive und persist-tun sollte noch raus so das wirklich nur das drin ist was man wirklich braucht.
Persist-tun bewirkt vermutlich das die Tunnel Netz nicht abgebaut werden und als Inaktiv in der Routing Tabelle verharren..

Alles klar, anbei noch die überarbeitete server konfig.

Die 10.8.8.1 sollte eigentlich gar nicht pingbar sein wenn der Server selber die .2 hat. Dann müsste die .2 vom Client pingbar sein.
Der Tunnel selber rennt also aber das das LAN Interface nicht pingbar ist zeigt klar das irgend etwas mit dem IPv4 Forwarding (Routing) am Server nicht klappt.

Ok, haben wir schon mal die Ursache.

Hast du mal in der Registry überprüft ob das wirklich aktiv ist ??

o13 - Klicke auf das Bild, um es zu vergrößern
IPEnableRouter war inaktiv, da der Rechner kein Server BS hat, aktiviert, aber leider ohne Erfolg bis jetzt.

Oder eben die lokale Firewall. Eins von beiden oder beides ist es....
Das ist die Pest mit Microsoft. Mit einem Linux würde das schon seit 3 Tagen laufen...

Die Microsoft Pest ^^ ja auf dem Rechner muss eine Handwerkssoftware laufen und die ist für Windows erworben, daher...
Ja mittlerweile sind gefühlt alle Türen offen von der FW her bei Server und Client, aber leider hackt es noch hmm
Da Verbindung da ist, denke ich müsste auf der Fritzbox keine Route noch erstellt werden oder.
Bitte warten ..
Mitglied: intane
18.04.2018 um 14:08 Uhr
Was mir jetzt aufgefallen ist, dass die Verbindung alle zwei Minuten neustartet, bricht einfach plötzlich ab (timeout)

Client Log:
Davor nicht wirklich drauf geachtet, das obere Log wiederholt sich alle zwei Minuten.
Bitte warten ..
Mitglied: 135950
18.04.2018, aktualisiert um 16:35 Uhr
Was mir jetzt aufgefallen ist, dass die Verbindung alle zwei Minuten neustartet, bricht einfach plötzlich ab (timeout)

In der zuletzt geposteten Server Config fehlt ein keepalive Eintrag, z.B.
keepalive 10 60

Sieht man ja eigentlich auch am Log :
Wed Apr 18 13:58:58 2018 [server] Inactivity timeout (--ping-restart), restarting

Gruß m.
Bitte warten ..
Mitglied: intane
18.04.2018 um 16:50 Uhr
In der zuletzt geposteten Server Config fehlt ein keepalive Eintrag, z.B.

Ah ok, stimmt ;)
Danke
Müssen nur noch die restlichen Schwierigkeiten klären


Gruß
intane
Bitte warten ..
Heiß diskutierte Inhalte
Router & Routing
Wireguard VPN (oder andere alternative) - Kompletter Traffic routen
gelöst KodaCHFrageRouter & Routing15 Kommentare

Guten Morgen Ich habe bisher mit OpenVPN und mit Wireguard VPN einige Tests gemacht. OpenVPN (Kostenlose Version): Hier habe ...

Server-Hardware
Konfiguration und Stromverbrauch ML350 Gen10
kosta88FrageServer-Hardware13 Kommentare

Hallo, ich versuche mal zu berechnen was ein ML350 verbrauchen würde. Ich weiß dass es von der Konfiguration und ...

Windows Server
Hyper-V Server vs Datacenter?
holliknolliFrageWindows Server12 Kommentare

Hallo, hat jemand Erfahrung mit dem - kostenlosen - Hyper-V-Server? Ich meine, warum teure Lizenzen für Datacenter zahlen, wenn ...

Server
Kein Zugriff auf NAS bei DS Lite
martingerdesFrageServer11 Kommentare

Hallo liebe Gemeinde, dieses Thema kennen wahrscheinlich viele und ich selbst habe schon viele Forenbeiträge zu diesem Thema gelesen. ...

Grafikkarten & Monitore
Grafikkarte kaputt? Hier muss noch etwas hin, weil der andere Titel schon vergeben ist :)
Sir.classicFrageGrafikkarten & Monitore9 Kommentare

Hallo an alle, ich habe einen selbst gebauten PC und mein Problem ist, dass meine Monitore regelmäßig (alle 3h) ...

LAN, WAN, Wireless
Spanning Tree Probleme
predator66FrageLAN, WAN, Wireless9 Kommentare

Hallo, wir haben hier eigenartige Spanningtree Probleme, die wir zur Zeit nicht gelöst bekommen: New Root Port MAC ist ...

Ähnliche Inhalte
Router & Routing
OpenVPN Routing
gelöst sebastian2608FrageRouter & Routing2 Kommentare

Seid gegrüßt, würde gerne mal euren Input zu einem OpenVPN Routing "Problem" hören. Zur Situation: Privates Netzwerk; 10.0.0.0/24 Firmennetzwerk ...

Router & Routing
OPENVPN Routing Frage
gelöst stefan2k1FrageRouter & Routing8 Kommentare

Hallo zusammen, kann mir bitte jemand einen Tip geben? Wenn ich mit OpenVPN eine VPN-Verbindung in die Firma aufbaue, ...

Linux Netzwerk
OpenVPN Routing - Forwarding
gelöst behumiFrageLinux Netzwerk5 Kommentare

Hallo zusammen, und noch schöne Weihnachten. Ich habe ein Problem mit dem OpenVPN routing und hoffe ihr könnt mir ...

Router & Routing
OpenVPN Routing - zwei Interfaces
gelöst Steffen.MFrageRouter & Routing1 Kommentar

Hallo Leute, ich habe ein Problem. Ich nutze Ubuntu testweise als VPN Gateway. ens38 hängt am Router. Darüber wird ...

Router & Routing
Openvpn Routing in beide richtungen
fundave3FrageRouter & Routing3 Kommentare

Guten Abend, Ih brauche mal einen Rat, da ich gerade einen Denkfehler habe. Meinen Raspberry nutze ich als Openvpn ...

Router & Routing
PfSense routing OpenVPn und IPSec
TheOnlyOneFrageRouter & Routing13 Kommentare

Hallo zusammen, ich habe 3 Standorte die per VPN miteinander verbunden sind. (siehe Bild) Nun stehe ich vor der ...

Berechtigungs- und IdentitätsmanagementBerechtigungs- und IdentitätsmanagementWebdienste und -serverWebdienste und -serverDatenbankenDatenbankenMonitoring & SupportMonitoring & SupportHybrid CloudHybrid CloudSmall Business ITSmall Business IT