Clientverbindung OpenVPN Mikrotik
dauatitsbest (Level 1) - Jetzt verbinden
28.12.2017 um 15:11 Uhr, 9726 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
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
- LÖSUNG colinardo schreibt am 28.12.2017 um 15:16:08 Uhr
- LÖSUNG aqui schreibt am 28.12.2017 um 16:51:22 Uhr
- LÖSUNG colinardo schreibt am 28.12.2017 um 16:53:51 Uhr
- LÖSUNG aqui schreibt am 28.12.2017 um 16:54:56 Uhr
- LÖSUNG colinardo schreibt am 28.12.2017 um 16:53:51 Uhr
- LÖSUNG wusa88 schreibt am 28.02.2019 um 10:55:12 Uhr
- LÖSUNG aqui schreibt am 28.02.2019 um 16:56:30 Uhr
- LÖSUNG 138810 schreibt am 28.02.2019 um 18:25:39 Uhr
- LÖSUNG aqui schreibt am 28.02.2019 um 18:27:21 Uhr
- LÖSUNG 138810 schreibt am 28.02.2019 um 18:30:01 Uhr
- LÖSUNG aqui schreibt am 28.02.2019 um 18:27:21 Uhr
- LÖSUNG wusa88 schreibt am 28.02.2019 um 22:43:48 Uhr
- LÖSUNG aqui schreibt am 01.03.2019 um 20:37:02 Uhr
- LÖSUNG wusa88 schreibt am 05.03.2019 um 09:50:35 Uhr
- LÖSUNG aqui schreibt am 05.03.2019 um 13:47:44 Uhr
- LÖSUNG wusa88 schreibt am 05.03.2019 um 13:56:45 Uhr
- LÖSUNG aqui schreibt am 05.03.2019 um 18:04:46 Uhr
- LÖSUNG wusa88 schreibt am 13.03.2019 um 22:17:12 Uhr
- LÖSUNG aqui schreibt am 14.03.2019 um 16:58:32 Uhr
- LÖSUNG wusa88 schreibt am 15.03.2019 um 11:34:45 Uhr
- LÖSUNG wusa88 schreibt am 12.05.2020 um 10:07:09 Uhr
- LÖSUNG aqui schreibt am 12.05.2020 um 10:44:01 Uhr
- LÖSUNG wusa88 schreibt am 12.05.2020 um 11:16:49 Uhr
- LÖSUNG aqui schreibt am 12.05.2020 um 11:47:08 Uhr
- LÖSUNG wusa88 schreibt am 12.05.2020 um 12:45:42 Uhr
- LÖSUNG aqui schreibt am 12.05.2020 um 15:41:44 Uhr
- LÖSUNG wusa88 schreibt am 12.05.2020 um 20:12:13 Uhr
- LÖSUNG aqui schreibt am 13.05.2020 um 10:28:20 Uhr
- LÖSUNG wusa88 schreibt am 14.05.2020 um 09:50:40 Uhr
- LÖSUNG aqui schreibt am 14.05.2020 um 10:57:05 Uhr
- LÖSUNG wusa88 schreibt am 14.05.2020 um 09:50:40 Uhr
- LÖSUNG aqui schreibt am 13.05.2020 um 10:28:20 Uhr
- LÖSUNG wusa88 schreibt am 12.05.2020 um 20:12:13 Uhr
- LÖSUNG aqui schreibt am 12.05.2020 um 15:41:44 Uhr
- LÖSUNG wusa88 schreibt am 12.05.2020 um 12:45:42 Uhr
- LÖSUNG aqui schreibt am 12.05.2020 um 11:47:08 Uhr
- LÖSUNG wusa88 schreibt am 12.05.2020 um 11:16:49 Uhr
- LÖSUNG aqui schreibt am 12.05.2020 um 10:44:01 Uhr
- LÖSUNG wusa88 schreibt am 12.05.2020 um 10:07:09 Uhr
- LÖSUNG wusa88 schreibt am 15.03.2019 um 11:34:45 Uhr
- LÖSUNG aqui schreibt am 14.03.2019 um 16:58:32 Uhr
- LÖSUNG wusa88 schreibt am 13.03.2019 um 22:17:12 Uhr
- LÖSUNG aqui schreibt am 05.03.2019 um 18:04:46 Uhr
- LÖSUNG wusa88 schreibt am 05.03.2019 um 13:56:45 Uhr
- LÖSUNG aqui schreibt am 05.03.2019 um 13:47:44 Uhr
- LÖSUNG wusa88 schreibt am 05.03.2019 um 09:50:35 Uhr
- LÖSUNG aqui schreibt am 01.03.2019 um 20:37:02 Uhr
- LÖSUNG 138810 schreibt am 28.02.2019 um 18:25:39 Uhr
- LÖSUNG aqui schreibt am 28.02.2019 um 16:56:30 Uhr
- LÖSUNG aqui schreibt am 28.12.2017 um 16:51:22 Uhr
- LÖSUNG dauatitsbest schreibt am 08.01.2018 um 12:57:58 Uhr
- LÖSUNG aqui schreibt am 08.01.2018 um 15:37:34 Uhr
- LÖSUNG colinardo schreibt am 23.01.2018 um 16:17:28 Uhr
LÖSUNG 28.12.2017, aktualisiert um 16:59 Uhr
Servus,
der Mikrotik hat hier ein paar zwingende Anforderungen als da wären folgende
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).
Die Client-Config (Password Auth)
Wenn noch etwas unklar ist, kannst du mich gerne per PN kontaktieren.
Grüße Uwe
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).




