MikroTik RouterOS 7 IPsec Site-to-Site VPN Setup

An IPsec site-to-site VPN on MikroTik RouterOS 7 connects two office networks so hosts on each LAN reach the other as if they were local - but only if six pieces line up: the IKE profile, the peer, the identity with the pre-shared key, the Phase 2 proposal, the tunnel policy, and a NAT bypass rule that trips up most first attempts. RouterOS 7 makes this easier with cleaner IKEv2 handling than RouterOS 6. This guide configures both ends step by step with the /ip ipsec command set and finishes with the verification commands that prove the tunnel is encrypting traffic.

Before You Start

• Both sites need non-overlapping LAN subnets - if both use 192.168.88.0/24, routing is impossible. Re-address one side first.
• Enable NTP on both routers: IPsec security associations are time-sensitive, and clock drift makes the tunnel drop and re-establish constantly.

Step 1: IKE Profile and Peer (Phase 1)

/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 is Diffie-Hellman group 14 and exchange-mode=ike2 selects IKEv2, faster and more robust than legacy IKEv1 main mode.

Step 2: Identity with the Pre-Shared Key

The same secret must be configured on both routers, each with its own peer name:

/ip ipsec identity add peer=siteB auth-method=pre-shared-key secret="YourVeryStrongPSK" generate-policy=port-strict

Step 3: Phase 2 Proposal

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

Perfect Forward Secrecy (pfs-group) means every rekey uses fresh key material, so a compromised key never exposes past traffic.

Step 4: Tunnel Policy (Traffic Selectors)

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

Site B uses the mirror image: source 192.168.20.0/24, destination 192.168.10.0/24.

Step 5: NAT Bypass (The Rule Everyone Forgets)

If the router masquerades LAN traffic to the internet, add an accept rule ABOVE the masquerade rule so VPN traffic is not NATed - otherwise replies cannot route back through the tunnel:

/ip firewall nat add chain=srcnat src-address=192.168.10.0/24     dst-address=192.168.20.0/24 action=accept comment="Dont NAT to Site B"

Step 6: Firewall Rules for IPsec

/ip firewall filter add chain=input action=accept protocol=udp dst-port=500,4500 in-interface=ether1
/ip firewall filter add chain=input action=accept protocol=ipsec-esp in-interface=ether1
/ip firewall filter add chain=forward action=accept ipsec-policy=in,ipsec
/ip firewall filter add chain=forward action=accept ipsec-policy=out,ipsec

Verifying the Tunnel

/ip ipsec active-peers
/ip ipsec policy print
/ip ipsec installed-sa
/ping 192.168.20.1 src-address=192.168.10.1 count=5

Related articles: FortiGate IPsec site-to-site VPN configuration, WireGuard site-to-site VPN example, and MikroTik bridge VLAN filtering.

What Changed in RouterOS 7

RouterOS 6 split IPsec into /ip ipsec peer plus /ip ipsec policy with a legacy IKEv1 flavour and awkward PSK handling. RouterOS 7 keeps the same object model but reworks IKEv2 handling, moves the proposal into the peer's profile, and adds proper support for multiple policies per peer, mode-config and responder templates. If you are following a RouterOS 6 guide on v7 hardware, the commands will largely apply — but the defaults differ enough around IKE versions and proposals that a copied configuration can quietly negotiate Phase 1 with weaker parameters than you intended.

Check what you are actually running before you start, because the syntax valid on 7.1 is not identical to 7.15:

/system resource print
/system package print

Also confirm both sites have non-overlapping LAN subnets. If both sides use 192.168.88.0/24 — the RouterOS default — routing is impossible no matter how correct the IPsec configuration is. Re-address one side first, then build the tunnel.

Step 0: Foundation — Addressing, NTP and Interfaces

Two things make IPsec fail intermittently rather than outright, which is far harder to debug: clock drift and asymmetric routing. Fix both before touching /ip ipsec.

/system clock print
/system ntp client set enabled=yes servers=pool.ntp.org,time.cloudflare.com
/system ntp client servers print
/ip address print
/interface print

IPsec security associations are time-sensitive; a router whose clock has drifted will drop and re-establish tunnels on a schedule that looks random. Enable NTP on both ends and confirm the offset is small. Also decide which interface carries the WAN address — the examples below assume ether1 — and confirm it is the interface with the public IP, since the peer address and the firewall rules both reference it.

Step 1: IKE Profile and Peer (Phase 1)

