Site-to-Site WireGuard VPN on MikroTik: Connect Two Offices Securely (2026 Guide)

WireGuard isn't just for remote workers – it's also an excellent choice for site‑to‑site VPNs. Unlike IPsec, WireGuard is lighter, faster, and easier to debug. In this guide, you'll learn how to permanently connect two MikroTik routers (head office and branch) so that all devices on both LANs can communicate securely over the internet.

When to Use Site‑to‑Site WireGuard

• You have two or more physical locations sharing the same company network.
• You want centralised file servers, printers, or internal websites.
• You need to manage remote devices via the same LAN addressing.
• You prefer a modern VPN with better performance than IPsec or OpenVPN.

Prerequisites & Keywords for This Setup

• Two MikroTik routers running RouterOS v7.1 or later (WireGuard is not in v6).
• Each router must have a public IP (static or dynamic – we'll use DDNS).
• Different LAN subnets at each site (e.g., 192.168.1.0/24 and 192.168.2.0/24).
• Basic knowledge of IP addressing, routing, and firewall concepts.

Network Topology Example

• Site A (HQ): LAN 192.168.1.0/24, WAN IP 203.0.113.10 (static).
• Site B (Branch): LAN 192.168.2.0/24, WAN IP 198.51.100.20 (static).
• We'll create a WireGuard tunnel between the two routers with tunnel IPs 10.10.10.1/30 and 10.10.10.2/30.

Step 1: Create WireGuard Interfaces on Both Routers

On Site A (HQ):

/interface wireguard add name=wg-site2site listen-port=51820 private-key="auto"

On Site B (Branch):

/interface wireguard add name=wg-site2site listen-port=51820 private-key="auto"

WinBox: Interfaces → WireGuard → Add New → Name: wg-site2site, Listen Port: 51820, Private Key: leave blank (auto‑generated).

After creation, note the public keys:

/interface wireguard print

Copy the public-key of each router – you'll need them later.

Step 2: Assign Tunnel IP Addresses

On Site A:

/ip address add address=10.10.10.1/30 interface=wg-site2site

On Site B:

/ip address add address=10.10.10.2/30 interface=wg-site2site

Step 3: Add Peer Entries (Each Side Points to the Other)

On Site A (pointing to Site B):

/interface wireguard peers add interface=wg-site2site public-key="<Site-B-public-key>" endpoint-address=198.51.100.20 endpoint-port=51820 allowed-address=10.10.10.2/32,192.168.2.0/24

On Site B (pointing to Site A):

/interface wireguard peers add interface=wg-site2site public-key="<Site-A-public-key>" endpoint-address=203.0.113.10 endpoint-port=51820 allowed-address=10.10.10.1/32,192.168.1.0/24

Important: The allowed-address field tells WireGuard which remote subnets are reachable via this peer. Include both the tunnel IP and the remote LAN.

Step 4: Firewall Rules – Allow WireGuard Traffic

On both routers, add these input chain rules (before any drop rule):

/ip firewall filter add chain=input protocol=udp dst-port=51820 action=accept comment="Allow WireGuard site-to-site"
/ip firewall filter add chain=input connection-state=established,related action=accept comment="Accept established/related"

Also allow forwarding between the two LANs:

/ip firewall filter add chain=forward src-address=192.168.1.0/24 dst-address=192.168.2.0/24 action=accept comment="HQ to Branch"
/ip firewall filter add chain=forward src-address=192.168.2.0/24 dst-address=192.168.1.0/24 action=accept comment="Branch to HQ"

Step 5: NAT Bypass – Don't Masquerade VPN Traffic

If you have a default masquerade rule for your LAN (e.g., chain=srcnat src-address=192.168.0.0/16 action=masquerade), it will also catch traffic going to the other site's LAN and break the VPN. Add a rule above the masquerade to exclude VPN‑destined traffic.

On Site A:

/ip firewall nat add chain=srcnat src-address=192.168.1.0/24 dst-address=192.168.2.0/24 action=accept comment="No NAT to Site B"

On Site B:

/ip firewall nat add chain=srcnat src-address=192.168.2.0/24 dst-address=192.168.1.0/24 action=accept comment="No NAT to Site A"

Step 6: Add Static Routes (If Not Automatically Added)

WireGuard peers with allowed-address that include the remote LAN automatically add routes. Verify with:

/ip route print where dst-address~"192.168.2"

If missing, add manually:

On Site A:

/ip route add dst-address=192.168.2.0/24 gateway=10.10.10.2

On Site B:

/ip route add dst-address=192.168.1.0/24 gateway=10.10.10.1

Step 7: Test the Tunnel

1. From a PC at Site A (e.g., 192.168.1.100), ping a device at Site B (e.g., 192.168.2.1 – the router's LAN IP).
2. From Site B, ping back.
3. Check active WireGuard peers:

/interface wireguard peers print

You should see rx and tx packets increasing and a handshake time.

Step 8: (Optional) Run OSPF Over WireGuard for Dynamic Routing

If you have more than two sites or complex routing, you can run OSPF over the WireGuard tunnel. This is a powerful alternative to static routes.

On both routers, enable OSPF on the WireGuard interface:

/routing ospf instance add name=ospf-vpn router-id=1.1.1.1 (use unique IDs)
/routing ospf area add instance=ospf-vpn name=backbone area-id=0.0.0.0
/routing ospf interface add interface=wg-site2site area=backbone network-type=point-to-point
/routing ospf network add network=192.168.1.0/24 area=backbone (on Site A)
/routing ospf network add network=192.168.2.0/24 area=backbone (on Site B)

OSPF will automatically exchange routes and handle failover if you add redundant tunnels.

Step 9: Enable Persistent Keepalive (For Dynamic IPs or Unreliable Connections)

If one side has a dynamic public IP or sits behind a NAT, add persistent-keepalive=25s to the peer on the side that initiates. Usually the side with the static IP can be the listener, the dynamic side should send keepalives.

Example on Site B (dynamic IP) pointing to Site A (static):

/interface wireguard peers set [find interface=wg-site2site] persistent-keepalive=25

Step 10: Using DDNS When Both Sides Have Dynamic IPs

Enable MikroTik Cloud DDNS on both routers:

/ip cloud set ddns-enabled=yes
/ip cloud print

You'll get hostnames like xxxxxx.sn.mynetname.net. Then in the peer configuration, use the DDNS hostname as endpoint-address. For the side that cannot be reached directly (both dynamic), you may need a third‑party relay or use a VPS as a rendezvous point – beyond this guide.

Troubleshooting Common Site‑to‑Site Issues

• No handshake: Verify UDP 51820 is allowed in the firewall on both ends. Check that the endpoint addresses are correct and reachable. Try pinging the remote WAN IP.
• Handshake works but LANs cannot ping each other: Most likely NAT masquerade is still translating the traffic (revisit Step 5). Also ensure the allowed‑address includes the remote LAN (not just the tunnel IP).
• Only one direction works: Check that both routers have symmetric peer entries and that the firewall forward chain allows both source/destination pairs.
• High latency or packet loss: WireGuard is usually very efficient, but if your internet link is lossy, consider lowering MTU on the WireGuard interface: /interface wireguard set wg-site2site mtu=1420.

Security Hardening Tips

• Use a non‑standard listen port (not 51820) to reduce automated scans.
• Rotate private keys periodically (generate new ones and update peers).
• Limit the allowed-addresses to only the subnets that really need to communicate.
• Combine with firewall address lists to restrict which source IPs can even attempt a WireGuard handshake (though WireGuard itself is resistant to unauthenticated probes).

Comparison: WireGuard vs. IPsec for Site‑to‑Site

Conclusion

Site‑to‑site WireGuard on MikroTik is a modern, performant alternative to legacy IPsec tunnels. Once set up, your two offices will function as one seamless network – perfect for shared file servers, internal websites, and centralised management. For larger topologies (three or more sites), consider combining WireGuard with OSPF or BGP for dynamic routing.

Next steps: explore WireGuard over VLANs or multi‑hop WireGuard (VPN cascading). If you need user‑based remote access, see our WireGuard remote access guide.