Frage Sonstige Systeme MikroTik RouterOS

gelöst Clientverbindung OpenVPN Mikrotik

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).











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

Grüße Uwe

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

Japp, geht nicht hab ich alles schon durch. Die OpenVPN Umsetzung auf dem Mikrotik war leider schon immer sehr schlecht.
Ja.
Ich poste die hier später mal.

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/

Es kann definitiv so gelöst werden

Wenns das dann war, den Beitrag bitte noch auf gelöst setzen, und Lösungen markieren. Merci.

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!

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.

Ganz zu schweigen vom Client-Zertifikat, das hat auf dem Server nichts verloren. Da gehört in der Server-Config das Server-Zertifikat rein.

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.

Kein Thema, dafür sind wir ja eine Community .

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.
Eine Überlegung wäre UDP. Aber das muss nicht zwingend sein. Wenn TCP funktioniert, dann kann ich immer noch auf UDP umbauen.

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.
Ehrlich gesagt... Nein. Ich weiß auch nicht wie das Handhaben soll? Kenne mich da noch zu wenig aus.
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.

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.

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:

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.

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:

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


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 !

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:

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.

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.

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 !

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!

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 !

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.

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.

Nein, denn die RouterOS Firmware Version (nur darauf kommt es an !) ist ja immer identisch.
Musst du nicht, denn die stehen hier ja schon alle:
https://administrator.de/content/detail.php?id=359367&token=695#comm ...
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.

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

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

Das muss ich gestehen, habe ich noch nie gemacht. Auch bei dem "Tower" wo alles funktionierte habe ich keinen NTP Server konfiguriert gehabt.
Richtig
Ich vermute fast nicht. Fehlermeldungen weiter unten.
Richtig
Das geht leider auch nicht, ich kann 10.8.0.1 nicht pingen.
Das habe ich gecheckt. Hier kommt allerdings keine Antwort, bzw. kommen nur "*" zurück. Was für mich bedeutet, dass keine Antwort kommt.

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:

Böses Faul ! Besser ist das !
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.
Das ist richtig.
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...?!

Ich werde mich darum kümmern. Dem komme ich die Tage mal nach!

Erstelle habe ich die Zertifikate mit einem Raspberry Pi damals. Dieser war am Netz und war definitiv mit der richtigen Uhrzeit/Datum.

Normalerweise ja.
Weiter unten kommen die ganzen Screenshots.
Doch ich habe die default Konfig genommen und an meine Bedürfnisse angepasst. Ich habe die default Konfig auch wegen den Firewall Grundeinstellungen genommen.
Das werde ich morgen Abend testen. Ich schaffe es jetzt leider nicht.
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.

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

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 !

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.

Richtig
Siehe oben.
Siehe oben
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!