/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 is Diffie-Hellman group 14 and exchange-mode=ike2 selects IKEv2, faster and more robust than legacy IKEv1 main mode. Pinning dh-group matters: if one side accepts a range of groups and the other offers only a weak one, the tunnel comes up on the weakest common option, and that is a security finding rather than an outage — so it tends to survive review unnoticed. Set the parameters explicitly on both ends and keep them identical.

On the RouterOS 7 command line you can rely on \ for line continuation, or simply press Enter with an incomplete command and RouterOS will prompt for the rest. Both are shown here for readability; the router sees a single command either way.

Step 2: Identity with the Pre-Shared Key

The same secret must be configured on both routers, each with its own peer name:

/ip ipsec identity add peer=siteB auth-method=pre-shared-key \
    secret="YourVeryStrongPSK" generate-policy=port-strict

The identity object is where RouterOS 7 differs most from 6: permissions around the PSK, the option to use a certificate instead, and generate-policy — which controls whether the router auto-creates a policy when a peer requests one. port-strict generates a policy only for the exact port ranges in the traffic selector, which prevents a remote peer from widening the tunnel to a whole-subnet selector and pulling in traffic you never intended to encrypt.

Leave generate-policy at its default (disabled) for a purely site-to-site configuration where you define the policy yourself, and use it on the responder side when you cannot predict the peer's source subnet. A PSK should be long, random and unique per tunnel — reusing one secret across dozens of branches means a single compromised branch compromises the fleet.

Step 3: Phase 2 Proposal

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

Perfect Forward Secrecy (pfs-group) means every rekey uses fresh key material, so a compromised key never exposes past traffic. Matching pfs-group with the Phase 1 dh-group is not required, but keeping them aligned (both modp2048 here) is the simplest way to keep the two ends consistent. Note that enc-algorithms takes a suffix: aes-256-cbc is explicit, while bare aes-256 can resolve differently across versions — be explicit.

Step 4: Tunnel Policy (Traffic Selectors)

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

Site B uses the mirror image: source 192.168.20.0/24, destination 192.168.10.0/24. tunnel=yes selects tunnel mode, which encapsulates the entire original packet. A policy is a traffic selector — a rule that says which packets must be encrypted — so an imprecise selector is either a security problem (too broad) or a connectivity problem (too narrow). For multiple VLANs, add one policy per source/destination pair rather than a single /8, and keep the numbering consistent between sites so a future change is a mechanical edit rather than an investigation.

Step 5: NAT Bypass (The Rule Everyone Forgets)

If the router masquerades LAN traffic to the internet, add an accept rule ABOVE the masquerade rule so VPN traffic is not NATed — otherwise replies cannot route back through the tunnel:

/ip firewall nat add chain=srcnat src-address=192.168.10.0/24 \
    dst-address=192.168.20.0/24 action=accept comment="Dont NAT to Site B"
/ip firewall nat print

The trap here is placement. Firewall rules in RouterOS are evaluated top to bottom, and a NAT rule added with add lands at the bottom of the chain — below the masquerade rule that will already have rewritten the source address. On the command line use add chain=srcnat ... place-before=0 to lift it to the top, or reorder from the GUI. Then verify with /ip firewall nat print that the bypass rule genuinely precedes the masquerade, rather than assuming the order is what you intended.

This single mistake accounts for a large share of "the tunnel is up but nothing pings" reports: /ip ipsec active-peers shows a healthy Phase 1, /ip ipsec installed-sa lists security associations, and traffic still disappears because the source address was translated to the WAN address before it was matched by the policy. Related firewall patterns are collected in MikroTik RouterOS firewall chains, filters and address lists.

Step 6: Firewall Rules for IPsec

/ip firewall filter add chain=input action=accept protocol=udp dst-port=500,4500 in-interface=ether1
/ip firewall filter add chain=input action=accept protocol=ipsec-esp in-interface=ether1
/ip firewall filter add chain=forward action=accept ipsec-policy=in,ipsec
/ip firewall filter add chain=forward action=accept ipsec-policy=out,ipsec

Four rules cover the traffic IPsec needs. UDP 500 carries IKE negotiation and UDP 4500 carries NAT-T, which is required whenever either endpoint is behind NAT even if both public addresses are static. ESP is the encrypted data plane. The two forward rules using ipsec-policy=in,ipsec and ipsec-policy=out,ipsec match only packets that have been validated against an installed security association — they are stricter than a plain source/destination accept and are the correct way to let tunnel traffic through while keeping the firewall default-deny. Remember that RouterOS evaluates input and forward chains independently, and that on a router with a drop all at the end of input, these rules must be placed above it.

