MikroTik IPsec Site-to-Site-VPN Anleitung

Zusammenfassung Ein MikroTik IPsec Site-to-Site-VPN verschlüsselt den Verkehr zwischen zwei kompletten Netzwerken — Zentrale und Filiale, NOC und Funkstandort — sodass Hosts in beiden LANs die Gegenseite erreichen, als wäre sie lokal. Diese Anleitung konfiguriert beide Router unter RouterOS v7: den IKEv2-Peer, die Identität mit Pre-Shared Key, das Phase-2-Proposal, die Tunnel-Policy, die NAT-Bypass-Regel, an der die meisten ersten Versuche scheitern, sowie die Firewall-Regeln und Prüfungen, die den aktiven Tunnel bestätigen.

Was ist ein MikroTik IPsec Site-to-Site-VPN?

Ein MikroTik IPsec Site-to-Site-VPN ist ein dauerhafter verschlüsselter Tunnel zwischen zwei Routern, der zwei getrennte LANs auf Layer 3 zu einem routbaren Netzwerk verbindet, ohne dass einer der Router einen Management-Port ins öffentliche Internet stellt. Anders als Client-VPNs wie WireGuard oder OpenVPN — bei denen sich ein einzelnes Admin-Gerät einwählt — ist ein Site-to-Site-Tunnel immer aktiv und arbeitet Subnetz zu Subnetz: Jeder Host hinter Router A erreicht automatisch jeden freigegebenen Host hinter Router B. IPsec ist hier das richtige Werkzeug, weil es ein offener Standard ist, den praktisch jeder Firewall- und Router-Hersteller unterstützt, weil es für guten Durchsatz im RouterOS-Kernel läuft und weil es auf MikroTik ohne zusätzliches Paket bereits integriert ist.

Der Tunnel entsteht in zwei Verhandlungen. Phase 1 (IKE) authentifiziert die beiden Router gegenseitig und baut einen sicheren Kanal auf; Phase 2 (IPsec) handelt die Schlüssel aus, die Ihren Datenverkehr tatsächlich verschlüsseln. Stimmen beide Phasen auf jeder Seite überein, kommt der Tunnel hoch; weicht auch nur ein einziger Algorithmus ab, scheitert er stillschweigend — deshalb halten die folgenden Schritte beide Seiten symmetrisch.

Bevor Sie beginnen

Sie brauchen zwei MikroTik Router mit RouterOS v7, jeweils mit einer öffentlichen IP-Adresse oder einem funktionierenden DDNS-Hostnamen, und zwei überschneidungsfreie LAN-Subnetze. Diese Anleitung verwendet 192.168.10.0/24 an Site A und 192.168.20.0/24 an Site B. Wenn beide Standorte 192.168.88.0/24 nutzen, ist Routing unmöglich — adressieren Sie zuerst eine Seite um. Da IPsec sehr empfindlich auf Zeitabweichungen reagiert, aktivieren Sie vorab NTP auf beiden Routern; driften die beiden Enden auseinander, laufen die Security Associations ab und der Tunnel bricht immer wieder ab.

Diese Voraussetzung über mehr als eine Handvoll Standorte hinweg im Blick zu behalten, ist schon lästig. Wenn Sie eine Flotte betreiben, gibt Ihnen MKController eine einzige Konsole, um vor der Umschaltung eines Tunnels bei jedem Router die RouterOS-Version und die Zeitquelle zu prüfen — Sie müssen sich also nicht auf jedem Gerät einloggen, nur um dessen Bereitschaft zu bestätigen.

Schritt 1: IKE-Profil und Peer anlegen

Definieren Sie auf Site A das Phase-1-Profil und richten Sie einen Peer auf die öffentliche Adresse von Site B aus:

/ip ipsec profile add name=to-siteB hash-algorithm=sha256 \
    enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d

/ip ipsec peer add name=siteB address=<SITE_B_PUBLIC_IP>/32 \
    profile=to-siteB exchange-mode=ike2

dh-group=modp2048 ist Diffie-Hellman Gruppe 14 — ein solider moderner Standardwert. exchange-mode=ike2 wählt IKEv2, das schneller und robuster ist als der alte main-/IKEv1-Modus. Beide Enden müssen dieselben Profilwerte und denselben Exchange-Mode verwenden.

Schritt 2: Identität (Pre-Shared Key) hinzufügen

/ip ipsec identity add peer=siteB auth-method=pre-shared-key \
    secret="<long-random-shared-secret>"

Verwenden Sie ein langes, zufälliges Secret und verwahren Sie es wie einen SSH-Schlüssel — nicht in einer Chat-Nachricht. Dasselbe Secret kommt auf beide Router.

Schritt 3: Phase-2-Proposal definieren

/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \
    enc-algorithms=aes-256-cbc pfs-group=modp2048

Perfect Forward Secrecy (pfs-group) bedeutet, dass jedes Rekeying frisches Schlüsselmaterial verwendet, sodass ein kompromittierter Schlüssel niemals vergangenen Verkehr offenlegt. Wie in Phase 1 müssen die Algorithmen auf beiden Enden übereinstimmen.

Schritt 4: Tunnel-Policy erstellen

Die Policy sagt RouterOS, welchen Verkehr es verschlüsseln soll — das lokale LAN zum entfernten LAN:

