17.08.2022, aktualisiert um 22:17:12 Uhr

1748

Routeros7 (Mikrotik) als VPN-Client

Guten Abend,

ich möchte gerne auf die neue Version von RouterOS umsteigen, von 6 auf 7, das Gerät RB3011UiAS-RM.
Ich habe daher dementsprechend ein Upgrade durchgeführt.

Soweit alles geklappt, nur geht VPN nicht mehr. Anscheinend hat sich da was verändert, komme jedenfalls nicht weiter.

Hier die Konfiguration, die mit Routeros 6 funktioniert hat und mit 7 unverändert nicht mehr.

VPN-Client (Mikrotik):

/interface ovpn-client
add certificate=office1-client.crt_0 cipher=aes256 connect-to=XXX disabled=yes mac-address=XXX name=ovpn-office1-client-oob use-peer-dns=\
    no user=office1-client verify-server-certificate=yes

VPN-Server (Debian 11):

local XXX
dev tun
port 1194
proto tcp
tls-server
server 172.17.0.0 255.255.0.0
topology subnet
push "topology subnet"  
daemon
client-to-client
client-config-dir ccd-tcp
auth SHA1
cipher AES-256-CBC
ca crt/ca.crt
cert crt/server.crt
key crt/server.key
dh crt/dh.pem
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA
tun-mtu 1500
script-security 3
auth-user-pass-verify /etc/openvpn/server/scripts/password via-env
keepalive 10 120
reneg-sec 300
persist-key
persist-tun
user openvpn
group openvpn
verb 3
status /var/log/openvpn/status-tcp.log
route 10.0.0.0 255.0.0.0
push "route 10.0.0.0 255.0.0.0"  

Hier die Logs.

VPN-Server

2022-08-17T21:29:47+02:00 vpn-102 daemon:notice [125449]: TCP connection established with [AF_INET]XX.XX.XX.XX:41884
2022-08-17T21:29:47+02:00 vpn-102 daemon:notice [125449]: XX.XX.XX.XX:41884 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:41884, sid=3b19084e 18f60f6f
2022-08-17T21:29:48+02:00 vpn-102 daemon:err [125449]: XX.XX.XX.XX:41884 OpenSSL: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate
2022-08-17T21:29:48+02:00 vpn-102 daemon:err [125449]: XX.XX.XX.XX:41884 TLS_ERROR: BIO read tls_read_plaintext error
2022-08-17T21:29:48+02:00 vpn-102 daemon:err [125449]: XX.XX.XX.XX:41884 TLS Error: TLS object -> incoming plaintext read error
2022-08-17T21:29:48+02:00 vpn-102 daemon:err [125449]: XX.XX.XX.XX:41884 TLS Error: TLS handshake failed
2022-08-17T21:29:48+02:00 vpn-102 daemon:err [125449]: XX.XX.XX.XX:41884 Fatal TLS error (check_tls_errors_co), restarting
2022-08-17T21:29:48+02:00 vpn-102 daemon:notice [125449]: XX.XX.XX.XX:41884 SIGUSR1[soft,tls-error] received, client-instance restarting

VPN-Client

Die Meldung im Log ssl3_read_bytes:sslv3 alert bad certificate kann ich nicht verstehen. Wie gesagt, die Konfiguration wurde nicht geändert und die Zertifikate sind die alten geblieben.

Irgend eine Idee?

LG
Andre

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 3682548187

Url: https://administrator.de/forum/routeros7-mikrotik-als-vpn-client-3682548187.html

Ausgedruckt am: 03.01.2025 um 03:01 Uhr

7 Kommentare

Neuester Kommentar

Moin,

Ist das Zertifikat evtl. Abgelaufen?

Gruß,
Avoton

Hallo,

ev. hat sich durch das update ein Parameter im System geändert, sodass das Zertifikat nicht mehr als valide angesehen wird.

Gruß

Eine Tunnel MTU die gleich der Ethernet MTU ist ist auch ein konfigtechnischer Fehler. Ganz besonders bei TCP Encapsulation.
Ebenso die Kernelroute des lokalen Netzwerkes. Die Server Konfig ist recht unsauber und fehlerbehaftet.
Merkzettel: VPN Installation mit OpenVPN
In RouterOS 7 supportet MT endlich UDP Encapsulation so das es zudem sehr sinnvoll in Bezug auf Performance ist dies in der Serverkofig umzustellen!
OpenVPN in Router OS 7 mit der latest Stable Edition rennt mit einer klassischen Konfig fehlerfrei.

OpenVPN in Router OS 7 mit der latest Stable Edition rennt mit einer klassischen Konfig fehlerfrei.

Kann ich auch nur bestätigen:

