Remote Access
MikroTik IPsec site-to-site VPN-gids
Bouw een MikroTik IPsec site-to-site VPN: configureer de IKEv2-peer, de proposal, de policy en de NAT-bypassregel die de tunnel laat werken.
Samenvatting Een MikroTik IPsec site-to-site VPN versleutelt verkeer tussen twee volledige netwerken — een hoofdkantoor en een filiaal, een NOC en een mastlocatie — zodat hosts op elk LAN het andere bereiken alsof het lokaal is. Deze gids configureert beide routers op RouterOS v7: de IKEv2-peer, de identity met pre-shared key, de proposal voor fase 2, de tunnelpolicy, de NAT-bypassregel waarop de meeste eerste pogingen stuklopen, en de firewallregels en controles die bevestigen dat de tunnel actief is.

Wat is een MikroTik IPsec site-to-site VPN?
Een MikroTik IPsec site-to-site VPN is een permanente versleutelde tunnel tussen twee routers die twee gescheiden LAN’s samenvoegt tot één routeerbaar netwerk op Layer 3, zonder dat een van beide routers een beheerpoort blootstelt aan het publieke internet. Anders dan client-VPN’s zoals WireGuard of OpenVPN — waarbij één beheerapparaat inbelt — is een site-to-site tunnel altijd actief en verbindt hij subnet met subnet: elke host achter Router A bereikt automatisch elke toegestane host achter Router B. IPsec is hier het juiste middel omdat het een open standaard is die vrijwel elke firewall- en routerfabrikant ondersteunt, het in de RouterOS-kernel draait voor goede doorvoer, en het op MikroTik ingebouwd zit zonder extra pakket om te installeren.
De tunnel wordt in twee onderhandelingen opgebouwd. Fase 1 (IKE) authenticeert de twee routers naar elkaar en zet een beveiligd kanaal op; fase 2 (IPsec) onderhandelt de sleutels die je dataverkeer daadwerkelijk versleutelen. Laat beide fasen aan weerszijden overeenkomen en de tunnel komt op; wijkt één algoritme af, dan mislukt hij stilzwijgend — daarom houden de stappen hieronder beide kanten symmetrisch.
Voordat je begint
Je hebt twee MikroTik-routers met RouterOS v7 nodig, elk met een publiek IP-adres of een werkende DDNS-hostnaam, en twee niet-overlappende LAN-subnetten. Deze gids gebruikt 192.168.10.0/24 op locatie A en 192.168.20.0/24 op locatie B. Gebruiken beide locaties 192.168.88.0/24, dan is routering onmogelijk — hernummer eerst één kant. Omdat IPsec erg gevoelig is voor klokafwijking, schakel je NTP op beide routers in voordat je begint; lopen de twee uiteinden uit elkaar, dan verlopen de security associations en blijft de tunnel wegvallen.
Die randvoorwaarde bewaken over meer dan een handvol locaties is al een karwei. Bij een vloot geeft MKController je één console om van elke router de RouterOS-versie en klokbron te controleren voordat je een tunnel omzet, zodat je niet op elk apparaat hoeft in te loggen alleen om te bevestigen dat het klaar is.
Stap 1: Maak het IKE-profiel en de peer
Definieer op locatie A het profiel voor fase 1 en richt een peer op het publieke adres van locatie B:
/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=ike2dh-group=modp2048 is Diffie-Hellman Group 14 — een degelijke moderne standaardwaarde. exchange-mode=ike2 kiest IKEv2, dat sneller en robuuster is dan de oude main/IKEv1-modus. Beide uiteinden moeten dezelfde profielwaarden en dezelfde exchange-mode gebruiken.
Stap 2: Voeg de identity toe (pre-shared key)
/ip ipsec identity add peer=siteB auth-method=pre-shared-key \ secret="<long-random-shared-secret>"Gebruik een lang, willekeurig geheim en bewaar het zoals je een SSH-sleutel zou bewaren — niet in een chatbericht. Hetzelfde geheim gaat op beide routers.
Stap 3: Definieer de proposal voor fase 2
/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \ enc-algorithms=aes-256-cbc pfs-group=modp2048Perfect Forward Secrecy (pfs-group) betekent dat elke rekey vers sleutelmateriaal gebruikt, zodat een gecompromitteerde sleutel nooit eerder verkeer blootlegt. Net als bij fase 1 moeten de algoritmen aan beide kanten overeenkomen.
Stap 4: Maak de tunnelpolicy
De policy vertelt RouterOS welk verkeer versleuteld moet worden — van het lokale LAN naar het externe 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=encrypttunnel=yes maakt dit site-to-site in plaats van host-to-host: de oorspronkelijke pakketten worden in hun geheel ingepakt, zodat de twee LAN’s transparant met elkaar praten.
Stap 5: Voeg de NAT-bypassregel toe (de stap die iedereen vergeet)
Hier lopen de meeste eerste pogingen stuk. Je router heeft al een masquerade-regel die het bronadres van uitgaand LAN-verkeer herschrijft. Vuurt die vóór IPsec, dan ontvangt het externe uiteinde pakketten waarvan de bron niet meer bij de policy past en gooit ze weg. Voeg een accept-regel boven de masquerade toe zodat verkeer richting de tunnel NAT overslaat:
/ip firewall nat add chain=srcnat action=accept place-before=0 \ src-address=192.168.10.0/24 dst-address=192.168.20.0/24place-before=0 zet de regel helemaal bovenaan de srcnat-chain, en dat is verplicht — een bypassregel na de masquerade doet niets.
Stap 6: Open de firewall en controleer
Sta de IKE- en NAT-T-poorten plus het ESP-protocol toe in de input-chain zodat de tunnel tot stand kan komen, zeker als een van beide locaties achter een ander NAT-apparaat zit:
/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept/ip firewall filter add chain=input protocol=ipsec-esp action=acceptBevestig daarna dat de tunnel actief is:
/ip ipsec active-peers print/ip ipsec policy printEen gezonde tunnel toont een actieve peer en een policy waarvan de ph2-state op established staat. Een snelle ping van een host op het ene LAN naar een host op het andere bewijst end-to-end bereikbaarheid.
Spiegel de configuratie op locatie B
Herhaal elke stap op locatie B met omgedraaide adressen: de peer wijst naar het publieke IP van locatie A, en de policy en NAT-bypass gebruiken src-address=192.168.20.0/24 en dst-address=192.168.10.0/24. Het profiel, de proposal, het identity-geheim en de IKEv2-modus blijven identiek. Komen beide kanten overeen, dan voltooien fase 1 en fase 2 en komt de tunnel op.
Tips voor beveiliging en beheer
Houd RouterOS gepatcht — recente releases bevatten fixes rond het matchen van peer-certificaten bij IPsec/IKEv2, dus een tunnel die vorig kwartaal werkte verdient na elke upgrade een hertest. Geef de voorkeur aan IKEv2 met PFS boven de oude IKEv1-standaarden. Stap waar het kan over van een gedeeld geheim naar certificaatauthenticatie naarmate het aantal tunnels groeit, want één gelekte pre-shared key raakt elke locatie die hem deelt. En log de tunnelstatus ergens waar je ook echt kijkt: een dode site-to-site verbinding is onzichtbaar totdat iemand het verre LAN probeert te bereiken en dat niet lukt.
In een vloot is een IPsec-tunnel die stilletjes wegvalt na een klokafwijking of een WAN-storing precies het soort storing dat een klant eerder opmerkt dan jij. MKController dicht dat gat: het bewaakt elke router via een beveiligde uitgaande tunnel die geen publiek IP en geen port forwarding op het apparaat nodig heeft, houdt versiebeheerde configuratieback-ups bij zodat je een werkend IPsec-blok kunt vergelijken en terugzetten na een slechte wijziging, en kan een ticket openen bij een link-down-event voordat de telefoon gaat. Voor de tunnelconfiguratie zelf legt onze gids over NAT op MikroTik de masquerade-regel uit die je hier omzeilt, en om één router te bereiken in plaats van twee LAN’s samen te voegen, zie beheer op afstand achter CGNAT en onze uitleg over beheer op afstand met WireGuard.
Breng je tunnels onder één dak
IPsec verbindt twee locaties netjes, maar een groeiende ISP of MSP heeft al snel tientallen tunnels, sleutels en firewallregels om synchroon te houden — en elke handmatige wijziging is een kans om jezelf buiten te sluiten op een externe locatie. MKController is precies voor die schaal gebouwd: centraal vlootbeheer, veilige toegang op afstand zonder blootgestelde poorten, configuratiehistorie en back-ups, en vlootbrede pushes van firewall- en policywijzigingen, zodat een tunneltemplate één keer wordt uitgerold in plaats van router voor router te worden overgetypt. Operators die MikroTik op schaal draaien gebruiken het om een verloren middag met SSH per apparaat om te zetten in een paar klikken per wijziging.