Top-Themen

Aktuelle Themen (A bis Z)

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWünsch Dir wasWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

Clientverbindung OpenVPN Mikrotik

Mitglied: dauatitsbest

dauatitsbest (Level 1) - Jetzt verbinden

28.12.2017 um 15:11 Uhr, 7881 Aufrufe, 31 Kommentare, 5 Danke

Grüß euch,
ich müsste eine OpenVPN Verbindung von einem Windows Client PC auf ein Mikrotik Routerboard machen.
Hat jemand einen aktuellen Link von einer Anleitung mit Konfiguration (über Webinterface oder Winbox, nicht Linux) die er schon probiert hat und funktioniert?
Ich habs bei mir auf eine PFSense probiert und da klappt das sofort und tadellos, aber auf einen Mikrotik Router mags einfach nicht ...
Danke

31 Antworten
Mitglied: colinardo
28.12.2017, aktualisiert um 16:59 Uhr
Servus,
der Mikrotik hat hier ein paar zwingende Anforderungen als da wären folgende
  • Verschlüsselung max. AES-256 mit SHA1 oder MD5.
  • Verbindung nur über TCP (kein UDP)
  • kein zusätzliches TLS-Auth (keine Nutzung von ta.key)
  • keine Kompression nutzen (comp no)

Wird das in der Client-Config beachtet klappt auch die Verbindung mit dem Mikrotik.

Wenn noch etwas unklar ist, kannst du mich gerne per PN kontaktieren.

-edit-

Hier eine ganz einfach gehaltene Verbindung mit Passwort Authentifizierung (mit Zertfikaten ist es fast genauso,nur das das Häkchen bei "Require client certificate" gesetzt und in der Client-Config das Client-Zertifikat angegeben wird).

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

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

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

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

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

Die Client-Config (Password Auth)
Wenn noch etwas unklar ist, kannst du mich gerne per PN kontaktieren.

Grüße Uwe
Bitte warten ..
Mitglied: aqui
28.12.2017, aktualisiert um 16:54 Uhr
Hallo Uwe !
Bist du sicher das keine UDP Encapsulierung erlaubt ist ? Das wäre aus Performance Sicht ja ein gravierender Nachteil
"ip" ist ja in der Konfig eine etwas unsinnige Angabe. Meint das dann TCP als Encap ?
Sind diese "Zwangsparameter" irgendwo dokumentiert auf den MT Seiten ?
Hier:
https://wiki.mikrotik.com/wiki/OpenVPN#RouterOS
sieht man das so ja erstmal nicht obwohl diese Diskussion von 2013 es ja indirekt bestätigt.
https://forum.mikrotik.com/viewtopic.php?t=77898
Bitte warten ..
Mitglied: colinardo
28.12.2017, aktualisiert um 16:54 Uhr
Zitat von aqui:

Hallo Uwe !
Bist du sicher das keine UDP Encapsulierung erlaubt ist ? Das wäre aus Performance Sicht ja ein gravierender Nachteil
Japp, geht nicht hab ich alles schon durch. Die OpenVPN Umsetzung auf dem Mikrotik war leider schon immer sehr schlecht.
"ip" ist ja in der Konfig eine etwas unsinnige Angabe. Meint das dann TCP als Encap ?
Ja.
Sind diese "Zwangsparameter" irgendwo dokumentiert auf den MT Seiten ?
Hier:
https://wiki.mikrotik.com/wiki/OpenVPN#RouterOS
sieht man das so erstmal nicht.
Ich poste die hier später mal.
Bitte warten ..
Mitglied: aqui
28.12.2017, aktualisiert um 17:00 Uhr
Die o.a. MT Forendiskussion lässt es erahnen....

Für den TO ist hier eine gute und dokumentierte Anleitung für das GUI:
http://www.klehr.de/michael/openvpn-server-unter-mikrotik-routeros/
Bitte warten ..
Mitglied: dauatitsbest
08.01.2018 um 12:57 Uhr
Hallo Leute,
danke für die Antworten. Ich werd mir das die nächsten Tage nochmals zu Gemüte führen und schauen ob es so gelöst werden kann.
Danke erstmal.
Bitte warten ..
Mitglied: aqui
08.01.2018 um 15:37 Uhr
Es kann definitiv so gelöst werden
Bitte warten ..
Mitglied: colinardo
23.01.2018 um 16:17 Uhr
Wenns das dann war, den Beitrag bitte noch auf gelöst setzen, und Lösungen markieren. Merci.
Bitte warten ..
Mitglied: wusa88
28.02.2019 um 10:55 Uhr
Hallo Zusammen,

vorerst, ich weiß, dass der Thread schon etwas betagt ist. Allerdings habe ich genau das selbe Problem, daher denke ich das es hier Platz hat. Wenn nicht, dann bitte verschieben, oder mir bescheid geben, dann erstelle ich einen neuen Thread.

Der Mikrotik hängt bei mir hinter einem Kabelmodem, welches im Bridge Modus betrieben wird. Zur Verfügung wird eine IPv4 gestellt.

Vielleicht ist es für das weitere vorgehen wichtig: Ich hatte vorher einen Raspberry Pi der bei mir OVPN übernommen hat. Diese Zertifikate usw. habe ich alles von dem Raspi übernommen und in den Mikrotik importiert.
Beim Raspi hat OVPN ohne jegliche Einschränkung funktioniert!

Das DDNS Update mache ich über den Mikrotik direkt:
ddns_mikrotik - Klicke auf das Bild, um es zu vergrößern



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


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

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

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


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

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

Wegen der Firewall Regel bin ich mir nicht ganz sicher:
firewall_mikrotik - Klicke auf das Bild, um es zu vergrößern

Auch hier ist noch eine Log Ausgabe:
log_mikrotik - Klicke auf das Bild, um es zu vergrößern