2022-08-18 12:16:09 us=778446 [USER]/[QUELLE]:45420 SIGUSR1[soft,ping-restart] received, client-instance restarting
2022-08-18 12:16:34 us=34564 MULTI: multi_create_instance called
2022-08-18 12:16:34 us=34744 [QUELLE]:49929 Re-using SSL/TLS context
2022-08-18 12:16:34 us=34977 [QUELLE]:49929 Control Channel MTU parms [ L:1621 D:1212 EF:38 EB:0 ET:0 EL:3 ]
2022-08-18 12:16:34 us=35075 [QUELLE]:49929 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ]
2022-08-18 12:16:34 us=35165 [QUELLE]:49929 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1569,tun-mtu 1500,proto UDPv4,cipher AES-256-CBC,auth SHA256,keysize 256,key-method 2,tls-server'  
2022-08-18 12:16:34 us=35239 [QUELLE]:49929 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1569,tun-mtu 1500,proto UDPv4,cipher AES-256-CBC,auth SHA256,keysize 256,key-method 2,tls-client'  
2022-08-18 12:16:34 us=35311 [QUELLE]:49929 TLS: Initial packet from [AF_INET][QUELLE]:49929, sid=76ee13cb 25383f33
2022-08-18 12:16:34 us=238863 [QUELLE]:49929 VERIFY OK: depth=1, C=DE, CN=XXXXXXX
2022-08-18 12:16:34 us=239122 [QUELLE]:49929 VERIFY OK: depth=0, CN=[USER]
2022-08-18 12:16:34 us=241183 [QUELLE]:49929 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
2022-08-18 12:16:34 us=241239 [QUELLE]:49929 [[USER]] Peer Connection Initiated with [AF_INET][QUELLE]:49929
2022-08-18 12:16:34 us=241274 [USER]/[QUELLE]:49929 MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
2022-08-18 12:16:34 us=241324 [USER]/[QUELLE]:49929 MULTI: Learn: 10.8.0.2 -> [USER]/[QUELLE]:49929
2022-08-18 12:16:34 us=241358 [USER]/[QUELLE]:49929 MULTI: primary virtual IP for [USER]/[QUELLE]:49929: 10.8.0.2
2022-08-18 12:16:34 us=241438 [USER]/[QUELLE]:49929 Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key  
2022-08-18 12:16:34 us=241488 [USER]/[QUELLE]:49929 Outgoing Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication  
2022-08-18 12:16:34 us=241511 [USER]/[QUELLE]:49929 Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key  
2022-08-18 12:16:34 us=241530 [USER]/[QUELLE]:49929 Incoming Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication  
2022-08-18 12:16:34 us=242412 [USER]/[QUELLE]:49929 PUSH: Received control message: 'PUSH_REQUEST'  
2022-08-18 12:16:34 us=242491 [USER]/[QUELLE]:49929 SENT CONTROL [[USER]]: 'PUSH_REPLY,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0' (status=1)  

Der Performance wegen würde ich aber bevorzugt zukünftig auf Wireguard setzen.

...oder IKEv2 oder L2TP, damit nutzt man bequem die onboard Clients in jedem OS und Mobilgeräten und erspart sich dann die überflüssige Frickelei mit externen VPN Clients.
Vom so oder so fragwürdigen Betrieb eines VPN Servers im lokalen LAN mal nicht zu reden.
Scheitern am IPsec VPN mit MikroTik

Guten Abend,

ich wollte noch eine Rücmeldung geben.
Danke für eure Antworten.

Ich habe direkt Wireguard ausprobiert (danke für den Tipp). Bin sehr zufrieden.
Es läuft bei mir etwas schneller als Openvpn.

Die Konfiguration ist aber wesentlich einfacher und die Fummelei mit Zertifikaten entfällt komplett!
Erfreulich ist noch dass der Verbindungsaufbau Bruchteil einer Sekunde dauert. Im Gegensatz zu Openvpn (5-10 Sek.).

Ich habe inzwischen Openvpn aus allen meinen Mikrotik's komplett raus geschmissen bzw. durch Wireguard ersetzt.

Bin zufrieden.

Vielen Dank!

Gruß
Andre

Es läuft bei mir etwas schneller als Openvpn.

Kein Wunder!

komplett raus geschmissen bzw. durch Wireguard ersetzt.

Macht aber nur Sinn wenn man auch ein reines Wireguard Umfeld hat. Zudem sollte man nicht vergessen das WG derzeit fast überall noch Beta Status hat.
IPsec ist da oft deutlich flexibler, schafft gleichen Durchsatz und ist voll kompatibel zu herstellerfremder VPN Hardware.

Bin zufrieden.

Bitte dann auch nicht vergessen deinen Thread hier als erledigt zu markieren!

gelöst Frage Internet Server

Mehr von stickybit

Switches von Mikrotik vs. andere Herstellerstickybit - 11 Kommentare

Unpriviligierter LXC xt recentstickybit

Shell: Datei mit Einrückungen zeilenweise einlesenstickybit - 4 Kommentare

Zugriff auf das LAN hinter dem VPN-Server unter Linux (Debian)stickybit - 6 Kommentare

Heiß diskutiert