MikroTik Router als VPN Client
Hallo zusammen,
ich möchte mit einem MikroTik Router (Client) eine VPN Verbindung zu einem VPN-Server aufbauen.
So habe ich es konfiguriert, bekomme aber keine Verbindung aufgebaut.
Im Ereignislog auf dem VPN-Server sehe ich nichts, sprich der Router scheint schon nicht bis dahin zu kommen...
Mit anderen Geräten (PC, Smartphone, Tablet) funktioniert die Verbindung.
VG
ich möchte mit einem MikroTik Router (Client) eine VPN Verbindung zu einem VPN-Server aufbauen.
So habe ich es konfiguriert, bekomme aber keine Verbindung aufgebaut.
Im Ereignislog auf dem VPN-Server sehe ich nichts, sprich der Router scheint schon nicht bis dahin zu kommen...
Mit anderen Geräten (PC, Smartphone, Tablet) funktioniert die Verbindung.
VG
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1721997934
Url: https://administrator.de/forum/mikrotik-router-als-vpn-client-1721997934.html
Ausgedruckt am: 27.12.2024 um 04:12 Uhr
56 Kommentare
Neuester Kommentar
Bist du dir sicher das dein Server wo sich der Client einwählen soll wirklich L2TP macht ? Leider machst du ja oben keinerlei verlässliche Aussage zum VPN Protokoll welches dein Server verwendet.
Gut, nehmen wir mal an das es wirklich L2TP ist. Hast du dann zuallererst einmal mit einem L2TP Client von Windows oder einem Smartphone sicher ausprobiert das der Zugang mit den L2TP User Credentials (User/Passwort) wasserdicht funktioniert ??
Wenn ja liegt es vermutlich an den IPsec Einstellungen !! Dazu machst du ja auch leider keinerlei Aussagen bzw. der Screenshot dazu fehlt.
L2TP nutzt IPsec im Tunnel und hier ist es essentiell welche Verschlüsselung du unter IP --> IPsec eingestellt hast in den Default Settings ? Siehe dazu hier:
Scheitern am IPsec VPN mit MikroTik
Du solltest dort auch noch zusätzlich den Haken bei modp1024 setzen fals der Server ältere IPsec Cipher Suites verwendet !
Zusätzlich wäre, wie immer, ein Log Auszug des Servers und des Mikrotik von der Einwahl des Clients hilfreich ! Dort steht bekanntlich immer ganz genau warum es scheitert.
Allgemeine Grundlagen zu L2TP Settings auch hier:
Scheitern am IPsec VPN mit MikroTik
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Gut, nehmen wir mal an das es wirklich L2TP ist. Hast du dann zuallererst einmal mit einem L2TP Client von Windows oder einem Smartphone sicher ausprobiert das der Zugang mit den L2TP User Credentials (User/Passwort) wasserdicht funktioniert ??
Wenn ja liegt es vermutlich an den IPsec Einstellungen !! Dazu machst du ja auch leider keinerlei Aussagen bzw. der Screenshot dazu fehlt.
L2TP nutzt IPsec im Tunnel und hier ist es essentiell welche Verschlüsselung du unter IP --> IPsec eingestellt hast in den Default Settings ? Siehe dazu hier:
Scheitern am IPsec VPN mit MikroTik
Du solltest dort auch noch zusätzlich den Haken bei modp1024 setzen fals der Server ältere IPsec Cipher Suites verwendet !
Zusätzlich wäre, wie immer, ein Log Auszug des Servers und des Mikrotik von der Einwahl des Clients hilfreich ! Dort steht bekanntlich immer ganz genau warum es scheitert.
Allgemeine Grundlagen zu L2TP Settings auch hier:
Scheitern am IPsec VPN mit MikroTik
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
mit der folgenden Anleitung habe ich es hinbekommen:
👍Allerdings kann ich noch nichts anpingen im Ziel Netz.
Das kann mehrere Ursachen haben...OK, sofern die Screenshots oben die deines L2TP Clients sind, machst du ja NAT (Adress Translation) im Tunnel. Sprich alle deine Absender IPs werden auf die IP Adresse des VPN Adapters geNATet.
Das Zielnetz "sieht" also nur diese IP Adresse als Absender deiner Pakete so das dort Routing in deine Quellnetze nicht relevant ist solange an der Serverseite das VPN IP Netz bekannt ist.
Dein Mikrotik nutzt ja, wie bereits gesagt, eine IP Adresses dieses Netzes das dann am Ziel die Absender IP all deines Traffics ist. Simple NAT/Masquerading Logik...
Zu der o.a. Konfig passt dann aber deine Aussage...
Der Bereich 10.0.0.0/24 ist der, den ich gerne erreichen will im Zielnetz.
irgendwie nicht.Das bedeutet ja aus Sicht deines MT das es dann die Destination IP Adresse (Destination eng.=Ziel) ist !
In der NAT Klassifizierung der FW gibst du das aber als Source, sprich also fälschlicherweise als Absender (Source) IP an, was ja dann nach deiner o.a. eigenen Logik völliger Unsinn wäre. Absender IPs wären ja die deines lokalen IP Netzes.
Was gilt denn nun ?? WER soll WOHIN ? Verwirrung komplett...
Tip:
Ein Blick in die Routing Tabelle des MT bei aktivem L2TP Client kann auch nicht schaden... Dort steht ja dann schwarz auf weiss ob das 10.0.0.0/24 Netz auf das VPN Interface geroutet wird !
Aber wie erreiche aus dem entfernten Netz das Gerät das an dem Router hängt?
Da hast du 2 Optionen...Du machst ja NAT/Masquerading (Adress Translation) am Tunnelport. Dadurch das NAT aktiv ist hast du nur noch einseitiges Routing, denn NAT lässt inbound nur die Sessions zu für die es einen Eintrag in der NAT Session Table hat. Alle anderen Versuche werden geblockt bzw. verworfen.
Es ist das gleiche Prinzip was an jedem Heimrouter aktiv ist der NAT ins Internet macht.
Die 2 Optionen sind dann:
- Wenn du NAT beibehalten willst musst du mit Port Forwarding arbeiten
- Ohne NAT kannst du beidseitig transparent routen musst dann aber aber auch beidseitig statische Routen in die lokalen Netze eintragen. (Alternative dynamisches Routing).
Grundlagen zum IP Routing auch in Verbindung zu NAT erklärt dir, wie immer, dieses Tutorial.
Bin ich auf dem Holzweg ?
Nein, eigentlich nicht...Site-to-Site VPN mit Mikrotik L2TP
Inhaltsverzeichnis
Hier eine Demo Konfiguration mit einem Cisco IOS Router als L2TP Server und dem Mikrotik als L2TP Client. Konfigurationsbasis ist eine Mikrotik Default Konfig:
- eth1 = WAN Interface mit NAT und Firewall
- eth2-5 = Bridge IP Interface lokales LAN mit der IP: 192.168.88.1 /24
- DHCP Pool: .88.100 bis .88.254
- Router OS: 7.1.1 (Stable)
Lokales LAN (VLAN1 Interface) = 192.168.25.0 /24
L2TP Client Netz (Loopback) = 192.168.26.0 /24
1.) Mikrotik als L2TP VPN Server
Die Mikrotik L2TP Server Konfiguration bei einem Site-to-Site Design ist (fast) identisch zum VPN Client Setup.Wichtig ist hier das Feld "Routes" in der L2TP Userdefinition!
Hier eingetragene Routen ergänzt der L2TP Server automatisch wenn der VPN Tunnel für den jeweiligen Client aktiv ist. Das ist sehr bequem weil es das extra Setzen von statischen Routen für die lokalen Client Netze erspart. Die Syntax ist wie folgt:
<client_zielnetz/maske> <gateway_IP> <metrik>
Mehrere IP Netze auf Clientseite werden mit einem Komma separiert!
Hier im Beispiel wir dem L2TP Clientrouter die "192.168.18.30/32" vergeben was gleichzeitig die Gateway IP auf Clientseite ist und wohin das .88.0/24er Netz hingeroutet wird. Das D vor dem entsprechenden Routingtabellen Eintrag zeigt das diese Route dynamisch zugefügt wurde.
2.) Cisco als L2TP VPN Server
Um den Rahmen dieses Tutorials nicht zu sprengen findet man die vollständige L2TP Server Konfiguration für einen Cisco IOS Router im Cisco Tutorial!3.) Mikrotik L2TP Client VPN Konfiguration:
Alles auf Default belassen und nur Peer IP Adressen entsprechend angepasst.Tunnelstatus auf "Established" und L2TP nutzt immer ein IPsec Tunnel im +++Transport Mode@@, deshalb steht Tunnel Mode auf 0. Also Tunnelaufbau alles korrekt und aktiv !
Entsprechendes sieht man dann auch auf der Cisco Seite (L2TP Server) wenn der Tunnel aktiv ist:
cisco-router#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
10.1.1.222 10.99.1.138 QM_IDLE 2057 ACTIVE
10.1.1.222 10.99.1.138 QM_IDLE 2055 ACTIVE
IPv6 Crypto ISAKMP SA
cisco-router#sh crypto ipsec sa address
fvrf/address: (none)/10.99.1.138
protocol: ESP
spi: 0xD1AF901(219871489)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 4, flow_id: Onboard VPN:4, sibling_flags 80000000, crypto map: vpntest
sa timing: remaining key lifetime (k/sec): (4608000/1181)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
4.) Mikrotik Routing anpassen:
L2TP ist ein reines Punkt zu Punkt (Bridging) Protokoll, kann also ohne Hilfe wie dynamische Routing Protokolle (RIP, OSPF usw.) keine Routen von sich aus austauschen.Das L2TP IP Netz basiert auf der IP Adressierung des L2TP Servers! (32Bit Hostmasken)
Hier im Setup der Cisco Router mit der 192.168.26.1 (Loopback Interface IP Netz bzw. Pool).
Der Mikrotik als Client braucht also immer eine statische Route um das lokale LAN des L2TP Servers (hier Cisco) bzw. das remote IP Netz erreichen zu können.
Sind remote mehrere lokale IP Netze vorhanden, müssen diese ebenso hinzugefügt werden.
Sind es mehrere kann man sie ggf. intelligent mit einer Summary Route mit entsprechender Maske angeben. Bei dir z.B. 10.0.0.0 /16, was dann alle 10.0.x.y IP Netze in den Tunnel routet.
4.1) Cisco (L2TP Server) Routing Tabelle
Statische Route ("S" Index) auf Mikrotik LAN via L2TP Gateway IP Mikrotik hinzugefügt:cisco-router#sh ip rou
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is 10.1.1.254 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 10.1.1.254
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.1.1.0/24 is directly connected, Vlan99
L 10.1.1.222/32 is directly connected, Vlan99
192.168.25.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.25.0/24 is directly connected, Vlan1
L 192.168.25.1/32 is directly connected, Vlan1
192.168.26.0/32 is subnetted, 2 subnets
C 192.168.26.1 is directly connected, Loopback1
C 192.168.26.200 is directly connected, Virtual-Access2.1
S 192.168.88.0/24 [1/0] via 192.168.26.204 <==(Stat.Route Mikrotik)
5.) Ping Checks:
Mikrotik auf Cisco LAN
PC am Mikrotik auf Cisco LAN
Cisco LAN auf Mikrotik LAN
cisco-router#ping 192.168.88.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.88.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Works as designed !
6.) Weiterführende Links zum Thema L2TP VPN
Jetzt kommen die Routen
Sieht gut aus und alles richtig ! "C" sind die lokal connecteten Systeme. "S" ist die Dynmaisch erlernte Default Route von der FB. Deine statische Route routet alles was 10.0.x.y hat in den VPN Tunnel.Der Client ist also korrekt.
Der Ping hinter den L2TP Server funktioniert:
Ist das sein lokales LAN Interface ??Der Ping hintern den L2TP Client nicht:
Warum gehst du hier nicht strategisch vor in liest oben mal was man dir geantwortet hat ! L2TP ist erstmal Punkt zu Punkt !! Sprich der Server kennt erstmal das L2TP Tunnelnetz 10.2.0.0 ganz sicher.
Da liegt es doch auf der Hand vom PC zuerst einmal diese Adresse 10.2.0.2 auf dem Client zu pingen BEVOR man das lokale 88er LAN pingt !!
Mache das also als allererstes um mal zu checken ob du überhaupt erstmal zum Client kommst mit den IP Netzen die die Serverseite kennt.
Erst dann siehst du mal in die Routing Tabelle des l2TP Servers ob da überhaupt das 88er Netz bekannt ist ?!
Vermutlich ist es das wegen der dir oben bereits geschilderten P2P Geschichte nicht. Folglich muss man auch dem Server (wie bei den Routen des Clients) das 88er IP Netz mit einer statischen Route ala: "Zielnetz: 192.168.88.0, Maske: /24, Gateway: 10.2.0.2" doch bekannt geben.... Siehe output der Routing Tabelles des Cisco L2TP Servers oben !
DAS sind die Sachen die du falsch machst weil du vermutlich nicht mal in aller Ruhe nachdenkst WIE sich deine IP Pakete im Netz bewegen...
Ich kann weder die 10.2.0.2 noch die 10.2.0.1 pingen.
Mmmhhh...das ist in der Tat recht ungewöhnlich und zeigt das du ggf. noch Firewall Problematiken irgendwo hast.Entweder im Test PC (Bei Windows FW fehlt dann der Haken ICMP von "any" Netzwerk akzeptieren) oder auf dem MT Client bzw. dem Server selber.
Auf alle Fälle MUSS ein Test PC im lokalen LAN des Mikrotik (L2TP Client) die eigene, lokale L2TP Tunnel IP des MT (hier 10.2.0.2) immer pingen können und immer auch die L2TP Tunnel IP des Servers (hier 10.2.0.1) !! Das sind eigene, lokal connectete IP Netze die immer erreichbar sind ohne jegliche Routen. Gut, beim Server mus sman ggf. aufpassen. Wenn dort eine Firewall aktiv ist muss die natürlich auf dem L2TP Tunnelinterface Pakete mit einer .88.0er Absender IP erlauben. Ansonsten werden diese Frames geblockt.
Das das sogar mit den L2TP und FW Default Settings klappt kannst du oben am Test Setup ja auch selber sehen.
In Bezug auf diese Punkte solltest du dir natürlich den L2TP Server genau ansehen. Routingtabelle natürlich auch, das da eine Route ins 88er Netz eingetragen ist !!
Also auf dem NAS ?
Wenn du den L2TP Server auf einem NAS betreibst, dann JA !Nachteil von VPN Servern auf NAS Systemen ist das manchmal auf dem NAS kein IP Forwarding (Routing) aktiviert ist !
Wenn man dann Geräte im lokalen LAN erreichen will muss das aber zwingend der Fall sein, denn das NAS muss ja IP Traffic vom virtuellen VPN Interface auf das LAN routen. Kann es generell gar nicht routen wird das natürlich nix.
QNAP nutzt wie alle NAS Hersteller ja ein Linux als Unterbau. Dort gibt es generell in der Systemkonfig Datei /etc/sysctl.confden Parameter #net.ipv4.ip_forward=1 der immer mit einem "#" davor auskommentiert ist, also Routing deaktiviert. Siehe dazu auch HIER im hiesigen Routing Tutorial !
M.W. regelt QNAP das mit Dateien unter /proc/sys/net/ipv4 (Shell Zugang mit SSH (z.B. PuTTY) erforderlich). Müsstest du aber mal googeln nach wie man v4 Forwarding aktiviert bzw. ob es dort aktiv ist.
Logischerweise muss dann in der FritzBox 2 Routen eingetragen werden, denn die FritzBox ist ja Default Gateway für alle Endgeräte auf der Serverseite und sie muss deshalb wissen WIE sie auf die remoten IP Netze sprich L2TP und lokales Mikrotik LAN kommt. Raten kann sie das ja schwer...
Zumindestens ein Eintrag, nämlich der des lokalen MT LANs, fehlt bei dir völlig !
Vermutlich weil du mal wieder nicht nachgedacht hast WIE deine IP Pakete sich in deinem Netz bewegen !
Auf der NAS Seite muss die FB also deshalb zwingend zwei statische Routen haben um ihr das beizubringen WIE diese IP Netze zu erreichen sind ! Leuchtet ein, oder ?!
- Ziel: 10.2.0.0, Maske: 255.255.255.0, Gateway: 10.0.0.142
- Ziel: 192.168.88.0, Maske: 255.255.255.0, Gateway: 10.0.0.142
Fazit:
Etwas solltest du schon nachdenken WER deine lokalen IP Pakete WIE routet !!
Dein Fehler ist die fehlende Route auf das 88.0er Netz in der FB auf der NAS Seite und (vermutlich) NICHT das NAS !!
Du hast es scheinbar immer noch nicht verstanden...
Aber auch wenn es das NAS sein würde, dann stellst du dir halt einen 20 Euro hAP lite dahin der das kann und gut iss.
Generell ist es immer ein schlechtes Frickeldesign einen VPN Server im internen Netz zu betreiben und dann auch noch auf so einem wichtigen Endgerät wie einem NAS. Damit lässt du völlig ungeschützten Internet Traffic in dein internes Netz und zudem noch direkt auf sowas wichtiges wie ein NAS. Sowas macht kein guter Netzwerk Admin und auch nicht ein Laie in einem Heimnetz.
Die grundsätzliche Frage die sich stellt ist die: warum du nicht einfach die beiden FritzBoxen mit einem VPN verbindest wenn es dir nur um die Kopplung der beiden Netze geht ??
Die FBs haben das doch beide an Bord und du hast das VPN dann in der Peripherie wie es sich gehört.
Aber warum einfach machen wenn es umständlich auch geht...
Du hast es scheinbar immer noch nicht verstanden...
Aber auch wenn es das NAS sein würde, dann stellst du dir halt einen 20 Euro hAP lite dahin der das kann und gut iss.
Generell ist es immer ein schlechtes Frickeldesign einen VPN Server im internen Netz zu betreiben und dann auch noch auf so einem wichtigen Endgerät wie einem NAS. Damit lässt du völlig ungeschützten Internet Traffic in dein internes Netz und zudem noch direkt auf sowas wichtiges wie ein NAS. Sowas macht kein guter Netzwerk Admin und auch nicht ein Laie in einem Heimnetz.
Die grundsätzliche Frage die sich stellt ist die: warum du nicht einfach die beiden FritzBoxen mit einem VPN verbindest wenn es dir nur um die Kopplung der beiden Netze geht ??
Die FBs haben das doch beide an Bord und du hast das VPN dann in der Peripherie wie es sich gehört.
Aber warum einfach machen wenn es umständlich auch geht...
schlussendlich ist die zweite Fritte dann nicht mehr Bestandteil der endgültigen Konstellation.
Ahhh, OK verstanden !Die Lösung mit den 2 Mikrotiks ist dann erheblich zielführender. Dann solltest du aber zumindestens für die LAN zu LAN Kopplung kein L2TP mehr nehmen sondern IKEv2 !!
IPsec-Site2Site-Tunnel zwischen zwei MikroTik-Routern, beide MikroTik-Router hinter NAT
VPN Performance durch Mikrotik erhöhen
usw. usw.
ob ich das Ganze mit dem hAP hinbekomme
Wird zu 100% funktionieren ! Nochmal vielen Dank für Deine Unterstützung
Immer gerne !Also genau genommen hatte ich das NAS als VPN Server im Einsatz
Kein guter Design Ansatz bei VPN. Ein VPN Server direkt im lokalen LAN ist, wie oben bereits gesagt, immer ein sehr schlechtes und laienhaftes Design aus Security Sicht. VPNs gehören aus guten Gründen (siehe oben) immer in die Peripherie !von Windows Geräten eine VPN Verbindung einrichten kann ohne zusätliche Tools
Das kann man mit jedem 20 Euro Mikrotik oder einer kostenfreien Firewall auch: Scheitern am IPsec VPN mit MikroTik
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Wie sieht es da mit IKEv2 aus ?
pfSense, OPNsense (siehe oben) oder auch mit jedem OpenWRT fähigen Router ! Kommerzielle wie Lancom, Bintec, Cisco und Co. können es auchAußerdem benötige ich auch weiterhin nicht nur eine site2site Verbindung, sondern möchte auch mit meinen Endgeräten (Laptop, Smartphone, Tablet etc) weiterhin eine Verbindung nach Hause aufbauen
Dann machst du es mit dem Mikrotik doch genau richtig ! Site to Site (auch zu Fremdroutern) mit IKEv1 oder IKEv2 und Client VPN Einwahl von remote mit L2TP.Macht der MT doch mit links und das alles mit Bordmitteln !
Aus dem Netz 10.0.0.0 ins 192.168.20.0 zu pingen und zurück....
Das Routing ist soweit richtig. Für das Fehlverhalten gibt es 2 mögliche Fehlerquellen:- In der IPsec Phase 2 (Policy) hast du jeweils nur die 88.0er und .20.0er IP Netze eingetragen, was dann bedeutet das nur diese beiden Netze in den VPN Tunnel geroutet werden, nicht aber das 10er und .178er Netz. Da müsstest du dann zusätzliche Phase2 Policies noch anlegen. Wie man auch oben an deinem Screenshot sieht fehlt diese Policy !!! Da ist es dann logisch das es nicht klappt.
- Sind die Workstations Windows Maschinen ? Dann kann es auch daran liegen das deren lokale Firewall den Zugang blockt. Diese lässt bekanntlich nur Frames durch die aus dem eigenen lokalen Netzwerk kommen und muss entsprechend customized werden.
aber die Verbindung vom Win10 Client (21H2) funktioniert nicht...
DAS !!! hast du dazu gelesen und umgesetzt ??? KB5010793 PatchAlle IPsec und L2TP Tutorials weisen explizit in rot darauf hin !
Habs hier gerade nochmal auf einem hAP lite mit 7.1.1 (Stable) getestet. Setup genau die aus dem Mikrotik L2TP Tutorial und...funktioniert fehlerlos !
Windows 10 Client ist 21H2 und KB5010793 Patch installiert.
Da ist dann wohl noch etwas faul in deinem Setup ?!
Windows 10 Client ist 21H2 und KB5010793 Patch installiert.
Da ist dann wohl noch etwas faul in deinem Setup ?!
Welche Hardware ist das ?? Nicht das du nur ein 100 Mbit Model hast... ?!
Ansonsten nur mal auf dem Endgerät 1000 Mbit und Fulldup erzwingen.
Den Haken bei Auto Negotiation zu setzen wenn du eine statische Datenrate erzwingen willst ist ja etwas sinnfrei !
Ansonsten nur mal auf dem Endgerät 1000 Mbit und Fulldup erzwingen.
Den Haken bei Auto Negotiation zu setzen wenn du eine statische Datenrate erzwingen willst ist ja etwas sinnfrei !
2te Frage
Das kann dann nur eine Firewall Konfig sein. Ist da eine Firewall aktiv oder nur die Default Konfig ohne konfigurierte Firewall ?!
Augen auf beim Mikrotik Kauf !!!
Oder hEX S oder hEX PoE wenn es dir um die kleinen Kaliber geht.
Ich guck mal ob ich einen finde mit 1000
RB750Gr3 = https://mikrotik.com/product/RB750Gr3Oder hEX S oder hEX PoE wenn es dir um die kleinen Kaliber geht.
Wie bekomme ich raus woran das liegt ?
Indem du einmal ins Router Log siehst und dort checkst warum die Phase 2 nicht hochkommt. Idealerweise macht man das auch am ZielrouterVermutlich falsche Crypto Credentials mit dem Gegenüber. Das ist zu 98% der Grund.
Nebenbei:
Wieso gibt es 2 Policy Einträge ? Du arbeitest doch mit L2TP und nicht mit native IPsec im ESP Tunnelmode, oder ??
Das Log ist nur das hier
Richtig !Dann müsste es aber "nie" funktionieren und nicht nur hin und wieder nicht, oder ?
Das ist richtig. Hin und wieder zeigt dann eher das es ein Leitungsproblem gibt.Also L2TP war ja nur für die Site2End Verbindung und die Site2Site habe ich ja nach Deiner Anleitung eingerichtet:
Aaahhsooo.... Sprich also der Site to Site soll die 2 Netze routen. Ist das Gegenüber auch ein Mikrotik ? Wenn nicht, musst du in deinen Policy Setup einen Haken in den Policies setzen das due 2 P2s parallel nutzt, sonst bauen sich die Tunnel immer nur nach Zufall wechselseitig auf wer grad erster ist.und die 8.8.8.8 als dritten eingetragen
Igitt, ein NoGo !! Du solltest eine datenschutzfreundlichere Alternative verwenden wenn du meinst unbedingt US Server als DNS verwenden zu müssen:https://www.heise.de/newsticker/meldung/Quad9-Datenschutzfreundliche-Alt ...
Dein 10.0.0.254 (DC auf der 88er Seite) hat aber wohl hoffentliche eine DNS Weiterleitung konfiguriert auf den lokalen Internet Router ?!! Damit hast du ja dann auch einen laufenden DNS auf der Seite !
und die Dst Address für Policy2 nicht
Sorry, aber das ist völlig unverständlich ?! Die Tunnel Destination IP wird doch mit dem Peer festgelegt !Folglich ist also die Destination IP für beide Phase 2 Policies doch immer gleich. Ist ja nur eine einzige IP für den Peer.
Kann es sein das du hier einen Denkfehler machst ?!
Oder sind das 2 unterschiedliche Lokationen ?? Dann wäre aber deine Peer Konfig ziemlicher Blödsinn, denn dort hast du namentlich den gleichen Peer benutzt was konfigtechnisch gar nicht geht.
Irgendwas ist also recht wirr und unverständlich bei dir.
beide Policies nutzen den selben Peer.
Was ja auch normal ist !Die Frage ist nur warum du von 2 Peer IP Adressen redest und das eine im DynDNS bekannt ist und eine nicht wo es doch nur eine einzige gibt...verwirrend.
OK, also ein Site Peer aber 2 Phase 2 Policies wie es sein sollte...
Haben beide Seiten eine dynamische WAN IP ? Das kann dann oftmals tricky sein mit dem Update Gap.
Wenn einer eine statische IP hat sollte der keinen "Initial Contact" senden als passic sein und nur auf eingehende Conns der Router mit den DynDNS Adressen warten. Nur diese sollten den dann senden.
Das Problem sind deine statischen Routen auf die jeweiligen remoten Netze ! Die sind in der Beziehung Blödsinn bei IPsec Site-to-Site weil die dynamisch mit den Phase 2 Settings angelegt werden.
Die waren ausschliesslich nur gedacht für den Fall das du L2TP machst, weil L2TP das anders handhabt.
Wenn du jetzt auf Site-to-Site umgestellt hast sind die remoten Routen überflüssiger (und auch kontraproduktiver) Unsinn. Es bleiben also einzig nur die Routen auf das lokal kaskadierte IP Netz und nichts anderes.
Das löst dein Problem sofort. Ein entsprechendes Setup funktioniert hier im Test fehlerlos mit deinen IP Netzen und 2 Policies.
Die waren ausschliesslich nur gedacht für den Fall das du L2TP machst, weil L2TP das anders handhabt.
Wenn du jetzt auf Site-to-Site umgestellt hast sind die remoten Routen überflüssiger (und auch kontraproduktiver) Unsinn. Es bleiben also einzig nur die Routen auf das lokal kaskadierte IP Netz und nichts anderes.
Das löst dein Problem sofort. Ein entsprechendes Setup funktioniert hier im Test fehlerlos mit deinen IP Netzen und 2 Policies.
konnte ich das 192.168.20.0 Netz nicht erreichen, dafür benötige ich doch die statischen Routen ?!
Das ist richtig. Verwendet man L2TP, was ja im IPsec Transport Mode arbeitet, benötigt man immer statische Routen.Benutzt man IPsec im ESP Tunnelmode (wie du vermutlich jetzt ?!) benötigt man keine statischen Routen, (und sollte diese löschen wenn vorhanden) da der Tunnelmode das über die P2 SAs automatisch regelt !
Einfache Logik !
dass ich aktuell kein weiteren Abbruch mehr hatte... (Klopf aufs Holz)
👍 So sollte es sein (und natürlich auch bleiben !) 😉