Einen IP Adresskonflikt kann ich schon mal ausschließen.

Ich weiß jetzt leider nicht, ob es an den Raspi Zertifikaten liegt oder an einer Einstellung im Mikrotik.

Vielen Dank schon mal für die Hilfe!
Bitte warten ..
Mitglied: aqui
28.02.2019, aktualisiert um 18:27 Uhr
welches im Bridge Modus betrieben wird. Zur Verfügung wird eine IPv4 gestellt.
Ganz sicher ??
Mit anderen Worten du hast die öffentliche Provider IP direkt am MT ??
Nur um sicher zu gehen !
Einen Kardinalsfehler in der MT Implementation ist die TCP Encapsulation. Das erhöht massiv den Overhead auf dem VPN Tunnel und geht stark zu Lasten der Performance.
Kann man aber nix machen MT supportet nur TCP Encapsulierung (Video bei 5:39)
So oder so kannst du niemals mit einer Tunnel MTU von 1500 arbeiten. Die musst du anpassen.
Das hier hast du sicher gesehen:
https://www.youtube.com/watch?v=ZZBvOyjCZ6U

Das Log sieht erstmal normal aus. Interessanter wäre das Client Log !!
Was steht da drin ?
Hast du daran gedacht das OVPN interne Netz vom NAT Prozess auszunehmen ??
Fragt sich auch was die PPP Konfig bei dir zu suchen hat bei OVPN, das ist garantiert ebenso falsch ! OVPN hat mit PPP nix zu tun.
Bitte warten ..
Mitglied: 138810
28.02.2019, aktualisiert um 18:26 Uhr
Ganz zu schweigen vom Client-Zertifikat, das hat auf dem Server nichts verloren. Da gehört in der Server-Config das Server-Zertifikat rein.
Bitte warten ..
Mitglied: aqui
28.02.2019 um 18:27 Uhr
das hat auf dem Server nichts verloren.
In der Tat !! Da muss man sich nicht wundern das das in die Hose geht.
Sorry, Hatte ich im Eifer des Gefechts auch noch übersehen.
Bitte warten ..
Mitglied: 138810
28.02.2019 um 18:30 Uhr
Zitat von aqui:
Sorry, Hatte ich im Eifer des Gefechts auch noch übersehen.
Kein Thema, dafür sind wir ja eine Community .
Bitte warten ..
Mitglied: wusa88
28.02.2019 um 22:43 Uhr
Zitat von aqui:

welches im Bridge Modus betrieben wird. Zur Verfügung wird eine IPv4 gestellt.
Ganz sicher ??
Mit anderen Worten du hast die öffentliche Provider IP direkt am MT ??
Nur um sicher zu gehen !
Normalerweise ja... ich habe im Internet diverse Seiten auf IPv6 getestet. Keine einzige Seite zeigt mir etwas von DS oder DS-Lite an. Auch ist bei mir keine IPv6 verfügbar.
Kann man aber nix machen MT supportet nur TCP Encapsulierung (Video bei 5:39)
Eine Überlegung wäre UDP. Aber das muss nicht zwingend sein. Wenn TCP funktioniert, dann kann ich immer noch auf UDP umbauen.

So oder so kannst du niemals mit einer Tunnel MTU von 1500 arbeiten. Die musst du anpassen.
Das hier hast du sicher gesehen:
https://www.youtube.com/watch?v=ZZBvOyjCZ6U
Ja habe ich gesehen. Hier wird aber auch alles auf Default gelassen auch MTU von 1500. Es wird zwar erwähnt, dass es weniger sein soll. Kann ich aber gerne anpassen.

Das Log sieht erstmal normal aus. Interessanter wäre das Client Log !!
Was steht da drin ?
Hast du daran gedacht das OVPN interne Netz vom NAT Prozess auszunehmen ??
Ehrlich gesagt... Nein. Ich weiß auch nicht wie das Handhaben soll? Kenne mich da noch zu wenig aus.
Fragt sich auch was die PPP Konfig bei dir zu suchen hat bei OVPN, das ist garantiert ebenso falsch ! OVPN hat mit PPP nix zu tun.
Ich weiß ehrlich gesagt nicht was du hier genau meinst. Ich bin den Anleitungen gefolgt. Ich selbst habe noch nie OVPN auf dem Router betrieben. Daher bin ich nur nach den Anleitungen gegangen.

Zitat von 138810:

Ganz zu schweigen vom Client-Zertifikat, das hat auf dem Server nichts verloren. Da gehört in der Server-Config das Server-Zertifikat rein.
Danke... Hier bin ich total daneben gestanden. Das war auch keine Absicht...
Habe das Client gegen Server getauscht.

Auch mit dem Austausch von Client und Server Zertifikat funktioniert es nicht.
Client Log reiche ich morgen nach.
Bitte warten ..
Mitglied: aqui
01.03.2019, aktualisiert 06.07.2020
So, Testaufbau gemacht und wieder was gelernt.
OpenVPN auf dem Mikrotik ist ein klein wenig anders als OpenVPN "normal" ! (Kollege @colinardo hat das oben ja auch schon zu Recht angemerkt.)
Folgende Punkte muss man genau beachten:
  • Mikrotik supportet keine UDP Encapsulation sondern nur TCP !
  • Server Zertifikat muss RSA Format haben (.pem)
  • Mikrotik benötigt zwingend einen Usernamen und Passwort zum Login. Nur Zertifikat geht nicht
  • Mikrotik kann keinen globalen Adresspool für das interne OpenVPN IP Netz verwalten sondern MUSS das in /30er Netzen angelegt haben mit Folge Pools (next Pool Kommando).
  • Mikrotik OVPN Server kann keine Routen automatisch an den Client per "push" schicken. In der Client Konfig ist eine (oder mehr) Route(n) erforderlich ! Alternative: Dynamisch routen mit RIPv2 oder OSPF (Tutorial wird dbzgl. erweitert !)
  • Arbeitet man auf dem Mikrotik mit der Standard NAT Firewall (Default Konfig) muss eine Regel in die Firewall konfiguriert werden die den OVPN Zugriff erlaubt.