Die Client-Config (Password Auth)
client
proto tcp
dev tun
remote <IP-DES-MIKROTIK> 1194
auth-user-pass
pull
# beispielhaft Route auf client setzen
# route 10.10.2.0 255.255.255.0
ca ca.crt
verb 3
mute 10
Grüße Uwe
LÖSUNG 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
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
LÖSUNG 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.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 ?
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.Hier:
https://wiki.mikrotik.com/wiki/OpenVPN#RouterOS
sieht man das so erstmal nicht.
LÖSUNG 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/
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/
LÖSUNG 08.01.2018 um 12:57 Uhr
LÖSUNG 23.01.2018 um 16:17 Uhr
Wenns das dann war, den Beitrag bitte noch auf gelöst setzen, und Lösungen markieren. Merci.
LÖSUNG 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:
Wegen der Firewall Regel bin ich mir nicht ganz sicher:
Auch hier ist noch eine Log Ausgabe:
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!
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:





Wegen der Firewall Regel bin ich mir nicht ganz sicher:
Auch hier ist noch eine Log Ausgabe:
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!
LÖSUNG 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
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.
LÖSUNG 28.02.2019, aktualisiert um 18:26 Uhr
LÖSUNG 28.02.2019 um 18:27 Uhr
LÖSUNG 28.02.2019 um 22:43 Uhr
Zitat von aqui:
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. 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 !
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 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.
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...Ganz zu schweigen vom Client-Zertifikat, das hat auf dem Server nichts verloren. Da gehört in der Server-Config das Server-Zertifikat rein.
Habe das Client gegen Server getauscht.
Auch mit dem Austausch von Client und Server Zertifikat funktioniert es nicht.
Client Log reiche ich morgen nach.
LÖSUNG 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:
Beachtet man diese etwas speziellen Punkte funktioniert es fehlerlos und ohne Probleme !
Der Testaufbau sieht so aus:
1.) Server Zertifikate importieren:
Das geht einfach über das "Files" Menü per drag and drop.
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)
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:
4.) Usernamen/Passwort einrichten und dem OVPN Profil zuweisen:
5.) OVPN Server einrichten und aktivieren:
6.) In der NAT Firewall OVPN Zugriff (hier TCP 1194) erlauben:
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:
Die relevanten Dateien liegen alle im Verzeichnis C:\Benutzer\<username>\OpenVPN\config
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):
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.
Das ein Ping dann ins remote LAN ebenso fehlerfrei läuft muss man sicher nicht noch extra betonen.
Fazit:
Alles fehlerfrei ! Works as designed !
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.
Beachtet man diese etwas speziellen Punkte funktioniert es fehlerlos und ohne Probleme !
Der Testaufbau sieht so aus:
Konfig Schritte Mikrotik (hier RB750)
1.) Server Zertifikate importieren:
Das geht einfach über das "Files" Menü per drag and drop.
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.
(Testweise hier für 4 Clients)
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:

