47
Clientverbindung OpenVPN Mikrotik
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 359367
Url: https://administrator.de/contentid/359367
Printed on: April 23, 2024 at 09:04 o'clock
47 Comments
Latest comment
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 10Wenn 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
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
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.
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/
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.
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.
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!
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!
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.
Ganz zu schweigen vom Client-Zertifikat, das hat auf dem Server nichts verloren. Da gehört in der Server-Config das Server-Zertifikat rein.
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.
Kein Thema, dafür sind wir ja eine Community .
.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. (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
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.
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:
Hinweis:
Den Zertifikats Import muss man nur dann machen wenn man sich bereits extern z.B. mit easy-rsa oder xca Zertifikate erzeugt hat ! Siehe auch OpenVPN_Tutorial.
Ansonsten ist das bei einer Neuinstallation NICHT notwendig und kann natürlich auch direkt auf dem Mikrotik selber gemacht werden. Dieses_Tutorial zeigt genau wie.
Das Importieren vorhandener Zertifikate geht recht 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.
Dieses_Tutorial beschreibt ebenfalls die Import Funktion noch einmal genau.
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:
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 !
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 Tunnel Encapsulation sondern derzeit 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:
Hinweis:
Den Zertifikats Import muss man nur dann machen wenn man sich bereits extern z.B. mit easy-rsa oder xca Zertifikate erzeugt hat ! Siehe auch OpenVPN_Tutorial.
Ansonsten ist das bei einer Neuinstallation NICHT notwendig und kann natürlich auch direkt auf dem Mikrotik selber gemacht werden. Dieses_Tutorial zeigt genau wie.
Das Importieren vorhandener Zertifikate geht recht einfach über das "Files" Menü per drag and drop.
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.
Dieses_Tutorial beschreibt ebenfalls die Import Funktion noch einmal genau.
(Testweise hier für 4 Clients)
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 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):
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 !
1
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.0Problem ist jetzt, dass ich folgenden Fehler im Mikrotik Log erhalte:
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
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.
Entferne mal das "remote-cert-tls server" in deiner Client Konfig und versuche nochmal.
1
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.
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 !
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 !
1
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!
Dann die ganze Anleitung nochmal von vorne Schritt für Schritt befolgt.
Und siehe da... es funktioniert!
Danke für die Hilfe!
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
How can I mark a post as solved?
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.
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.
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.0Gerne kann ich auch nochmal alle Schritte die ich im Mikrotik eingestellt habe, hier posten.
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:Clientverbindung OpenVPN Mikrotik
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.
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.
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.
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 ?
RichtigDer 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.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.247habe 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...?!
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.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.
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 !
1Zitat 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.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!
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
How can I mark a post as solved?
nicht vergessen
1
Hi,
ich habe eben die obere Konfig ausprobiert und alles gunktioniert einwandfrei, danke dafür. Ich nutze VLANs auf dem Mikrotik und frage mich, ob es möglich ist den IP-Pool des OVPN in ein VLAN zu packen. Das würde mir die Firewall-Regeln etwas übersichtlicher machen. Wie macht man das am besten?
VG Wapitifass
ich habe eben die obere Konfig ausprobiert und alles gunktioniert einwandfrei, danke dafür. Ich nutze VLANs auf dem Mikrotik und frage mich, ob es möglich ist den IP-Pool des OVPN in ein VLAN zu packen. Das würde mir die Firewall-Regeln etwas übersichtlicher machen. Wie macht man das am besten?
VG Wapitifass
Glückwunsch das es nun klappt. 👏
Die Frage mit dem VLAN DHCP Adress Pool und dem IP Adressing Pool des internen OpenVPN IP Netzes verstehe ich leider nicht wirklich. Es sind ja 2 ganz unterschiedliche Baustellen die per se erstmal nichts miteinander zu tun haben. Kannst du da ggf. etwas genauer werden ?!
Die Frage mit dem VLAN DHCP Adress Pool und dem IP Adressing Pool des internen OpenVPN IP Netzes verstehe ich leider nicht wirklich. Es sind ja 2 ganz unterschiedliche Baustellen die per se erstmal nichts miteinander zu tun haben. Kannst du da ggf. etwas genauer werden ?!
Also, mein Netz ist momentan so aufgebaut:
VLAN10 10.10.10.0/24
VLAN20 10.10.20.0/24
VLAN30 10.10.30.0/24
OVPN Pool 10.10.100.100-200
Jetzt dachte ich, dass es doch nur konsequent wäre, wenn ich die 100er IPs des OVPN in ein 100 VLAN packe oder ist das vergebliche Mühe / geht das überhaupt? Du meintest ja, dass es zwei völlig unterschiedliche Baustellen sind. Ich kenne mich mit OVPN leider nicht wirklich aus.
VG
VLAN10 10.10.10.0/24
VLAN20 10.10.20.0/24
VLAN30 10.10.30.0/24
OVPN Pool 10.10.100.100-200
Jetzt dachte ich, dass es doch nur konsequent wäre, wenn ich die 100er IPs des OVPN in ein 100 VLAN packe oder ist das vergebliche Mühe / geht das überhaupt? Du meintest ja, dass es zwei völlig unterschiedliche Baustellen sind. Ich kenne mich mit OVPN leider nicht wirklich aus.
VG
OpenVPN und VLAN ist wie Fisch und Fahrrad. 2 unterschiedliche Baustellen. Das ist dir hoffentlich klar, oder ? Ein Pool ist erstmal nur ein Adresspool und der OVPN Pool hat nichts mit dem VLAN Pool zu tun außer das beides nur eine Gruppe von IP Adressen sind. Nicht mehr und nicht weniger. Der eine Adresspool x wird nur für OpenVPN intern benutzt, der andere Pool y für den VLAN DHCP. Der Pool ist eben nur ein Pool und völlig unabhängig davon welche Netzwerk Funktion ihn später benutzt.
Die Frage ist so als wenn du einen Kanister Benzin hast den du im Auto und im Rasenmäher nutzen kannst aber dann jemanden fragst wie du mit dem Auto dann den Rasen mähen sollst, denn du hast den Kanister Benzin ja schon im Tank.
Es ist also etwas unklar was du mit deiner Frage genau meinst wenn du ein reines Layer 2 Feature wie VLAN irgendwie in Verbindung mit einem Layer 3 Feature wie OpenVPN bringen willst. Es fällt da leider sehr schwer deinen Gedankengängen zu folgen oder man missversteht die Frage. Vermutlich ist das aber auch deiner Unkenntniss zu OpenVPN (und/oder DHCP) geschuldet ?!
Lies dir einmal das hiesige OpenVPN Grundlagen Tutorial durch und zusätzlich auch das VLAN Tutorial. Vielleicht hilft dir das etwas zur Beantwortung deiner Frage:
Merkzettel: VPN Installation mit OpenVPN
Die Frage ist so als wenn du einen Kanister Benzin hast den du im Auto und im Rasenmäher nutzen kannst aber dann jemanden fragst wie du mit dem Auto dann den Rasen mähen sollst, denn du hast den Kanister Benzin ja schon im Tank.
Es ist also etwas unklar was du mit deiner Frage genau meinst wenn du ein reines Layer 2 Feature wie VLAN irgendwie in Verbindung mit einem Layer 3 Feature wie OpenVPN bringen willst. Es fällt da leider sehr schwer deinen Gedankengängen zu folgen oder man missversteht die Frage. Vermutlich ist das aber auch deiner Unkenntniss zu OpenVPN (und/oder DHCP) geschuldet ?!
Lies dir einmal das hiesige OpenVPN Grundlagen Tutorial durch und zusätzlich auch das VLAN Tutorial. Vielleicht hilft dir das etwas zur Beantwortung deiner Frage:
Merkzettel: VPN Installation mit OpenVPN
Alles klar, werde ich mir ansehen. Dann macht das wohl keine Sinn. Danke.
Einen schönen Sonntag euch allen,
ich hoffe es ist ok, dass ich diesen Thread nach fast einem Jahr wieder hervorhole, aber die Anleitung von @aqui ist die einzige die bei mir zumindest Ansatzweise funktioniert hat...
Zu den Gegebenheiten:
Fritzbox6660 Bridged -> WAN v. Mikrotik Hex s mit default config
Ein Zugriff aufs Internet ist möglich und es wird auch eine eigene IPv4 zugewiesen.
IPv6 sowohl bei der Fritzbox als auch im Mikrotik deaktiviert.
Ich habe mich strikt an die Anleitung von Aqui gehalten und nach einigen Versuchen (aufgrund von Flüchtigkeitsfehlern) konnte ich dann endlich eine Verbindung (Windows 10 testweise mit dem Hotspot meines Handys verbunden) herstellen. Aber was ich auch Probiere, es lassen sich keine Seiten aufrufen. Weder über URL noch direkt über eine IP. Allerdings kann ich über CMD sowohl den Mikrotik als auch diverse IP's anpingen...
Ich weiß langsam nicht mehr weiter... okay wahrscheinlich nicht verwunderlich da ich kein gelernter ITler bin, aber so ganz dunkel bin ich auch wieder nicht ;D
noch paar Infos die vllt helfen könnten:
OpenVPN-Client Log:
Mikrotik Log:
Firewall:
Ich würde mich sehr freuen, wenn jemand mir helfen würde)
LG Leoooo
ich hoffe es ist ok, dass ich diesen Thread nach fast einem Jahr wieder hervorhole, aber die Anleitung von @aqui ist die einzige die bei mir zumindest Ansatzweise funktioniert hat...
Zu den Gegebenheiten:
Fritzbox6660 Bridged -> WAN v. Mikrotik Hex s mit default config
Ein Zugriff aufs Internet ist möglich und es wird auch eine eigene IPv4 zugewiesen.
IPv6 sowohl bei der Fritzbox als auch im Mikrotik deaktiviert.
Ich habe mich strikt an die Anleitung von Aqui gehalten und nach einigen Versuchen (aufgrund von Flüchtigkeitsfehlern) konnte ich dann endlich eine Verbindung (Windows 10 testweise mit dem Hotspot meines Handys verbunden) herstellen. Aber was ich auch Probiere, es lassen sich keine Seiten aufrufen. Weder über URL noch direkt über eine IP. Allerdings kann ich über CMD sowohl den Mikrotik als auch diverse IP's anpingen...
Ich weiß langsam nicht mehr weiter... okay wahrscheinlich nicht verwunderlich da ich kein gelernter ITler bin, aber so ganz dunkel bin ich auch wieder nicht ;D
noch paar Infos die vllt helfen könnten:
OpenVPN-Client Log:
[Feb 13, 2022, 15:52:34] OpenVPN core 3.git::d3f8b18b win x86_64 64-bit built on Dec 8 2021 12:04:20
⏎[Feb 13, 2022, 15:52:34] Frame=512/2048/512 mssfix-ctrl=1250
⏎[Feb 13, 2022, 15:52:34] UNUSED OPTIONS
6 [auth-nocache]
7 [tls-client]
9 [persist-tun]
10 [persist-key]
11 [mute-replay-warnings]
12 [verb] [1]
15 [pull]
⏎[Feb 13, 2022, 15:52:34] EVENT: RESOLVE ⏎[Feb 13, 2022, 15:52:34] EVENT: WAIT ⏎[Feb 13, 2022, 15:52:34] WinCommandAgent: transmitting bypass route to "mikrotik-IP"
{
"host" : "mikrotik-IP",
"ipv6" : false
}
⏎[Feb 13, 2022, 15:52:34] Connecting to [vpn.adress.tld]:1194 ("mikrotik-IP") via TCPv4
⏎[Feb 13, 2022, 15:52:34] EVENT: CONNECTING ⏎[Feb 13, 2022, 15:52:34] Tunnel Options:V4,dev-type tun,link-mtu 1559,tun-mtu 1500,proto TCPv4_CLIENT,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client
⏎[Feb 13, 2022, 15:52:34] Creds: Username/Password
⏎[Feb 13, 2022, 15:52:34] Peer Info:
IV_VER=3.git::d3f8b18b
IV_PLAT=win
IV_NCP=2
IV_TCPNL=1
IV_PROTO=30
IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
IV_IPv6=0
IV_AUTO_SESS=1
IV_GUI_VER=OCWindows_3.3.4-2600
IV_SSO=webauth,openurl,crtext
⏎[Feb 13, 2022, 15:52:35] SSL Handshake: peer certificate: CN=vpn.adress.tld, 2048 bit RSA, cipher: ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
⏎[Feb 13, 2022, 15:52:35] Session is ACTIVE
⏎[Feb 13, 2022, 15:52:35] EVENT: GET_CONFIG ⏎[Feb 13, 2022, 15:52:35] Sending PUSH_REQUEST to server...
⏎[Feb 13, 2022, 15:52:36] Sending PUSH_REQUEST to server...
⏎[Feb 13, 2022, 15:52:38] Sending PUSH_REQUEST to server...
⏎[Feb 13, 2022, 15:52:38] OPTIONS:
0 [route] [192.168.88.0] [255.255.255.0]
1 [dhcp-option] [DNS] [192.168.88.1]
2 [ping] [20]
3 [ping-restart] [60]
4 [topology] [subnet]
5 [route-gateway] [10.88.88.100]
6 [ifconfig] [10.88.88.99] [255.255.255.0]
7 [block-ipv6]
⏎[Feb 13, 2022, 15:52:38] PROTOCOL OPTIONS:
cipher: AES-256-CBC
digest: SHA1
key-derivation: OpenVPN PRF
compress: NONE
peer ID: -1
⏎[Feb 13, 2022, 15:52:38] EVENT: ASSIGN_IP ⏎[Feb 13, 2022, 15:52:38] CAPTURED OPTIONS:
Session Name: vpn.addr.tld
Layer: OSI_LAYER_3
Remote Address: mikrotik-IP
Tunnel Addresses:
10.88.88.99/24 -> 10.88.88.100
Reroute Gateway: IPv4=0 IPv6=0 flags=[ IPv4 ]
Block IPv6: yes
Add Routes:
192.168.88.0/24
Exclude Routes:
DNS Servers:
192.168.88.1
Search Domains:
⏎[Feb 13, 2022, 15:52:39] SetupClient: transmitting tun setup list to \\.\pipe\agent_ovpnconnect
{
"allow_local_dns_resolvers" : true,
"confirm_event" : "4816000000000000",
"destroy_event" : "7816000000000000",
"tun" :
{
"adapter_domain_suffix" : "",
"add_routes" :
[
{
"address" : "192.168.88.0",
"gateway" : "",
"ipv6" : false,
"metric" : -1,
"net30" : false,
"prefix_length" : 24
}
],
"block_ipv6" : true,
"dns_servers" :
[
{
"address" : "192.168.88.1",
"ipv6" : false
}
],
"layer" : 3,
"mtu" : 0,
"remote_address" :
{
"address" : "mikrotik-IP",
"ipv6" : false
},
"reroute_gw" :
{
"flags" : 256,
"ipv4" : false,
"ipv6" : false
},
"route_metric_default" : -1,
"session_name" : "vpn.address.tld",
"tunnel_address_index_ipv4" : 0,
"tunnel_address_index_ipv6" : -1,
"tunnel_addresses" :
[
{
"address" : "10.88.88.99",
"gateway" : "10.88.88.100",
"ipv6" : false,
"metric" : -1,
"net30" : false,
"prefix_length" : 24
}
]
},
"wintun" : false
}
POST np://[\\.\pipe\agent_ovpnconnect]/tun-setup : 200 OK
TAP ADAPTERS:
guid='{AA02A067-E1F1-47F5-90A2-B2163FAAE9D1}' index=69 name='LAN-Verbindung 2'
Open TAP device "LAN-Verbindung 2" PATH="\\.\Global\{AA02A067-E1F1-47F5-90A2-B2163FAAE9D1}.tap" SUCCEEDED
TAP-Windows Driver Version 9.24
ActionDeleteAllRoutesOnInterface iface_index=69
netsh interface ip set interface 69 metric=1
OK.
netsh interface ip set address 69 static 10.88.88.99 255.255.255.0 gateway=10.88.88.100 store=active
netsh interface ipv6 add route 2000::/4 interface=1 store=active
OK.
netsh interface ipv6 add route 3000::/4 interface=1 store=active
OK.
netsh interface ipv6 add route fc00::/7 interface=1 store=active
OK.
IPHelper: add route 192.168.88.0/24 69 10.88.88.100 metric=-1
netsh interface ip set dnsservers 69 static 192.168.88.1 register=primary validate=no
NRPT::ActionCreate names= dns_servers=[192.168.88.1]
ActionWFP openvpn_app_path=C:\Program Files\OpenVPN Connect\OpenVPNConnect.exe tap_index=69 enable=1
permit IPv4 DNS requests to 127.0.0.1
permit IPv6 DNS requests to ::1
permit IPv4 DNS requests from OpenVPN app
permit IPv6 DNS requests from OpenVPN app
block IPv4 DNS requests from other apps
block IPv6 DNS requests from other apps
allow IPv4 traffic from TAP
allow IPv6 traffic from TAP
ipconfig /flushdns
Windows-IP-Konfiguration
Der DNS-Auflösungscache wurde geleert.
TAP: ARP flush succeeded
TAP handle: 7816000000000000
⏎[Feb 13, 2022, 15:52:39] Connected via TUN_WIN
⏎[Feb 13, 2022, 15:52:39] EVENT: CONNECTED user@vpn.address.tld:1194 (Mikrotik-IP) via /TCPv4 on TUN_WIN/10.88.88.99/ gw=[10.88.88.100/]⏎[Feb 13, 2022, 15:53:30] SetupClient: signaling tun destroy event
⏎[Feb 13, 2022, 15:53:30] EVENT: DISCONNECTED ⏎Mikrotik Log:
15:52:30 ovpn,info connection established from 109.40.2.155, port: 1651
15:52:31 ovpn,info : using encoding - AES-256-CBC/SHA1
15:52:31 ovpn,info,account Leo logged in, 10.88.88.99 from "Hotspot-IP"
15:52:31 ovpn,info <ovpn-Leo>: connected
15:53:26 ovpn,info <ovpn-Leo>: terminating... - peer disconnected
15:53:26 ovpn,info,account Leo logged out, 55 9160 7412 133 99 from "Hotspot-IP"
15:53:26 ovpn,info <ovpn-Leo>: disconnected
15:53:39 interface,info ether2 link up (speed 1G, full duplex)Firewall:
Ich würde mich sehr freuen, wenn jemand mir helfen würde
)LG Leoooo
Sehr wahrscheinlich ein MTU Problem, das die Tunnel MTU nicht angepasst wurde. Ggf. solltest du die mal testweise auf 1300 setzen was klein genug ist das alles durchgeht.
Checke dann mit einem Ping und wechselnder MTU Size was noch durchgeht bei dir.
Tip:
Vergiss die Frickelei mit OpenVPN. Schlechter Durchsatz und du brauchst ewig einen Extra Client für das VPN.
Wenn du das bordeigene L2TP VPN in ALLEN Geräten nutzt hast du all diese Probleme nicht mehr:
Scheitern am IPsec VPN mit MikroTik
Checke dann mit einem Ping und wechselnder MTU Size was noch durchgeht bei dir.
Tip:
Vergiss die Frickelei mit OpenVPN. Schlechter Durchsatz und du brauchst ewig einen Extra Client für das VPN.
Wenn du das bordeigene L2TP VPN in ALLEN Geräten nutzt hast du all diese Probleme nicht mehr:
Scheitern am IPsec VPN mit MikroTik
Danke schon mal für die Rückmeldung.
Das mit dem MTU probiere ich mal aus.
Ansonsten, warum ich mich für OVPN entschieden habe, bei uns auf der Arbeit sind die meisten Ports gesperrt deshalb wollte ich mich mit meinem Privaten PC dann über den 443 mit meinem Netzwerk zuhause verbinden. Wenn es dafür ne alternative gibt, gerne her damit. Downloadrate ist nicht so wichtig eher der Ping.
Das mit dem MTU probiere ich mal aus.
Ansonsten, warum ich mich für OVPN entschieden habe, bei uns auf der Arbeit sind die meisten Ports gesperrt deshalb wollte ich mich mit meinem Privaten PC dann über den 443 mit meinem Netzwerk zuhause verbinden. Wenn es dafür ne alternative gibt, gerne her damit. Downloadrate ist nicht so wichtig eher der Ping.
Zitat von @aqui:
Sehr wahrscheinlich ein MTU Problem, das die Tunnel MTU nicht angepasst wurde. Ggf. solltest du die mal testweise auf 1300 setzen was klein genug ist das alles durchgeht.
Checke dann mit einem Ping und wechselnder MTU Size was noch durchgeht bei dir.
Sehr wahrscheinlich ein MTU Problem, das die Tunnel MTU nicht angepasst wurde. Ggf. solltest du die mal testweise auf 1300 setzen was klein genug ist das alles durchgeht.
Checke dann mit einem Ping und wechselnder MTU Size was noch durchgeht bei dir.
Ich habe MTU unter
OVPN Server
OVPN Windows Adapter
OVPN Client config
Pingen kann ich Interessanterweise nur bis MTU 996 aber auch wenn ich alles auf 900 setze kann ich mich nur verbinden...
Könnte es auch ein einfaches DNS Problem sein? Denn wenn ich eine IP anpinge geht es aber wenn ich zb. google.de anpingen will kommt ein Fehler...
meine client config:
dev tun
proto tcp-client
remote vpn.domain.tld 1194 # Remote OpenVPN Servername or IP address
ca ca.crt
cert client.crt
key client.key
auth-nocache
tls-client
remote-cert-tls server
persist-tun
tun-mtu 900
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 mit meinem Privaten PC dann über den 443 mit meinem Netzwerk zuhause verbinden.
OK, da hast du dann Recht. Solange du dann nicht gegen Security Policies der Firma und damit gegen deinen Arbeitsvertrag verstößt, weil du damit eine Gefährdung der Firmen IT darstellst, ist das absolut OK. Dann musst du natürlich ein SSL VPN wie OpenVPN oder WireGuard nutzen, keine Frage.Könnte es auch ein einfaches DNS Problem sein?
Könnte natürlich auch sein. Aber du sagst ja auch nackte IPs kannst du nicht erreichen. Das schliesst dann wieder ein DNS Problem aus.Außerdem kannst du das auch mit ipconfig -all immer sehen WER der DNS Server an deinem (Windows) Client ist. Wenn das ein externer DNS ist kann der lokale Firmendomains natürlich NICHT auflösen, das ist klar. Hier ist nslookup immer dein bester Freund das wasserdicht zu testen !
Pingen kann ich Interessanterweise nur bis MTU 996
Da kann etwas nicht stimmen !! Das ist deutlich zu wenig. Da stimmt etwas im Setup nicht.Wichtig ist das die MTU und MSS Settings auf Server und Client identisch sind !
Denn wenn ich eine IP anpinge geht es aber wenn ich zb. google.de anpingen will kommt ein Fehler...
Was dann deutlich auf ein Routing Problem hinweist....Leider fehlt deine Server Konfig die hier essentiell wäre zu kennen. Die entscheidet nämlich ob du Split Tunneling machst oder Gateway Redirect !! Auch warum du ein route Kommando im Client hast ist eigentlich unverständlich, denn das wäre einzig nur erforderlich wenn du eine Site-to-Site Kopplung machen willst was bei dir ja nicht der Fall ist.
Es gibt also diverse Ungereimtheiten in deinem Setup. Vielleicht liest du dir das hiesige OpenVPN Tutorial nochmal in aller Ruhe durch.
Merkzettel: VPN Installation mit OpenVPN
1
Sooo, nach mehrfachem Lesen des Tutorials und weiteren Recherchen habe ich es endlich zum Laufen gebracht, was mir gefehlt hat war der Eintrag, .
Ich habe mich vllt. undeutlich ausgedrückt, was ich überhaupt wollte.
Ich brauche kein Zugriff auf mein Heimnetz sondern ich will einfach nur meinen Datenverkehr wenn ich unterwegs bin verschlüsselt über meinen Heimrouter ins Netz schicken. Eigentlich würde es mir sogar recht sein, wenn ich keinen Zugriff auf mein Heimnetz hätte. Da das eben auch mal von der Arbeit aus passiert brauche ich eben den Port 443.
Meine Client Conf. ist jetzt
und da ich nicht weiß wie ich meine Server Conf exportieren kann hier ein Bild davon:
redirect-gateway def1 bypass-dhcpIch habe mich vllt. undeutlich ausgedrückt, was ich überhaupt wollte.
Ich brauche kein Zugriff auf mein Heimnetz sondern ich will einfach nur meinen Datenverkehr wenn ich unterwegs bin verschlüsselt über meinen Heimrouter ins Netz schicken. Eigentlich würde es mir sogar recht sein, wenn ich keinen Zugriff auf mein Heimnetz hätte. Da das eben auch mal von der Arbeit aus passiert brauche ich eben den Port 443.
Meine Client Conf. ist jetzt
dev tun
proto tcp-client
remote vpn.domain.tld 1194 # Remote OpenVPN Servername or IP address
ca ca.crt
cert client.crt
key client.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
auth-user-pass auth.cfg
redirect-gateway def1 bypass-dhcpund da ich nicht weiß wie ich meine Server Conf exportieren kann hier ein Bild davon:
was mir gefehlt hat war der Eintrag, redirect-gateway def1 bypass-dhcp
Genau deshalb die Frage ob du ein Gateway Redirect machst oder Split Tunneling ?? ich will einfach nur meinen Datenverkehr wenn ich unterwegs bin verschlüsselt über meinen Heimrouter ins Netz schicken.
Dann ist ein Gateway Redirect mit redirect-gateway def1 bypass-dhcp natürlich Pflicht, weil du ja dann ALLES in den Tunnel routen musst !wenn ich keinen Zugriff auf mein Heimnetz hätte.
Das ist ja im Mikrotik kinderleicht in der Firewall einzurichten- Chain: Forwarding
- Source: internes OpenVPN Netz
- Destination: Heimnetz
- Action: DROP
- Färdsch
Meine Client Conf. ist jetzt
Zumindestens das redirect-gateway def1 bypass-dhcp ist dort in einer Client Konfig ziemlicher Quatsch und unsinnig. Das Kommando ist ein reines Server Kommando, macht also einzig nur Sinn in der Server Konfig Datei. Vergiss diesen Unsinn also...und da ich nicht weiß wie ich meine Server Conf exportieren kann hier ein Bild davon:
Oha... Mikrotik Handbuch lesen sofern dein Server auf einem Mikrotik rennt. export im CLI heisst das Zauberwort. Handbuch lesen hilft wirklich ! 1
Ja, ich will wohl ein Gateway Redirect :D
Wegen dem Zugriff auf's Heimnetz: Macht es einen Unterschied ob ich eine Range bei "Src. Address" angebe oder eine Address List anlege (direkt den Pool kann ich ja nicht auswählen)? ...und dann einfach "out interface: LAN" richtig?
Vllt. stelle ich mich ja auch zu blöd an aber, wie greife ich denn im Mikrotik auf die OpenVPN-Server Konfig zu? Und wieso muss es unbedingt dort rein? bei mir Funktioniert es ja auch in der Client Konfig... In der GUI habe ich die Auswahl ja nicht.
gibt folgendes aus:
Wegen dem Zugriff auf's Heimnetz: Macht es einen Unterschied ob ich eine Range bei "Src. Address" angebe oder eine Address List anlege (direkt den Pool kann ich ja nicht auswählen)? ...und dann einfach "out interface: LAN" richtig?
Zumindestens das redirect-gateway def1 bypass-dhcp ist dort in einer Client Konfig ziemlicher Quatsch und unsinnig. Das Kommando ist ein reines Server Kommando, macht also einzig nur Sinn in der Server Konfig Datei. Vergiss diesen Unsinn also...
Vllt. stelle ich mich ja auch zu blöd an aber, wie greife ich denn im Mikrotik auf die OpenVPN-Server Konfig zu? Und wieso muss es unbedingt dort rein? bei mir Funktioniert es ja auch in der Client Konfig... In der GUI habe ich die Auswahl ja nicht.
interface ovpn-server server export verbose/interface ovpn-server server
set auth=sha1 certificate="VPN Server" cipher=aes256 default-profile=ovpn \
enabled=yes keepalive-timeout=60 mac-address=XX:XX:XX:XX:XX:XX max-mtu=\
1500 mode=ip netmask=24 port=1194 protocol=udp \
require-client-certificate=yes tls-version=anyWegen dem Zugriff auf's Heimnetz: Macht es einen Unterschied ob ich eine Range
Autsch, der Dativ ist dem Genitiv sein Tod....Nein, es ist völlig egal ob du eine Range oder eine Liste anlegst. Das ist kosmetisch. Am einfachsten ist es doch wenn du dein gesamtes internes OpenVPN IP Netz nimmst, bei dir dann 10.10.100.0/24 ! Sprich...
- Chain: Forwarding
- Source: 10.10.100.0/24
- Destination: 192.168.88.0/24
- Action: DROP
Einfacher gehts doch nicht, oder ?
1
Vor lauter Wald den Baum nicht gesehen :D
Vielen vielen Dank. Es läuft wie am Schnürchen ;)
Vielen vielen Dank. Es läuft wie am Schnürchen ;)
👏 Glückwunsch !
Passiert mal im Eifer des Gefechts !!
Passiert mal im Eifer des Gefechts !!
1