In sofern müssen wir die Kritik oben in puncto "PPP" etwas relativieren, sorry !

Beachtet man diese etwas speziellen Punkte funktioniert es fehlerlos und ohne Probleme !
Der Testaufbau sieht so aus:

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

Konfig Schritte Mikrotik (hier RB750)


1.) Server Zertifikate importieren:
Das geht einfach über das "Files" Menü per drag and drop.
cert - Klicke auf das Bild, um es zu vergrößern
Wichtig:
Wer den Server Key mit dem Standard Tool Easy-RSA erzeugt hat muss diesen für den Mikrotik OpenVPN ins RSA Format (.pem) umwandeln !! Das geht unter Linux schnell und einfach mit:
openssl rsa -in keys/RB750.key -out keys/RB750.pem
(Wobei hier RB750.key der vorab erzeugte Server Key ist und und RB750.pem dann der konvertierte Key, der auf den Mikrotik kopiert werden muss.

2.) IP /30 Pool einrichten und mit "next Pool" auf das folgende /30er Pärchen verweisen
(Testweise hier für 4 Clients)

ipovpnpool - Klicke auf das Bild, um es zu vergrößern
Das ist NICHT mehr up to date !!
Mit dem aktuellen Router OS kann man nun auch einen einfachen und normalen "Subnet" basierten Pool mit einer /24 Maske einrichten !
/ip pool add name=ovpn-pool ranges=10.88.88.10-10.88.88.100

3.) Diesem Pool ein OVPN Server Profil zuweisen:
o2 - Klicke auf das Bild, um es zu vergrößern

4.) Usernamen/Passwort einrichten und dem OVPN Profil zuweisen:
user - Klicke auf das Bild, um es zu vergrößern

5.) OVPN Server einrichten und aktivieren:
o1 - Klicke auf das Bild, um es zu vergrößern

6.) In der NAT Firewall OVPN Zugriff (hier TCP 1194) erlauben:
fw - Klicke auf das Bild, um es zu vergrößern

Konfig Schritte OpenVPN Client (hier Raspberry Pi):


Verwendete OVPN Client Konfig Datei mikrotik.conf
(Man erkennt hier die im Client erforderliche Route via VPN Tunnel ins lokale LAN des MT, da der Mikrotik OVPN Server diese nicht per Push automatisch an den Client senden kann ! Das ist NUR bei der Mikrotik OVPN Implementation so, nicht bei "normalen" OVPN Setups die natürlich mit "Push" arbeiten.)
Die lokale Userdatei auth.cfg ist eine simple Text Datei und enthält den Usernamen user und das Passwort test123 damit am Client kein Fenster zur Abfrage hochpoppt.)
Das Format dieser Textdatei ist dann so:
Die Datei kann dann mit dem Notepad Editor oder nano Editor (Linux) erstellt werden.

Check der OVPN Client Konfig mit manuellem Start in der Kommandozeile:
Initialization Sequence Completed sagt schon das alles OK ist und damit kann man den OVPN Client dann auch sicher als Daemon auf dem RasPi starten.
Das OVPN Tunnel Interface kommt auch sauber hoch mit richtiger IP:
Finaler Client Verbindungs Check (Ping Mikrotik LAN IP vom Client) und Routing Tabelle:

Konfig und Check mit Windows OpenVPN Client:

Windows OpenVPN Client heruntergeladen und installiert.
Die relevanten Dateien liegen alle im Verzeichnis C:\Benutzer\<username>\OpenVPN\config
ow3 - Klicke auf das Bild, um es zu vergrößern

Windows OpenVPN Client Config Datei (mikrotik.ovpn):
Diese ist wie bei OpenVPN üblich über die Betriebssysteme immer gleich mit ein paar kleinen kosmetischen Änderungen zur der o.a. Apple Mac und Linux Version.
Start OpenVPN Client:
In den Eigenschaften des Clients kann man temporär ein Skriptfenster eröffnen um das Logging zu beobachten. (Sollte man wenn alles klappt wieder deaktivieren):
ow2 - Klicke auf das Bild, um es zu vergrößern
Verbindung wird fehlerfrei hergestellt mit dem Mikrotik RB750 !
Was Windows dann auch mit einem Balloon Info Text am Taskleistensymbol meldet. Das OVPN Icon wird dann auch grün.
ow1 - Klicke auf das Bild, um es zu vergrößern
Das ein Ping dann ins remote LAN ebenso fehlerfrei läuft muss man sicher nicht noch extra betonen.

Fazit:
Alles fehlerfrei ! Works as designed !
Bitte warten ..
Mitglied: wusa88
05.03.2019, aktualisiert um 09:52 Uhr
Hallo @aqui,

vielen lieben Dank für die super ausführliche Erklärung. Schön dass du dir solch ein Arbeit für ein Forum machst.

Leider klappt das ganze nicht bei mir. Hier mal mein vorgehen. Vielleicht siehst du ja einen Fehler.

Server Zertifikat Importieren:
filelist - Klicke auf das Bild, um es zu vergrößern

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

IP Pools
ippools - Klicke auf das Bild, um es zu vergrößern

PPP Profile
pppprofile - Klicke auf das Bild, um es zu vergrößern


PPP Secrets
pppsecret - Klicke auf das Bild, um es zu vergrößern

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

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

Client ist ein Windows PC. Hier meine Config:

Problem ist jetzt, dass ich folgenden Fehler im Mikrotik Log erhalte:
log - Klicke auf das Bild, um es zu vergrößern