4.) Usernamen/Passwort einrichten und dem OVPN Profil zuweisen:
5.) OVPN Server einrichten und aktivieren:

6.) In der NAT Firewall OVPN Zugriff (hier TCP 1194) erlauben:
Konfig Schritte OpenVPN Client (hier Raspberry Pi):
Verwendete OVPN Client Konfig Datei mikrotik.conf
dev tun
proto tcp-client
remote 10.99.1.149 1194
ca keys/ca.crt
cert keys/client1.crt
key keys/client1.key
cipher AES-256-CBC
auth SHA1
auth-nocache
tls-client
remote-cert-tls server
user nobody
group nogroup
persist-tun
persist-key
mute-replay-warnings
pull
route 192.168.88.0 255.255.255.0
auth-user-pass auth.cfg
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:
username
password
Check der OVPN Client Konfig mit manuellem Start in der Kommandozeile:
root@raspi:/etc/openvpn/client# openvpn --config mikrotik.conf
Fri Mar 1 18:20:39 2019 OpenVPN 2.4.0 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Oct 14 2018
Fri Mar 1 18:20:39 2019 library versions: OpenSSL 1.0.2r 26 Feb 2019, LZO 2.08
Fri Mar 1 18:20:39 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]10.99.1.149:1194
Fri Mar 1 18:20:39 2019 Attempting to establish TCP connection with [AF_INET]10.99.1.149:1194 [nonblock]
Fri Mar 1 18:20:40 2019 TCP connection established with [AF_INET]10.99.1.149:1194
Fri Mar 1 18:20:40 2019 TCP_CLIENT link local: (not bound)
Fri Mar 1 18:20:40 2019 TCP_CLIENT link remote: [AF_INET]10.99.1.149:1194
Fri Mar 1 18:20:40 2019 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Fri Mar 1 18:20:43 2019 [RB750] Peer Connection Initiated with [AF_INET]10.99.1.149:1194
Fri Mar 1 18:20:54 2019 TUN/TAP device tun0 opened
Fri Mar 1 18:20:54 2019 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Fri Mar 1 18:20:54 2019 /sbin/ip link set dev tun0 up mtu 1500
Fri Mar 1 18:20:54 2019 /sbin/ip addr add dev tun0 10.88.88.2/24 broadcast 10.88.88.255
Fri Mar 1 18:20:54 2019 GID set to nogroup
Fri Mar 1 18:20:54 2019 UID set to nobody
Fri Mar 1 18:20:54 2019 Initialization Sequence Completed
Das OVPN Tunnel Interface kommt auch sauber hoch mit richtiger IP:
root@raspi:/home/pi# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.7.169 netmask 255.255.255.0 broadcast 192.168.7.255
inet6 fe80::f0e8:9cd1:7505:6f51 prefixlen 64 scopeid 0x20<link>
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.88.88.2 netmask 255.255.255.0 destination 10.88.88.2
inet6 fe80::db7a:5b63:5171:db87 prefixlen 64 scopeid 0x20<link>
root@raspi:/etc/openvpn# netstat -r -n
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default 192.168.7.254 0.0.0.0 UG 0 0 0 eth0
10.88.88.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.7.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.88.0 10.88.88.1 255.255.255.0 UG 0 0 0 tun0
root@raspi:/etc/openvpn# ping -c 3 192.168.88.1
PING 192.168.88.1 (192.168.88.1) 56(84) bytes of data.
64 bytes from 192.168.88.1: icmp_seq=1 ttl=64 time=1.74 ms
64 bytes from 192.168.88.1: icmp_seq=2 ttl=64 time=1.59 ms
64 bytes from 192.168.88.1: icmp_seq=3 ttl=64 time=1.90 ms
--- 192.168.88.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 1.590/1.748/1.907/0.133 ms
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
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.
dev tun
proto tcp-client
remote 10.99.1.149 1194 # Remote OpenVPN Servername or IP address
ca ca.crt
cert client3.crt
key client3.key
auth-nocache
tls-client
remote-cert-tls server
persist-tun
persist-key
mute-replay-warnings
verb 1
cipher AES-256-CBC
auth SHA1
pull
route 192.168.88.0 255.255.255.0
auth-user-pass auth.cfg
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):
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.

