Tunnels between locations

Besides WireGuard, RouterOS has a handful of plain tunnels. They wrap traffic from one router into packets aimed at the other, with no key negotiation. That makes them predictable and fast, and it also means they encrypt nothing by themselves.

Routed or layer 2

GRE and IPIP are routed: the tunnel is a point-to-point link with an address on each end, and you send networks through it with routes. This is nearly always what you want.
EoIP and VXLAN carry whole Ethernet frames, which puts both ends in the same layer 2 network: broadcasts, ARP and everything that goes wrong there included. Only take these when something really has to sit on one network.

Where it sits

In advanced, under VPN, there is a Tunnels group. You add a row per tunnel and fill it in for this side; the other router is configured separately, with the addresses the other way round.

If you are working on a site, you can draw it instead. Right-click a router on the network board, pick Tunnel to and the type. The tunnel is then configured on both routers from one record: virtual ports with a name, a transfer network (a /30 out of 10.255.255.0), keys or an IPsec secret, and routes. See also Example: two locations with a tunnel.

The fields

Name — the interface name on this router.
Type — GRE, EoIP, IPIP or VXLAN.
Remote address — the public IP address of the far end. This field wants an IP address, not a hostname. If that address changes regularly, use WireGuard, which can work with a name.
Tunnel address — this router's address inside the tunnel, 10.255.255.1/30 for example. Leave it empty for EoIP or VXLAN in the bridge: that tunnel needs no address of its own.
Tunnel id / VNI — for EoIP and VXLAN only, and required. Both ends need the same number, and two tunnels between the same routers need different numbers. On VXLAN this is called the VNI.
IPsec secret — fill this in and RouterOS encrypts the tunnel with IPsec. Available for GRE, EoIP and IPIP, not for VXLAN.
In the LAN bridge — for EoIP and VXLAN only: the tunnel becomes a port of your bridge, which makes the far side part of the same network.
Routes through the tunnel — for GRE and IPIP only: the networks on the far side, separated by commas. The tool turns them into routes.

Encryption

A tunnel without an IPsec secret is unencrypted. Everything that goes through it can be read along the way. The checks report it per tunnel. If the link runs over the internet, fill in a secret or use WireGuard.

VXLAN has no IPsec field in the tool. If you need VXLAN encrypted, add that by hand or run it through another tunnel. On GRE the script sets allow-fast-path=no as soon as a secret is present, because fast path and IPsec do not go together.

What the script contains

the interface: /interface gre, /interface ipip, /interface eoip with a tunnel-id, or /interface vxlan with a vni on port 4789, plus a vtep with the far end address
the tunnel address under /ip address, or the interface as a bridge port when you put it in the bridge
routes to the networks behind a GRE or IPIP tunnel
firewall rules that only accept traffic from the remote address: protocol GRE, IPIP or UDP 4789, and with an IPsec secret also UDP 500 and 4500 and ESP

MTU

This is the part that swallows evenings. A tunnel puts an extra header on every packet, so less fits inside.

EoIP in a bridge is given mtu=1500 by the tool. Left alone, RouterOS would land on 1458, and every full-size Ethernet frame in the bridge would be too big. At 1500 the outer packet is fragmented on the way instead and whole frames arrive.
VXLAN keeps 1500 and adds 50 bytes on top, so the path to the other end has to carry 1550 bytes. Over ordinary internet that is 1500. The check warns about it as long as the MTU on the ports is below 1550. Fix it with a larger MTU on the path (jumbo frames under Bridge and ports), or set the MTU of the devices behind the tunnel to 1450.
GRE and IPIP suffer less from this, but TCP connections that stall halfway almost always point at an MTU that does not fit.

On the board

Click a drawn tunnel and a few more choices appear:

Transfer network (/30) for routed tunnels; the two routers get the first and the second address.
Routes to the other location, or BGP over this tunnel. With BGP the routers learn each other's networks themselves, which means every router needs an AS number, and a BGP password is worth setting. See BGP.
VLANs over the tunnel for EoIP and VXLAN: every VLAN both routers carry, or a selection. The tunnel then becomes a trunk.
WireGuard shows its keys here, GRE, IPIP and EoIP a checkbox to encrypt with IPsec.

The site checks look over your shoulder: both routers need a public address, GRE, IPIP and EoIP need an IP address for it rather than a DNS name, a routed tunnel to a device that does not route achieves nothing, and two locations on the same address range produce routes that get in each other's way.

What goes wrong

The tunnel does not come up. Both ends have to be configured and the remote address has to be genuinely reachable. Some providers do not pass protocol GRE or IPIP, and behind NAT they work badly. WireGuard has less trouble there.
The tunnel is up but nothing passes. On GRE and IPIP the routes are usually missing on one side; on EoIP and VXLAN the tunnel id or the VNI does not match.
Large files stall while pings work. That is the MTU.
Everything is slow and the log is full. A layer 2 tunnel shares the broadcasts too. Consider a routed tunnel after all.