Und hier noch die Logausgabe vom Windows Client:
Bitte warten ..
Mitglied: aqui
05.03.2019 um 13:47 Uhr
Du hast ein Problem mit deinem Zertifikat !! (TLS Error: TLS key negotiation failed to occur within 60 seconds)
Entferne mal das "remote-cert-tls server" in deiner Client Konfig und versuche nochmal.
Bitte warten ..
Mitglied: wusa88
05.03.2019 um 13:56 Uhr
Funktioniert weiterhin nicht. Ich habe die Vermutung, dass es vielleicht damit zusammen hängt, dass ich das Zertifikat von meine Raspi genommen habe und keine neues ausgestellt habe.
Ich werde heute mal ein neues Zertifikat ausstellen und nochmals neu versuchen.
Bitte warten ..
Mitglied: aqui
05.03.2019, aktualisiert um 18:05 Uhr
Was du nochmal machen kannst ist das "tls-client" ebenfalls entfernen und mal testen.
Es liegt auf alle Fälle am Zertifikat, denn das meckert er an. Nicht am Netzwerk.
Nur nebenbei: Es ist wichtig das die Uhrzeit halbwegs synchron ist auf dem MT und dem Client ! Hast du dem MT einen NTP Server konfiguriert so das der eine korrekte Uhrzeit hat ?
Sonst generierst du eben mit Easy-RSA ein paar neue Zertifikate, das ist ja auch in 5 Minuten erledigt.
Das fixt dein Problem sofort !
Bitte warten ..
Mitglied: wusa88
13.03.2019 um 22:17 Uhr
So... kurze Rückmeldung von mir. Habe die Zertifikate nochmals alle neu ausgestellt.
Dann die ganze Anleitung nochmal von vorne Schritt für Schritt befolgt.
Und siehe da... es funktioniert!

Danke für die Hilfe!
Bitte warten ..
Mitglied: aqui
14.03.2019, aktualisiert um 16:59 Uhr
Und siehe da... es funktioniert!
Heureka !!
War ja ne schwere Geburt mit dir ! Aber wenigstesn sind wir so endlich auch mal zu einer Mikrotik Open VPN Anleitung gekommen.

Case closed ! Und bitte
https://administrator.de/faq/32
dann nicht vergessen !
Bitte warten ..
Mitglied: wusa88
15.03.2019 um 11:34 Uhr
Ursprünglicher Post war nicht von mir.. hab nur den Thread auch verwendet, da ich das selbe Problem hatte.
Daher kann ich es leider nicht auf erledigt setzen.

Der TO war seit Dez 2018 nicht mehr online. Vielleicht kann das jemand anderes auf Erledigt setzen.
Bitte warten ..
Mitglied: wusa88
12.05.2020 um 10:07 Uhr
Hallo Zusammen,

ich habe leider wieder ein kleines Problem mit meiner OpenVPN Verbindung.

Ich habe von einem hAP Lite (Tower) auf einen normalen hAP Lite gewechselt. Nur das mal als Info, vielleicht liegt hier schon irgendwo der Hund begraben.

Ich habe alle Zertifikate einfach übernommen, ohne diese neu auszustellen.

Wenn ich mich nun mit meinem Android Smartphone und OVPN verbinde, funktioniert der Verbindungsaufbau grundsätzlich, allerdings erscheint diese Meldung: Ausgeschlossene Route: (hier meine interne IP Adresse, 192.168.7.0)

Somit bin ich grundsätzlich verbunden, aber ich kann nicht auf mein internes Netz zugreifen.

Die Route ist in der .ovpn auch hinzugefügt:
route 192.168.7.0 255.255.255.0

Gerne kann ich auch nochmal alle Schritte die ich im Mikrotik eingestellt habe, hier posten.
Bitte warten ..
Mitglied: aqui
12.05.2020, aktualisiert um 10:47 Uhr
Nur das mal als Info, vielleicht liegt hier schon irgendwo der Hund begraben.
Nein, denn die RouterOS Firmware Version (nur darauf kommt es an !) ist ja immer identisch.
Gerne kann ich auch nochmal alle Schritte die ich im Mikrotik eingestellt habe, hier posten.
Musst du nicht, denn die stehen hier ja schon alle:
https://administrator.de/content/detail.php?id=359367&token=695#comm ...
aber ich kann nicht auf mein internes Netz zugreifen.
Kannst du z.B. mit den HE.net_Tools den lokalen LAN Port des MT pingen ?
Oder irgendein anderes nicht Windows Gerät im lokalen LAN pingen ? Widows wegen der Problematik der lokalen Firewall das diese Fremdnetze und ICMP (Ping) blockiert im Default.
Betreibst du den MT als Kaskade oder als sog. "one armed" VPN Server ?
Hilfreich wäre zudem das VPN Log des Clients und servers bei Einwahl ! Ggf. mal den Verbosity Level auf 3 setzen um mehr zu sehen. Übrigens ist Level 1 der Default den du nicht extra in der Client.conf definieren musst.
Bitte warten ..
Mitglied: wusa88
12.05.2020, aktualisiert um 11:22 Uhr
Zitat von aqui:

Nein, denn die RouterOS Firmware Version (nur darauf kommt es an !) ist ja immer identisch.
Diese war bei mir leider nicht Identisch.
Auf dem "Tower" hatte ich 6.43.8 auf dem "normalen" hAP Lite habe ich 6.46.4.
Ist das für die Zertifikate auch ausschlaggebend?
Kannst du z.B. mit den HE.net_Tools den lokalen LAN Port des MT pingen ?
Ping kommt leider nicht durch. Weder auf den lokalen LAN Port direkt auf den MT noch auf irgend ein Geräte im Netzwerk, welches auch wirklich Pingbar ist.
Betreibst du den MT als Kaskade oder als sog. "one armed" VPN Server ?
Ich weiß leider nicht, was ein "one armed" ist, aber ich betreibe keine Kaskade. Der MT ist mein "Hauptrouter" hinter einem Kabelmodem, das allerdings im Bridge Modus ist. So hat es mit dem Tower auch wunderbar funktioniert.
Hilfreich wäre zudem das VPN Log des Clients und servers bei Einwahl ! Ggf. mal den Verbosity Level auf 3 setzen um mehr zu sehen. Übrigens ist Level 1 der Default den du nicht extra in der Client.conf definieren musst.
Hier mal ein Teil vom Logeintrag. Wenn Verbosity Level 3 noch nötig ist, dann stelle ich das gerne um:
anmerkung 2020-05-12 111630 - Klicke auf das Bild, um es zu vergrößern