Fazit:
Alles fehlerfrei ! Works as designed !
LÖSUNG 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:
IP Pools
PPP Profile
PPP Secrets
OpenVPN Server
Firewall
Client ist ein Windows PC. Hier meine Config:
Problem ist jetzt, dass ich folgenden Fehler im Mikrotik Log erhalte:
Und hier noch die Logausgabe vom Windows Client:
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:
IP Pools
PPP Profile

PPP Secrets

OpenVPN Server

Firewall
Client ist ein Windows PC. Hier meine Config:
dev tun
proto tcp-client
remote xxxxxxxx.sn.mynetname.net 1194
ca ca.crt
cert client1.crt
key client1.key
auth-nocache
tls-client
remote-cert-tls server
persist-tun
persist-key
#mute-replay-warnings
verb 1
cipher AES-256-CBC
auth SHA1
pull
route 192.168.7.0 255.255.255.0
Und hier noch die Logausgabe vom Windows Client:
Tue Mar 05 09:24:53 2019 OpenVPN 2.3.14 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Dec 7 2016
Tue Mar 05 09:24:53 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Tue Mar 05 09:24:53 2019 library versions: OpenSSL 1.0.2i 22 Sep 2016, LZO 2.09
Enter Management Password:
Tue Mar 05 09:24:54 2019 Attempting to establish TCP connection with [AF_INET]188..xxx.xxx.xxx:1194 [nonblock]
Tue Mar 05 09:24:55 2019 TCP connection established with [AF_INET]188..xxx.xxx.xxx:1194
Tue Mar 05 09:24:55 2019 TCPv4_CLIENT link local: [undef]
Tue Mar 05 09:24:55 2019 TCPv4_CLIENT link remote: [AF_INET]188..xxx.xxx.xxx:1194
Tue Mar 05 09:25:55 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Mar 05 09:25:55 2019 TLS Error: TLS handshake failed
Tue Mar 05 09:25:55 2019 Fatal TLS error (check_tls_errors_co), restarting
Tue Mar 05 09:25:55 2019 SIGUSR1[soft,tls-error] received, process restarting
Tue Mar 05 09:25:58 2019 SIGTERM[hard,init_instance] received, process exiting
LÖSUNG 05.03.2019 um 13:47 Uhr
LÖSUNG 05.03.2019 um 13:56 Uhr
LÖSUNG 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 !
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 !
LÖSUNG 13.03.2019 um 22:17 Uhr
LÖSUNG 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 !
LÖSUNG 15.03.2019 um 11:34 Uhr
LÖSUNG 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.
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
dev tun
proto tcp-client
remote xxxxx.sn.mynetname.net 63558
ca ca.crt
cert client1.crt
key client1.key
auth-nocache
tls-client
remote-cert-tls server
persist-tun
persist-key
verb 1
cipher AES-256-CBC
auth SHA1
auth-user-pass pass.txt
pull
route 192.168.7.0 255.255.255.0
LÖSUNG 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.
LÖSUNG 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. Nein, denn die RouterOS Firmware Version (nur darauf kommt es an !) ist ja immer 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:Edit:
Hier noch der OpenVPN Log vom Smartphone direkt.
LÖSUNG 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.
LÖSUNG 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. 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 ?!
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 ?
RichtigDer 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. 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.
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. user nobody
group nogroup
in die Client Konfig hinzuzufügen.
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.
Tue May 12 12:39:19 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]188.xxx.xxx.35:63558
Tue May 12 12:39:19 2020 Attempting to establish TCP connection with [AF_INET]188.xxx.xxx.35:63558 [nonblock]
Tue May 12 12:39:20 2020 TCP connection established with [AF_INET]188.xxx.xxx.35:63558
Tue May 12 12:39:20 2020 TCP_CLIENT link local: (not bound)
Tue May 12 12:39:20 2020 TCP_CLIENT link remote: [AF_INET]188.xxx.xxx.35:63558
Tue May 12 12:39:22 2020 [haplite] Peer Connection Initiated with [AF_INET]188.xxx.xxx.35:63558
Tue May 12 12:39:34 2020 open_tun
Tue May 12 12:39:34 2020 TAP-WIN32 device [Ethernet 5] opened: \\.\Global\{0957E5B9-1C47-4977-9E5E-AA8D52A7CDA4}.tap
Tue May 12 12:39:34 2020 Set TAP-Windows TUN subnet mode network/local/netmask = 10.8.0.0/10.8.0.1/255.255.255.0 [SUCCEEDED]
Tue May 12 12:39:34 2020 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.1/255.255.255.0 on interface {0947E4B9-1C47-4977-9E5E-AA8D52A7CDA4} [DHCP-serv: 10.8.0.254, lease-time: 31536000]
Tue May 12 12:39:34 2020 Successful ARP Flush on interface [3] {0957E5B9-1C47-4977-9E5E-AA8D52A7CDA4}
Tue May 12 12:40:09 2020 Warning: route gateway is not reachable on any active network adapters: 192.168.7.247
Tue May 12 12:40:09 2020 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
SYSTEM ROUTING TABLE
0.0.0.0 0.0.0.0 192.168.70.1 p=0 i=9 t=4 pr=3 a=2178894 h=0 m=50/0/0/0/0
10.8.0.0 255.255.255.0 10.8.0.1 p=0 i=3 t=3 pr=2 a=35 h=0 m=291/0/0/0/0
10.8.0.1 255.255.255.255 10.8.0.1 p=0 i=3 t=3 pr=2 a=35 h=0 m=291/0/0/0/0
10.8.0.255 255.255.255.255 10.8.0.1 p=0 i=3 t=3 pr=2 a=35 h=0 m=291/0/0/0/0
80.xxx.xxx.139 255.255.255.255 192.168.70.1 p=0 i=9 t=4 pr=3 a=2178551 h=0 m=50/0/0/0/0
127.0.0.0 255.0.0.0 127.0.0.1 p=0 i=1 t=3 pr=2 a=2179293 h=0 m=331/0/0/0/0
127.0.0.1 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=2179293 h=0 m=331/0/0/0/0
127.255.255.255 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=2179293 h=0 m=331/0/0/0/0
192.168.7.0 255.255.255.0 192.168.7.247 p=0 i=9 t=4 pr=3 a=0 h=0 m=51/0/0/0/0
192.168.70.0 255.255.255.0 192.168.70.250 p=0 i=9 t=3 pr=2 a=19478 h=0 m=306/0/0/0/0
192.168.70.250 255.255.255.255 192.168.70.250 p=0 i=9 t=3 pr=2 a=19478 h=0 m=306/0/0/0/0
192.168.70.255 255.255.255.255 192.168.70.250 p=0 i=9 t=3 pr=2 a=19478 h=0 m=306/0/0/0/0
224.0.0.0 240.0.0.0 127.0.0.1 p=0 i=1 t=3 pr=2 a=2179293 h=0 m=331/0/0/0/0
224.0.0.0 240.0.0.0 192.168.70.250 p=0 i=9 t=3 pr=2 a=2179276 h=0 m=306/0/0/0/0
224.0.0.0 240.0.0.0 10.8.0.1 p=0 i=3 t=3 pr=2 a=19484 h=0 m=291/0/0/0/0
255.255.255.255 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=2179293 h=0 m=331/0/0/0/0
255.255.255.255 255.255.255.255 192.168.70.250 p=0 i=9 t=3 pr=2 a=2179276 h=0 m=306/0/0/0/0
255.255.255.255 255.255.255.255 10.8.0.1 p=0 i=3 t=3 pr=2 a=19484 h=0 m=291/0/0/0/0
SYSTEM ADAPTER LIST
------
Hier kommen alle Netzwerkadapter...
Daher ausgeschnitten
----------
Tue May 12 12:40:09 2020 Initialization Sequence Completed With Errors ( see http://openvpn.net/faq.html#dhcpclientserv )
Tue May 12 12:40:09 2020 Warning: route gateway is not reachable on any active network adapters: 192.168.7.247
LÖSUNG 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...?!
LÖSUNG 12.05.2020 um 20:12 Uhr
Ich werde mich darum kümmern. Dem komme ich die Tage mal nach!
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.

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. 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...?!
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.



LÖSUNG 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 !!!

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 !
LÖSUNG 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. 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.
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.
RichtigDie 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 obenWie 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 !!!
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. 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 !
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!
LÖSUNG 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