poddeldunkt
Goto Top

MikroTik L2TP IpSec VPN Verbindungsprobleme

Hallo zusammen,

nachdem ich ja bereits gefragt hatte wie ich mein VPN Beschleunigen kann, habe ich mir nun einen MikroTik Router mit CryptoChip zum testen gekauft und diesen bei mir im Netzwerk installiert, nach einigen Stunden rumprobieren mit Interface / Brigde, RouterOS und VPN bin ich nun leider an einen Punkt gekommen wo ich nicht mehr weiterkomme, daher möchte ich euch um Rat fragen.

Folgendes ist die Situation bei mir im Büro:

Kabel Deutschland Anschluss (100 Down / 50 UP) mit öffentlicher IPv4 Adresse
-->
FritzBox 6490 Cable (192.168.5.1)
-->
Mikrotik hexS (mit aktuellstem RouterOS)
WAN: 192.168.5.5 (ether1)
LAN: 192.168.10.1 (bridge (ether2,3,4,5)


Beim MikroTik habe ich am WAN NAT augeschaltet und im MikroTik sowie in der FritzBox statische Routen eingetragen, des Zugriff vom MikroTik ins FritzBox Netz, sowie ins Internet klappt Problemlos. Desweiteren habe ich an der FritzBox alle VPN-Profile gelöscht, sowie Portweiterleitungen für 500, 1701, 4500 auf den MikroTik angelegt. Eine Portweiterleitung für ESP habe ich ebenfalls angelegt.

Bei der Grundeinrichtung für's VPN habe ich mich an folgende Anleitung gehalten:
https://saputra.org/threads/mikrotik-l2tp-over-ipsec-vpn-server-tutorial ...

Wenn ich mein Laptop (Windows 10) im lokalen LAN am MikroTik habe, und als "Remote-Adresse" 192.168.10.1 eingebe, kann ich die VPN Verbindung problemlos aufbauen. Auch wenn ich mich mit meinem Notebook ins FritzBox Netz hänge und die VPN Verbindung zu 192.168.5.5 (also der WAN-Adresse des MikroTik) aufbaue, klappt der Aufbau innerhalb von 1-2 Sekunden problemlos.

Lediglich direkt über's Internet kann ich die Verbindung nicht aufbauen. Hier dauert die Verbindung ewig, dann erhalte ich von Windows 10 eine Fehlermeldung (siehe Anhang). Die Config für Windows 10 befindet sich ebenfalls im Anhang.

Beim MikroTik, habe ich das LogLevel für IPSec bereits auf Debug gesetzt, ich sehe hier immer wieder
purged IPSec-SA proto_id=ESP

leider komme ich zu keinem Schluss wieso es nicht klappt. Die Logs vom Mikrotik befinden sich ebenfalls im Anhang.

Wenn ich bei auf meine Public IP einen Ike-Scan mache erhalte ich ebenfalls einen handshake, wenn ich den L2TP Server am MikroTik ausschalte, erhalte ich 0 handshakes, ich gehe also davon aus dass die FritzBox keine relevanten Pakete mehr abfangen sollte???

Die FritzBox möchte ich im Netz behalten da diese weiterhin ein Analoges Telefon betreiben soll, desweiteren wüsste ich nicht wie ich meinen MikroTik an den Kabel Deutschland anschluss bekomme, da Kabel ja nach wie vor keine PPP Zugangsdaten herausgibt.

NAT-Traversal habe ich uner IP->IpSec->Policies->Default aktiviert.

Vielleicht hat hier jemand eine Idee wo ich noch ansetzen könnte um mein VPN zum laufen zu bekommen.

(Anmerkung meine öffentliche IP 46.128.73.157) habe ich nach diesem Post durch einen Reconnect geändert, nicht dass ich hier gleich wieder Ärger bekomme.
config
unbenannt
bildschirmfoto von 2019-10-02 17-56-56
bildschirmfoto von 2019-10-02 17-56-40

Content-ID: 500665

Url: https://administrator.de/contentid/500665

Ausgedruckt am: 21.11.2024 um 22:11 Uhr

aqui
aqui 02.10.2019 aktualisiert um 19:43:31 Uhr
Goto Top
sowie Portweiterleitungen für 500, 1701, 4500 auf den MikroTik angelegt.
Das Wichtigste fehlt ! Das ESP Protokoll. (IP Nummer 50, ESP ist ein eigenständges IP Protokoll)
Logisch dann das es ohne ESP nicht funktionieren kann, denn der ESP Tunnel transportiert die eigentlichen Produktivdaten !
L2TP nutzt IPsec zur Verschlüsselung RFC 3193: https://tools.ietf.org/html/rfc3193
Guckst du auch hier:
Scheitern am IPsec VPN mit MikroTik

Darauf wird in gefühlt jedem 2ten Thread hier zu dem Thema Port Forwarding bei VPN hingewiesen...!
https://justit.eu/mikrotik-l2tpipsec-vpn/
https://blog.johannfenech.com/mikrotik-fasttrack-configuration-with-l2tp ...
Fasttrack solltest du im MT zur Performance Steigerung im VPN immer aktivieren.
Poddeldunkt
Poddeldunkt 02.10.2019 um 21:23:56 Uhr
Goto Top
Hallo aqui,

ich habe schon ein paar Threads hier im Forum dazu gelesen face-wink

Aus meinem oberen Beitrag:
Desweiteren habe ich an der FritzBox alle VPN-Profile gelöscht, sowie Portweiterleitungen für 500, 1701, 4500 auf den MikroTik angelegt. Eine Portweiterleitung für ESP habe ich ebenfalls angelegt.

ESP habe ich ebenfalls weitergeleitet
FritzBox ESP -> 192.168.5.5
Poddeldunkt
Poddeldunkt 03.10.2019 um 00:30:40 Uhr
Goto Top
Ich habe das eben nochmal überprüft, auch ESP wird korrekt an den MikroTik weitergeleitet.

Desweiteren habe ich das MyFritz Konto aus meiner FritzBox entfernt und überprüft dass kein Benutzer mehr in der FB vorhanden ist, welcher den haken bei VPN gesetzt hat.
bildschirmfoto von 2019-10-03 00-29-30
aqui
aqui 03.10.2019 aktualisiert um 12:51:12 Uhr
Goto Top
Ich habe das eben nochmal überprüft, auch ESP wird korrekt an den MikroTik weitergeleitet.
Kommt es da auch wirklich an, sprich forwardet die FB das auch korrekt ??
Da das bei den FBs immer wieder kritisch ist (sie sind selber IPssec VPN Server) solltest du das mit dem Wireshark mal sicher überprüfen.
Der Knackpunkt ist die FB. Wenn dort nur ein Rest einer VPN Konfig oder User eingerichtet sind dann blockt sie alles was zu IPsec gehört und leitet es trotz Port Forwarding nicht weiter.
Hier wäre also eine Überprüfung mit dem Wireshark zielführend.
Das ist einfach umzusetzen indem du einfach testweise die .5.5 mal mit einem Wireshark Rechner mit gleicher IP temporär ersetzt und dann von extern den VPN Client startest.
Der Wireshark sollte dann eingehende IPsec Pakete anzeigen.

Noch viel einfacher ist es wenn du zuerst einmal den VPN Client direkt ins Koppelnetz zwischen FB und MT plazierst und diessem VPN Client eine freie IP aus dem Koppelnetz 192.168.5.x vergibst.
Dann vom VPN Client direkt eine VPN Verbindung auf den MT eröffnen. Das muss funktionieren !
So umgehst du erstmal ganz sicher eventuelle Port Forwarding Probleme auf der FB und außerdem kannst du so ganz sicher und ohne Hürden testen das der VPN Client auch fehlerlos mit dem MT zusammenarbeitet, sprich dessen Konfig fehlerfrei ist !!
Erst dann testest du von extern. Dann kannst du ggf. noch vorhandene Fehler einzig und allein auf die FB reduzieren.
Bedenke auch das du den externen VPN Test NICHT aus dem lokalen LAN mache kannst wegen der Hairpin NAT Problematik. Die FB supportet kein Hairpin NAT.
Der externe Test muss auch immer wirklich von extern passieren (Mobilnetz, Kollege usw.)
Poddeldunkt
Poddeldunkt 03.10.2019 um 16:08:15 Uhr
Goto Top
Hallo aqui,

Das Gerät ins Koppelnetz zu hängen, und von dort eine VPN Verbindung zu 192.168.5.5 aufzubauen, hatte ich bereits mit Erfolg getestet. Ich habe es aber eben nochmal getestet, wieder mit Erfolg. Die Verbindung wird sofort aufgebaut!

Die Tests über die öffentliche IP-Adresse mache (oder lasse ich machen) immer von zuhause, da mit die Problematik mit Hairpin bereits bekannt ist.

Ich habe heute die komplette FB zurückgesetzt, und nur IP-Netz, Routen und Portfreigaben angepasst, nun kann wirklich keine VPN oder MyFritz Konfigruation mehr vorhande sein. Leider kann ich immer noch keine Verbindung aufbauen.

Die Diagnose über Wireshark habe ich ebenfalls gemacht. Wenn ich den Stream nach ESP filtere erhalte ich keine Pakete! Gefiltert nach UDP während einem Verbindungsversuch allerdings schon. Interessant ist dass er nach der Authentifizierung ein IMCP Paket an den Client (öffentliche IP) schicken will, welches aber nicht durchkommt. Kann es hiermit etwas zu tun haben? Siehe Bild...
bildschirmfoto von 2019-10-03 16-02-37
aqui
aqui 03.10.2019 um 18:34:01 Uhr
Goto Top
Die Verbindung wird sofort aufgebaut!
Sehr gut ! Dann ist also nur das Port Forwarding der FW dein Problem !
Wenn ich den Stream nach ESP filtere erhalte ich keine Pakete!
Zeigt dann das die FW kein IPsec zum MT forwardet oder nicht richtig forwardet. Das ist ja offensichtlich.
Kann aber auch eine Folge sein das der Wireshark PC natürlich nicht antwortet und so gar kein Tunnelaufbau zustande kommt.
Besser wäre es also mal den aktiven Traffic mit einer Bridge zu belauschen:
https://www.heise.de/ct/artikel/Ethernet-Bridge-als-Sniffer-Quelle-22148 ...

Es ist ja klar das irgendwie kein oder nur Teile von IPsec ankommen am MT. Das liegt entweder an der FB oder am Provider.
Kanst du ausschliessen:
  • Das der Client an einem DS-Lite Anschluss hängt
  • Das der Client Provider oder deiner ggf. VPN Traffic filtert. (Ist manchmal bei Mobilnetzen der Fall)
  • Der Provider im Client Netz private RFC 1918 IPs nutzt mit CGN (Carrier Grade NAT)
Alle 3 Punkte wären der Tod von L2TP
Poddeldunkt
Poddeldunkt 03.10.2019 um 19:03:34 Uhr
Goto Top
Hallo,

interessanterweise habe ich vorhin einen ähnlichen Beitrag über L2TP & DS-Lite gelesen.

Ich kann leider keinen deiner 3 Punkte wirklich ausschließen, ist dann aber L2TP für mich vielleicht nicht das richtige, da ich mich gerne mit meinem NB von verschiedenen Standorten ins Büro eintunneln möchte (Zuhause, Kunden, Mobilnetz).

Wäre es hier vielleicht besser evtl. auf OpenVPN umzusteigen? Mit welchen Geschwindigkeiten kann ich hier mit einem MT hexS rechnen? Der dort verbaute Crypto-Chip ist ja meines Wissens nur für IPSec?
aqui
aqui 04.10.2019 aktualisiert um 10:05:47 Uhr
Goto Top
Ich kann leider keinen deiner 3 Punkte wirklich ausschließen
Warum nicht ?? Als IT oder Netzwerk Admin kennt man doch seine Rahmenbedingungen ganz genau, oder sollte es zumindestens !!
Wenn du wirklich DS-Lite oder CGN Umfelder hast ist immer die Verwendung eines SSL basierten VPN Protokolls (z.B. OpenVPN, WireGuard) erheblich einfacher und dann immer vorzuziehen. Das liegt daran das das Port Forwarding mit nur einem Port (UDP 1194 im Default) erheblch einfacher ist. Man kann zudem auch UDP 443 nutzen um so auch durch Firewall Regeln zu kommen. SSL ist also einfacher und flexibler zu handhaben.
Es macht also erstmal Sinn herauszubekommen ob du überhaupt DS-Lite oder CGN Umfelder hast. Wenn du das nicht weisst und auf Nummer scher gehen willst macht ein Test mit OpenVPN als SSL Alternative sicher mal Sinn.

Wie das genau geht und was dafür zu tun ist steht hier:
Clientverbindung OpenVPN Mikrotik
Der dort verbaute Crypto-Chip ist ja meines Wissens nur für IPSec?
Das ist laienhafter Unsinn, sorry. Krypto Hardware bezieht sich generell auf alle Schlüsselalgorithmen und verfahren.