Edit:
Hier noch der OpenVPN Log vom Smartphone direkt.
photo5321377537177267330 - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: aqui
12.05.2020, aktualisiert um 12:00 Uhr
Ist das für die Zertifikate auch ausschlaggebend?
Nein, normal nicht. Sofern Datum, Uhrzeit bzw. NTP Server stimmen kann man die problemlos portieren. Zertifikate sind aber immer von der genauen Uhrzeit abhängig. NTP Server hast du also hoffentlich in deinem MT konfiguriert ?!
Ich weiß leider nicht, was ein "one armed" ist, aber ich betreibe keine Kaskade.
Wie der Name es schon selber schon sagt sind das "einbeinig" angeschlossene Server wie z.B. dieses_Design es beschreibt. Also keine Kaskade. Eigentlich ein Standard Begriff in der Netzwerk IT...?!
Der MT ist mein "Hauptrouter" hinter einem Kabelmodem, das allerdings im Bridge Modus ist.
OK, das bedeutet der MT hält am WAN/Internet Port die öffentliche Provider IP Adresse, ist das richtig ?

Gut, soweit sieht die VPN Connection auch sauber aus. Kosmetisch könnte man noch anmeckern das du das auth-nocache in der Konfig vergessen hast, was ja auch das Log anmahnt, aber das ist nur Sicherheits Kosmetik und nicht ausschlaggebend.
Zu 95% kann man ausschliessen das es etwas mit Zertifikaten oder der OVPN Server Konfig zu tun hat sonst würdest du niemals ein "Initialization sequence completed !" bekommen haben im Log was ja belegt das alles OK ist !
Der Fehler liegt sehr wahrscheinlich im Client selber....

Besorgniserregender ist deshalb das "11:07 Ausgeschlossene Routen: 192.168.7.0/24" was vermutlich das lokale LAN des OVPN Servers ist, richtig ?
Der Android Client übernimmt diese IP Route nicht und damit ist ein Routen der Client IP Pakete in das 192.168.7.er Netz unmöglich, was dann das Problem erklärt.
Den OVPN Server selbst mit der internen 10.8.0.1 wirst du sicher pingen können, oder ? Sprich der Client kann rein nur auf dem Server arbeiten nicht aber im lokalen Server IP Netz weil er die IP Route dazu nicht übernimmt.
Der Android Client routet dann wegen der fehlenden Route Pakete mit der Ziel IP 192.168.7.x statt in den VPN Tunnel dann zum ISP Provider (Default Route) wo sie dann als private RFC1918 IP Netze im Nirwana verschwinden.
Ein Traceroute mit den HE.net Tools sollte dir das auch ganz eindeutig zeigen ! Hast du das mal gecheckt ?!

Der Android Client übernimmt vermutlich wegen fehlender Root oder User Rechten der OVPN App auf dem Device die 192.168.7.er Route nicht in den Kernel. Sprich es ist rein ein Problem des Android Clients.
Testweise könntest du mal versuchen ein:
user nobody
group nogroup

in die Client Konfig hinzuzufügen.

Kannst du ja auch ganz einfach mal testen wenn du den auf Tethering schaltest und mit einem Laptop oder anderem OVPN Client den Zugriff versuchst. Das sollte fehlerlos klappen und würde so verifizieren das es nur diese spezifische Android Client bzw. dessen Konfig ist.
Man kann das auch kontrollieren indem man z.B. unter Windows route print oder bei unixoiden OS netstat -r -n oder auch ip route show eingibt. Das zeigt die Routing Tabelle und dort sollte dann bei aktivem VPN Client immer das 192.168.7.0er IP Netz mit dem VPN Tunnelinterface als Next Hop angezeigt werden !
Traceroutes sollten dann auch in den Tunnel gehen.
Bitte warten ..
Mitglied: wusa88
12.05.2020, aktualisiert um 12:46 Uhr
Zitat von aqui:
Nein, normal nicht. Sofern Datum, Uhrzeit bzw. NTP Server stimmen kann man die problemlos portieren. Zertifikate sind aber immer von der genauen Uhrzeit abhängig. NTP Server hast du also hoffentlich in deinem MT konfiguriert ?!
Das muss ich gestehen, habe ich noch nie gemacht. Auch bei dem "Tower" wo alles funktionierte habe ich keinen NTP Server konfiguriert gehabt.
OK, das bedeutet der MT hält am WAN/Internet Port die öffentliche Provider IP Adresse, ist das richtig ?
Richtig
Der Fehler liegt sehr wahrscheinlich im Client selber....
Ich vermute fast nicht. Fehlermeldungen weiter unten.
Besorgniserregender ist deshalb das "11:07 Ausgeschlossene Routen: 192.168.7.0/24" was vermutlich das lokale LAN des OVPN Servers ist, richtig ?
Richtig
Der Android Client übernimmt diese IP Route nicht und damit ist ein Routen der Client IP Pakete in das 192.168.7.er Netz unmöglich, was dann das Problem erklärt.
Den OVPN Server selbst mit der internen 10.8.0.1 wirst du sicher pingen können, oder ? Sprich der Client kann rein nur auf dem Server arbeiten nicht aber im lokalen Server IP Netz weil er die IP Route dazu nicht übernimmt.
Das geht leider auch nicht, ich kann 10.8.0.1 nicht pingen.
Ein Traceroute mit den HE.net Tools sollte dir das auch ganz eindeutig zeigen ! Hast du das mal gecheckt ?!
Das habe ich gecheckt. Hier kommt allerdings keine Antwort, bzw. kommen nur "*" zurück. Was für mich bedeutet, dass keine Antwort kommt.
Der Android Client übernimmt vermutlich wegen fehlender Root oder User Rechten der OVPN App auf dem Device die 192.168.7.er Route nicht in den Kernel. Sprich es ist rein ein Problem des Android Clients.