/ip ipsec policy add peer=siteB tunnel=yes \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    proposal=to-siteB action=encrypt

tunnel=yes macht daraus Site-to-Site statt Host-to-Host: Die Originalpakete werden vollständig eingepackt, sodass die beiden LANs transparent miteinander sprechen können.

Schritt 5: NAT-Bypass-Regel hinzufügen (der Schritt, den alle vergessen)

Hier scheitern die meisten ersten Versuche. Ihr Router hat bereits eine Masquerade-Regel, die die Quelladresse ausgehenden LAN-Verkehrs umschreibt. Greift sie vor IPsec, erhält die Gegenstelle Pakete, deren Quelle nicht mehr zur Policy passt, und verwirft sie. Fügen Sie eine Accept-Regel oberhalb des Masquerade ein, damit für den Tunnel bestimmter Verkehr NAT überspringt:

/ip firewall nat add chain=srcnat action=accept place-before=0 \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24

place-before=0 setzt die Regel ganz an den Anfang der srcnat-Chain, was zwingend erforderlich ist — eine Bypass-Regel hinter dem Masquerade bewirkt nichts.

Schritt 6: Firewall öffnen und prüfen

Erlauben Sie die IKE- und NAT-T-Ports sowie das ESP-Protokoll in der Input-Chain, damit der Tunnel zustande kommt — besonders, wenn einer der Standorte hinter einem weiteren NAT-Gerät sitzt:

/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept
/ip firewall filter add chain=input protocol=ipsec-esp action=accept

Bestätigen Sie dann, dass der Tunnel steht:

/ip ipsec active-peers print
/ip ipsec policy print

Ein gesunder Tunnel zeigt einen aktiven Peer und eine Policy, deren ph2-state auf established steht. Ein kurzer Ping von einem Host im einen LAN zu einem Host im anderen belegt die Erreichbarkeit Ende zu Ende.

Die Konfiguration auf Site B spiegeln

Wiederholen Sie jeden Schritt auf Site B mit vertauschten Adressen: Der Peer zeigt auf die öffentliche IP von Site A, und Policy sowie NAT-Bypass verwenden src-address=192.168.20.0/24 und dst-address=192.168.10.0/24. Profil, Proposal, Identity-Secret und IKEv2-Modus bleiben identisch. Wenn beide Seiten übereinstimmen, schließen Phase 1 und Phase 2 ab und der Tunnel kommt hoch.

Tipps zu Sicherheit und Betrieb

Halten Sie RouterOS gepatcht — jüngere Releases enthielten Korrekturen rund um das Peer-Zertifikats-Matching bei IPsec/IKEv2, ein Tunnel, der letztes Quartal lief, verdient also nach jedem Upgrade einen erneuten Test. Bevorzugen Sie IKEv2 mit PFS gegenüber den alten IKEv1-Standardwerten. Wechseln Sie, wo möglich, vom gemeinsamen Secret zur Zertifikatsauthentifizierung, sobald die Zahl der Tunnel wächst, denn ein durchgesickerter Pre-Shared Key betrifft jeden Standort, der ihn teilt. Und protokollieren Sie den Tunnelzustand irgendwo, wo Sie auch hinschauen: Eine tote Site-to-Site-Verbindung bleibt unsichtbar, bis jemand das entfernte LAN erreichen will und scheitert.

In einer Flotte ist ein IPsec-Tunnel, der nach einer Uhrzeit-Abweichung oder einem WAN-Aussetzer klammheimlich abbricht, genau die Art von Störung, die ein Kunde vor Ihnen bemerkt. MKController schließt diese Lücke: Es überwacht jeden Router über einen sicheren ausgehenden Tunnel, der weder eine öffentliche IP noch eine Portweiterleitung auf dem Gerät benötigt, hält versionierte Konfigurations-Backups vor, damit Sie einen funktionierenden IPsec-Block nach einer misslungenen Änderung vergleichen und wiederherstellen können, und kann bei einem Link-Down-Ereignis ein Ticket eröffnen, bevor das Telefon klingelt. Für die Tunnelkonfiguration selbst erklärt unser Leitfaden zu NAT auf MikroTik die Masquerade-Regel, die Sie hier umgehen; und wenn Sie einen einzelnen Router erreichen wollen, statt zwei LANs zu verbinden, siehe Fernwartung hinter CGNAT und unsere Anleitung zur Fernwartung mit WireGuard.

Bringen Sie Ihre Tunnel unter ein Dach

IPsec verbindet zwei Standorte sauber, aber ein wachsender ISP oder MSP hat bald Dutzende Tunnel, Schlüssel und Firewall-Regeln synchron zu halten — und jede manuelle Änderung ist eine Gelegenheit, sich aus einem entfernten Standort auszusperren. MKController ist genau für diese Größenordnung gebaut: zentrale Flottenverwaltung, sicherer Fernzugriff ohne offene Ports, Konfigurationshistorie und Backups sowie flottenweite Rollouts von Firewall- und Policy-Änderungen, sodass ein Tunnel-Template einmal ausgerollt wird, statt Router für Router neu getippt zu werden. Betreiber, die MikroTik im großen Maßstab einsetzen, machen damit aus einem verlorenen Nachmittag voller SSH-Sitzungen pro Gerät ein paar Klicks pro Änderung.

Starten Sie Ihre kostenlose MKController-Testphase