MTU and Fragmentation

IPsec adds encapsulation overhead — around 50-70 bytes depending on mode and NAT-T — which lowers the usable MTU on the tunnel path. Large packets then either fragment or vanish, producing the classic symptom of a working ping and failing file transfers or HTTPS.

/ip firewall mangle add chain=forward action=change-mss \
    new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn \
    ipsec-policy=in,ipsec comment="MSS clamp inside tunnel"
/ip firewall mangle add chain=forward action=change-mss \
    new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn \
    ipsec-policy=out,ipsec comment="MSS clamp outbound tunnel"

Clamping MSS to the path MTU lets TCP endpoints negotiate a segment size that fits, which is far more reliable than fragmenting. If you would rather not clamp, reducing the LAN interface MTU works too, but it affects all traffic on that segment. The same fragmentation arithmetic for other overlay protocols is worked through in VXLAN MTU and fragmentation and, for the WireGuard case, in WireGuard MTU and handshake failures.

Verifying the Tunnel

/ip ipsec active-peers
/ip ipsec policy print
/ip ipsec installed-sa
/ip ipsec statistics
/ping 192.168.20.1 src-address=192.168.10.1 count=5

Read the four commands in order. /ip ipsec active-peers proves Phase 1 negotiated and shows which side is the responder and when the SA expires. /ip ipsec installed-sa proves Phase 2 completed — this is the one that matters, because a tunnel can have a live peer and no installed SA, which is exactly the state you get with a proposal mismatch. /ip ipsec statistics shows packet counters moving in both directions; counters rising on one side only is the signature of the NAT or policy problem described above. Finish with a ping sourced from the LAN address, not the router's WAN address, or you will test the wrong path entirely.

Troubleshooting: Where Tunnels Actually Fail

/system logging add topics=ipsec action=memory
/system logging print
/log print where topics~"ipsec"

Enabling the ipsec log topic is the fastest way to turn a silent failure into a specific one. The messages map onto a short list of causes:

• No active peer at all. Phase 1 is failing. Check that the peer address is the remote's real public IP, that UDP 500 is reachable from both ends, and that the profile's algorithms match. A peer address configured with the wrong prefix length is a common and invisible error.
• Active peer but no installed SA. Phase 2 mismatch — proposal algorithms, PFS group, or a traffic selector that does not intersect the remote's policy.
• SA installed but no traffic. Almost always NAT or policy ordering, and rarely the tunnel itself.
• Tunnel drops and reforms continuously. Clock drift, a lifetime mismatch between the two ends, or intermediate NAT that is rewriting the IKE ports. Enable a shorter lifetime to see the pattern sooner while debugging.

The debug messages themselves — what SA_INIT, IKE_AUTH and the various notify payloads mean — are decoded generically in IPsec IKEv2 troubleshooting with SA_INIT and IKE_AUTH debug, and the same Phase 1/Phase 2 split appears in the FortiGate site-to-site IPsec guide. If you would rather avoid IPsec's negotiation entirely for a simple point-to-point link, WireGuard site-to-site with wg0.conf is a lighter alternative with far fewer moving parts.

Frequently Asked Questions

Do I need a separate policy for each subnet pair? Yes. Each policy is a traffic selector; a pair of subnets that should be encrypted needs its own entry, and both ends must mirror it.

Is a PSK still acceptable, or should I use certificates? A long random PSK is fine for a small number of fixed tunnels. Certificates scale better, support identity rather than shared secrets, and are the right choice once the number of peers grows or you need per-device revocation.

Can I use dynamic (DHCP) WAN addresses? Yes, but one side must be the responder and you will need generate-policy or mode-config plus NAT-T, since the initiator cannot know the remote address in advance.

Why does the tunnel come up but the LAN hosts cannot reach each other? Work through three checks in order: the NAT bypass rule's position in /ip firewall nat, the forward chain rules for ipsec-policy, and the MSS clamp. One of those three explains nearly every case.

Does RouterOS 7 need separate IKEv1 and IKEv2 configuration? No — exchange-mode on the peer selects the version, and the rest of the object model is shared. Prefer IKEv2.

原文链接：https://mkcontroller.com/blog/remote_access/mikrotik/mikrotik-ipsec-site-to-site-vpn