Testweise könntest du mal versuchen ein:
user nobody
group nogroup

in die Client Konfig hinzuzufügen.
Das werde ich jetzt demnächst gleich noch testen.

Ich habe das ganze jetzt auch mal auf einem Windows PC getestet, mit dem es auch bisher immer problemlos funktionierte:
Leider kommt es hier auch zu Problemen.
An dieser Meldung stört mich am meisten dieser Eintrag:
Bitte warten ..
Mitglied: aqui
12.05.2020, aktualisiert um 15:53 Uhr
habe ich keinen NTP Server konfiguriert gehabt.
Böses Faul ! Besser ist das !
Das geht leider auch nicht, ich kann 10.8.0.1 nicht pingen.
Das bedeutet dann vermutlich Firewall Problematiken auf dem Client. Das man die interne IP nicht pingen kann ist schon außergewöhnlich wenn der Tunnelaufbau fehlerlos erfolgt ist.
Was für mich bedeutet, dass keine Antwort kommt.
Das ist richtig.
An dieser Meldung stört mich am meisten dieser Eintrag:
Das ist auch richtig !
Irgendwas stimmt mit dem Routing am Client nicht, das ist sicher. Wenn grundsätzlich was an den Zertifikaten nicht stimmen würde dann würdest du gar nicht so weit kommen.
Da Zertifikate aber immer eine Uhrzeit/Timestamp haben ist es zwingend beim Erstellen und auch Betrieb immer eine gültige Uhrzeit auf dem System zu haben. Das nur mal nebenbei und sollte man eigentlich wissen. NTP Server ist hier also Pflicht.
Das die Route auf die Clients nicht übernommen wird ist sehr ungewöhnlich. Das ist aber der Fehler.
Damit "kennt" der Client dann das Lokale Server LAN, also das remote LAN nicht und kann entsprechend Pakete dahin nicht in den Tunnel routen.
Das allerdings der Ping auf die interne 10.8.0.1 auch fehlschlägt zeigt das da schon das eigentliche Problem liegt. Den Pool der internen /30er IP Subnetze hast du richtig eingerichtet auf dem Server ?
Was ist das für ein Setup auf dem OVPN Server ?
Da der ja nur einbeinig angebunden ist, ist das eine Grundkonfig ein aktives Interface mit IP ohne die übliche Default Konfig oder wie ist der MT konfiguriert ?
Googelt man nach der Fehlermeldung weisen einige auf 2 Kommandos hin die am Client hinzugefügt werden sollten in dem Fall:
tap-sleep 3
route-delay 1 3

Siehe:
https://www.systemmen.com/security/vpn/fix-openvpn-route-gateway-is-not- ...
Die dortigen Kommandos unter Zeile 4 und 5 sind rein Windows Client spezifisch, die nutzen auf dem Androiden natürlich nichts !
Was merkwürdig ist ist, ist aber die Tatsache das es vorher auch ohne ging...?!
Bitte warten ..
Mitglied: wusa88
12.05.2020 um 20:12 Uhr
Zitat von aqui:

Böses Faul ! Besser ist das !
Ich werde mich darum kümmern. Dem komme ich die Tage mal nach!

Da Zertifikate aber immer eine Uhrzeit/Timestamp haben ist es zwingend beim Erstellen und auch Betrieb immer eine gültige Uhrzeit auf dem System zu haben. Das nur mal nebenbei und sollte man eigentlich wissen. NTP Server ist hier also Pflicht.
Erstelle habe ich die Zertifikate mit einem Raspberry Pi damals. Dieser war am Netz und war definitiv mit der richtigen Uhrzeit/Datum.

Das allerdings der Ping auf die interne 10.8.0.1 auch fehlschlägt zeigt das da schon das eigentliche Problem liegt. Den Pool der internen /30er IP Subnetze hast du richtig eingerichtet auf dem Server ?
Normalerweise ja.
Was ist das für ein Setup auf dem OVPN Server ?
Weiter unten kommen die ganzen Screenshots.
Da der ja nur einbeinig angebunden ist, ist das eine Grundkonfig ein aktives Interface mit IP ohne die übliche Default Konfig oder wie ist der MT konfiguriert ?
Doch ich habe die default Konfig genommen und an meine Bedürfnisse angepasst. Ich habe die default Konfig auch wegen den Firewall Grundeinstellungen genommen.
Googelt man nach der Fehlermeldung weisen einige auf 2 Kommandos hin die am Client hinzugefügt werden sollten in dem Fall:
tap-sleep 3
route-delay 1 3

Siehe:
https://www.systemmen.com/security/vpn/fix-openvpn-route-gateway-is-not- ...
Die dortigen Kommandos unter Zeile 4 und 5 sind rein Windows Client spezifisch, die nutzen auf dem Androiden natürlich nichts !
Das werde ich morgen Abend testen. Ich schaffe es jetzt leider nicht.
Was merkwürdig ist ist, ist aber die Tatsache das es vorher auch ohne ging...?!
Das war definitiv so. Ich habe den "Tower" noch nicht zurückgesetzt, bis alles auf dem neuen hAP Lite sauber läuft.
Ich könnte jederzeit zurück.
Ich konnte intern auf meine ganzen Geräte die ich benötige zugreifen.

