MikroTik / Lab · RouterOS 7 · July 2026

MikroTik Lab
HQ + Branches — GRE over IPsec WAN

A real branch WAN through an ISP that won't route your private LANs: GRE tunnels carry the traffic, IPsec encrypts them, and OSPF runs on top so every site learns the others automatically. This lab builds an HQ hub and two branches on RouterOS 7 — the twin of the Cisco GRE-over-IPsec lab, done the MikroTik way.

MikroTik RouterOS GRE IPsec OSPF Lab

Why not just IPsec? Because policy-based IPsec alone can't easily carry a routing protocol — OSPF uses multicast, which plain IPsec tunnels won't transport. Wrap the traffic in GRE first and you get a real point-to-point interface that carries anything, including OSPF's multicast hellos; then IPsec encrypts the GRE. On RouterOS the encryption is almost free: the GRE interface takes an ipsec-secret and auto-builds the IPsec policies for you. Run OSPF over the GRE tunnels and each site learns every other site's LAN with no static-route bookkeeping.

This is the exact pattern of the Cisco GRE-over-IPsec lab — hub-and-spoke tunnels, encrypted, with a dynamic routing protocol on top. HQ is the hub with a tunnel to each branch; branches tunnel only to HQ. (For a many-branch version without per-tunnel config, see the WireGuard hub-and-spoke.)

Prerequisites

The VPN and routing basics — IPsec and OSPF
Three routers with public IPs (or NAT with UDP 500/4500 + protocol 47/GRE forwarded)
Non-overlapping LANs: HQ 10.0.0.0/24, branches 10.1/10.2.0.0/24

HQ — a GRE Tunnel per Branch

The hub builds one encrypted GRE interface toward each branch, each with a small transit subnet. ipsec-secret turns on the encryption without a single manual IPsec policy.

RouterOS 7 (HQ) — encrypted GRE to Branch 1 and Branch 2

# One GRE per branch; ipsec-secret auto-creates the IPsec that protects it.
/interface gre
add name=gre-b1 remote-address=198.51.100.2 local-address=203.0.113.1 ipsec-secret="Str0ng-B1!"
add name=gre-b2 remote-address=198.51.100.3 local-address=203.0.113.1 ipsec-secret="Str0ng-B2!"

# A tiny transit /30 on each tunnel for OSPF to run over.
/ip address
add address=172.31.1.1/30 interface=gre-b1
add address=172.31.2.1/30 interface=gre-b2

⚠ Gotcha — GRE Needs Protocol 47, Not a Port; Mind the MTU

Two things bite here. GRE isn't TCP or UDP — it's IP protocol 47 — so if either side is behind a firewall/NAT, you must permit protocol 47 and the IPsec transports (UDP 500/4500, ESP), not just "open a port." Second, GRE + IPsec adds significant header overhead; the tunnel's usable MTU drops well below 1500, and if you don't lower it, large packets fragment or black-hole (the dreaded "ping works, file transfers hang"). Set the GRE interface MTU sensibly (≈1400) and consider mss-clamp so TCP negotiates a size that fits. This overhead trap is identical on Cisco.

A Branch — Tunnel Home to HQ

Each branch is the mirror: one encrypted GRE back to HQ, the other end of the transit /30. Copy it per site, changing only the addresses and secret.

RouterOS 7 (Branch 1) — GRE + IPsec to HQ

/interface gre add name=gre-hq remote-address=203.0.113.1 local-address=198.51.100.2 ipsec-secret="Str0ng-B1!"
/ip address add address=172.31.1.2/30 interface=gre-hq
# Same secret as HQ's gre-b1, mirrored endpoints. Branch 2 mirrors gre-b2.

OSPF Over the Tunnels

Now the payoff. Run OSPF on the GRE interfaces and each site's LAN is learned everywhere — add a third branch later and its subnet just appears, no static routes to edit.

RouterOS 7 (HQ) — OSPF on the GRE tunnels + the LAN

/routing ospf instance add name=v7 router-id=10.0.0.1
/routing ospf area add name=backbone area-id=0.0.0.0 instance=v7
/routing ospf interface-template
add interfaces=gre-b1,gre-b2 area=backbone cost=10 network-type=ptp
add interfaces=bridge-lan area=backbone cost=10 passive   # advertise the LAN, don't peer on it
# Branches run the mirror: OSPF on gre-hq + their own LAN (passive).

💡 passive on the LAN, ptp on the Tunnels

Two small settings that matter. Mark the LAN interface-template passive so OSPF advertises the LAN subnet but never tries to form an adjacency with a host down there (and can't be tricked into one by something on the LAN). Set the GRE tunnels to point-to-point (ptp) network type — they're literally point-to-point links, and ptp skips DR/BDR election for faster, simpler adjacencies. These are the same choices the Cisco lab makes; good hygiene on any tunnel-based WAN.

Verify End to End Safe to Run

Walk it in layers: GRE up, IPsec actually encrypting it, OSPF adjacent, LANs learned, and a LAN-sourced ping across.

RouterOS 7 (HQ) — the health walk

/interface gre print                    # tunnels running (R flag)
/ip ipsec active-peers print            # auto-built SAs established
/routing ospf neighbor print            # both branches Full
/ip route print where ospf              # 10.1.0.0/24 and 10.2.0.0/24 learned
/ping 10.1.0.1 src-address=10.0.0.1     # HQ LAN -> Branch 1 LAN

Takeaways

GRE carries what IPsec alone can't — a real interface for OSPF's multicast; IPsec then encrypts the GRE.
On RouterOS, encryption is one field — ipsec-secret on the GRE auto-builds the IPsec policies.
GRE is IP protocol 47 — permit it plus the IPsec transports through any firewall/NAT, not just a port.
Lower the tunnel MTU / clamp MSS — GRE+IPsec overhead black-holes big packets otherwise ("ping fine, transfers hang").
OSPF over the tunnels means zero static bookkeeping — new branches' LANs appear automatically.
passive the LAN, ptp the tunnels — advertise without peering on the LAN; skip DR election on point-to-point links.

Branches stitched to HQ with brittle static tunnels?

NOCTIS builds encrypted, dynamically-routed branch WANs on MikroTik and Cisco across Crete — GRE/IPsec or WireGuard overlays where new sites drop in cleanly and OSPF handles the rest.

Book a Discovery Call →