Hier die Scrrenshots. Ich hoffe ich habe keinen vergessen.

certificates_1 - Klicke auf das Bild, um es zu vergrößern
pool_1 - Klicke auf das Bild, um es zu vergrößern
ppp_profile_1 - Klicke auf das Bild, um es zu vergrößern
pppsecret_1 - Klicke auf das Bild, um es zu vergrößern
ovpnserver_1 - Klicke auf das Bild, um es zu vergrößern
ovpnfirewall_1 - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: aqui
13.05.2020, aktualisiert um 10:37 Uhr
Doch ich habe die default Konfig genommen und an meine Bedürfnisse angepasst.
Das ist eigentlich sinnfrei wenn der Router rein nur als VPN Server ohne jegliche Routing Funktion läuft. Die dann aktive Firewall ist dann eher kontraproduktiv und es wäre besser eine simple Grundkonfig ohne Default Konfig laufen zu lassen.
Gut, dagegen spricht das es vorher funktionierte. Dennoch erschwert das aber unnötigerweise ein Troubleshooting. Vom Performance Verlust durch das doppelte Durchlaufen der Firewall jetzt mal gar nicht zu reden.
Ggf. solltest du also darüber nochmal grundsätzlich nachdenken.
Obwohl nach der Konfig des MT zu urteilen dieser ja gerade scheinbar nicht als rein einarmig angebundener nur VPN Server arbeitet. Die ganzen DHCP Pools sprechen dagegen und lassen eher von einem internen VLAN Router ausgehen.
Die Frage ist WAS denn jetzt wirklich richtig ist ?
Aber auch bei einem internen VLAN Router in einer Router Kaskade mit einem vorhandenen Internet Router wäre die Verwendung der aktiven NAT Firewall auf dem MT eher kontraproduktiv und macht nur dann Sinn wenn man z.B. sowas wie einen Speedport Schrottrouter hat der keine statischen IP Routen supportet.
Wie sieht also dein Design wirklich aus...??

Einen Kardinalsfehler hast du beim PPP Profile IP Adress Pool des Servers gemacht. Dort ist unter "Local Address" fälschlicherweise der LAN IP Pool angegeben !! Dort muss aber der OpenVPN Pool hin. Siehe o.a. Mikrotik OpenVPN Tutorial !!!
ovpn_ip - Klicke auf das Bild, um es zu vergrößern
Damit bekommt der Server keine oder eine völlig falsche IP.
Das könnte schon sehr wahrscheinlich der Grund sein warum es bei dir nicht klappt und der OVPN Client das IP Interface nicht erkennt und die Route deshalb nicht implementieren kann.
Typischer Flüchtigkeitsfehler ?!
Bitte beachte die Schritte und Screenshots des o.a. Mikrotik OpenVPN Tutorials genau und halte dich auch daran !
Bitte warten ..
Mitglied: wusa88
14.05.2020, aktualisiert um 09:52 Uhr
Zitat von aqui:
Das ist eigentlich sinnfrei wenn der Router rein nur als VPN Server ohne jegliche Routing Funktion läuft. Die dann aktive Firewall ist dann eher kontraproduktiv und es wäre besser eine simple Grundkonfig ohne Default Konfig laufen zu lassen.
Da haben wir uns vermutlich missverstanden, oder ich habe mich nicht sauber ausgedrückt.
Der Router ist mein Hauptrouter! Das Geräte von Vodafone ist nur dazu da, dass RJ45 auf Koax gewandelt wird und diese Geräte ist im Bridge Modus, sodass alles direkt zum Mikrotik durchgeschleift wird. Der hAP Lite ist dann für das gesamte Routing, VLAN usw. zuständig.

Obwohl nach der Konfig des MT zu urteilen dieser ja gerade scheinbar nicht als rein einarmig angebundener nur VPN Server arbeitet. Die ganzen DHCP Pools sprechen dagegen und lassen eher von einem internen VLAN Router ausgehen.
Richtig
Die Frage ist WAS denn jetzt wirklich richtig ist ?
Siehe oben.
Aber auch bei einem internen VLAN Router in einer Router Kaskade mit einem vorhandenen Internet Router wäre die Verwendung der aktiven NAT Firewall auf dem MT eher kontraproduktiv und macht nur dann Sinn wenn man z.B. sowas wie einen Speedport Schrottrouter hat der keine statischen IP Routen supportet.
Wie sieht also dein Design wirklich aus...??
Siehe oben
Einen Kardinalsfehler hast du beim PPP Profile IP Adress Pool des Servers gemacht. Dort ist unter "Local Address" fälschlicherweise der LAN IP Pool angegeben !! Dort muss aber der OpenVPN Pool hin. Siehe o.a. Mikrotik OpenVPN Tutorial !!!
ovpn_ip - Klicke auf das Bild, um es zu vergrößern
Damit bekommt der Server keine oder eine völlig falsche IP.
Das könnte schon sehr wahrscheinlich der Grund sein warum es bei dir nicht klappt und der OVPN Client das IP Interface nicht erkennt und die Route deshalb nicht implementieren kann.
Typischer Flüchtigkeitsfehler ?!
Bitte beachte die Schritte und Screenshots des o.a. Mikrotik OpenVPN Tutorials genau und halte dich auch daran !
Das war in der Tat mein Fehler und ich denke ich hatte hier auch einen falschen Gedanken.
Mein Gedanke war, dass Remote die 10.8.0.0/30 vergeben wird aber intern sollte der Client 192.168.7.0/24 erhalten.
Allerdings scheint diese hier falsch zu sein.

Außerdem muss ich mich noch bei dir bedanken!
Jetzt nachdem ich alles auf den OVPN Pool umgestellt habe, funktioniert es auch wieder so wie gewollt.
Ich komme auf meine internen Geräte und auch die App HE.net Tools hat mir dabei geholfen.

Deiner Aussage mit NTP komme ich natürlich noch nach!
Bitte warten ..
Mitglied: aqui
14.05.2020, aktualisiert um 10:58 Uhr
Da haben wir uns vermutlich missverstanden, oder ich habe mich nicht sauber ausgedrückt.
Sorry, du hast Recht. Das hatte ich in den falschen Hals bekommen...sorry.
Allerdings scheint diese hier falsch zu sein.
Nicht nur scheint es IST falsch !
Nur so viel zum Warum:
OpenVPN nutzt intern ja ein dediziertes Netzwerk. Das kann entweder klassisch das net30 Verfahren sein indem jeder Client ein /30er Subnetz bekommt oder das etwas modernere, da Adress- und Resourcen schonenden subnet Verfahren was die native Subnetz Adresse des internen Netzes verwendet.
Mikrotik supportet derzeit nur das klassische net30 Verfahren. Jeder Client bekommt also immer ein dediziertes Punkt zu Punkt Netz mit einer 30Bit Subnetzmaske.
Genau deshalb generierst du diesen /30er Pool mit den angehängten Folgepools im Mikrotik !
Client und Server bekommen also logischerweise immer IP Adressen aus diesem Pool aber niemals aus den lokalen IPs.
Kleine Ursache große Wirkung wenn man nicht aufpasst und die Tutorials nicht richtig liest !

Gut wenn nun alles rennt wie es soll.
Den NTP Server solltest du immer konfigurieren und auch per Option 42 im DHCP verteilen. Wie das geht zeigt dir das hiesige Mikrotik_VLAN_Tutorial

Wenn es das denn nun war bitte dann auch
https://administrator.de/faq/32
nicht vergessen
Bitte warten ..
Ähnliche Inhalte
Router & Routing
Mikrotik RB750GL - OpenVPN -
gelöst Frage von nightman67Router & Routing3 Kommentare

Hallo zusammen, ich habe ein kleines Problem mit dem einrichten oder der Konfiguration von OpenVpn. Meine Konfiguration des Mikrotik ...

Netzwerkgrundlagen
MikroTik als OpenVPN-Server
gelöst Frage von Alex29Netzwerkgrundlagen10 Kommentare

Hallo in die Runde, kann mir bitte jemand sagen, ob es Sinn hat weiter zu probieren ob ein OpenVPN-Server ...

Netzwerke

Mikrotik OpenVPN Server und Windows Client - Routing Probleme

gelöst Frage von MopskillerNetzwerke2 Kommentare

Hallo alle zusammen, ich habe zur Zeit eine kleine Testkonfiguration für ein späteres Netzwerk aufgebaut: Ich habe einen Lancom ...

Netzwerkprotokolle

MikroTik-Router antwortet nicht bei der OpenVPN-Einwahl

gelöst Frage von Datax87Netzwerkprotokolle6 Kommentare

Hallo, ich versuche gerade einen OpenVPN-Server auf einem MikroTik-Router aufzusetzen. Habe mich dabei an die Vorgehensweise auf folgender Seite ...

Neue Wissensbeiträge
Humor (lol)

Wie verhindere ich, dass Websitebesucher die Werbecookies abschalten?

Information von DerWoWusste vor 4 StundenHumor (lol)3 Kommentare

Ich habe gerade auf die Antwort gefunden: ich täusche einen langwierigen Änderungsprozess vor und biete nebenbei einen Cancelbutton, den ...

Sicherheit

Windows Setup erlaubt elevation of privilege plus DC Updates

Information von DerWoWusste vor 11 StundenSicherheit2 Kommentare

Eine interessante neue Sicherheitslücke. Details gibt es wenig, aber die klare Empfehlung: If you are using WSUS or MEM ...

Exchange Server

Exchange Server 2016 and the End of Mainstream Support

Information von Dani vor 1 TagExchange Server

As hopefully many of you already know Exchange Server 2016 enters the Extended Support phase of its product lifecycle ...

Viren und Trojaner

Schwachstelle in Teamviewer oder aufgeflogene Backdoor?

Information von magicteddy vor 1 TagViren und Trojaner

Moin, die Interpretation überlasse ich jedem selber, ich habe eine deutliche Abneigung dagegen. Wer es nutzen muss sollte schleunigst ...

Heiß diskutierte Inhalte
Internet
VPN und Fritzbox
Frage von jensgebkenInternet29 Kommentare

Hallo Gemeinschaft, da der Support von AVM mir keine Antwort gibt, versuche ich es hier einmal HArdware 7490 zwei ...

Sicherheit
Verschlüsseln anstatt löschen ?
Frage von TastuserSicherheit19 Kommentare

Hallo, ist es möglich ganze Ordner auf Windows 10 zu verschlüsseln? Aber keine Kopien zu verschlüsseln (wie mit WinRAR) ...

Windows Server
Windows Server "mit" oder "ohne" Antivirensoftware
Frage von Dr.MabuseWindows Server16 Kommentare

Antiviren-Software: Fluch oder Segen? Die Frage der Sinnhaftigkeit von Antiviren-Software ist nicht neu Die Software kostet Performance, sorgt oft ...

Switche und Hubs
Neue Switches für Schule
Frage von Freak-On-SiliconSwitche und Hubs15 Kommentare

Servus; Eins Vorweg, bin leider in vielen Sachen noch nicht so erfahren. Und nein, ich kann LEIDER keinen Dienstleister ...

Administrator Magazin
08 | 2020 Cloud-First-Strategien sind inzwischen die Regel und nicht mehr die Ausnahme und Workloads verlagern sich damit in die Cloud – auch Datenbanken. Dort geht es aber nicht nur um die Frage, wie die Datenbestände in die Wolke zu migrieren sind, sondern auch darum, welche Datenbank ...