Skip to content

Site-to-Site WireGuard VPN: Home Network to Cottage

Site-to-Site WireGuard VPN: Home Network to Cottage

Section titled “Site-to-Site WireGuard VPN: Home Network to Cottage”

This guide builds a permanent encrypted WireGuard tunnel between a home router and a cottage router so both LANs can reach each other transparently. WireGuard is the recommended choice for MikroTik-to-MikroTik site-to-site VPNs on RouterOS 7.x — it requires fewer configuration objects than IPsec, has lower overhead, and handles dynamic IPs and NAT cleanly.

What you get after setup:

  • Devices at the cottage can reach home file servers, NAS, and printers by IP
  • Devices at home can reach cottage cameras, smart home gear, and remote desktops
  • All traffic between sites is encrypted with WireGuard’s ChaCha20-Poly1305 cipher

Prefer IPsec? See Site-to-Site VPN: Home Network to Cottage (IPsec) for the IKEv2/IPsec version.


  • RouterOS 7.x on both routers (WireGuard was added in RouterOS 7.0)
  • At least one site with a public, reachable WAN IP (or port-forwarded UDP port)
  • DDNS hostname recommended for the reachable site if the WAN IP is dynamic
  • UDP port 13231 (or your chosen port) open inbound on the reachable site’s WAN

Carrier-grade NAT (CGNAT): If your ISP assigns a private WAN address (100.64.x.x or 10.x.x.x range), that site cannot receive inbound connections. One public-reachable site is enough — the CGNAT-side router initiates the tunnel and sends keepalives. If both sites are behind CGNAT, you need a VPS relay with a public IP.


HomeCottage
LAN subnet192.168.1.0/24192.168.2.0/24
WAN addressPublic (DDNS: home.example.dyndns.org)Dynamic / NAT
WireGuard tunnel IP10.10.10.1/3010.10.10.2/30
WireGuard listen port1323113231

In this layout, the home router is reachable and the cottage router initiates the connection. Adjust subnets and hostnames to match your setup.


Run this on each router. RouterOS generates the private/public key pair automatically when the interface is created.

Home router:

/interface/wireguard
add name=wg-cottage listen-port=13231 mtu=1420

Cottage router:

/interface/wireguard
add name=wg-home listen-port=13231 mtu=1420

You need each router’s public key to configure the peer on the opposite side.

/interface/wireguard print

Note the public-key value from each router. You will need:

  • Home’s public key → entered on the cottage router
  • Cottage’s public key → entered on the home router

Home router:

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

Cottage router:

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

Home router (accepts the cottage connection):

/interface/wireguard/peers
add interface=wg-cottage \
public-key="<COTTAGE_PUBLIC_KEY>" \
allowed-address=10.10.10.2/32,192.168.2.0/24 \
comment="Cottage router"

The home router does not set endpoint-address here — it accepts connections from any source matching the public key.

Cottage router (initiates toward home):

/interface/wireguard/peers
add interface=wg-home \
public-key="<HOME_PUBLIC_KEY>" \
endpoint-address=home.example.dyndns.org \
endpoint-port=13231 \
allowed-address=10.10.10.1/32,192.168.1.0/24 \
persistent-keepalive=25s \
comment="Home router"

persistent-keepalive=25s keeps the NAT mapping alive on the cottage side’s upstream router and ensures the home router always knows the cottage’s current endpoint.

Home router — route cottage LAN traffic into the tunnel:

/ip/route
add dst-address=192.168.2.0/24 gateway=wg-cottage

Cottage router — route home LAN traffic into the tunnel:

/ip/route
add dst-address=192.168.1.0/24 gateway=wg-home

Home router — allow inbound WireGuard and forward traffic between LANs:

Prerequisite — WAN interface list: The firewall rule below uses in-interface-list=WAN. This list exists on routers running the default factory configuration, but not on routers reset with no-defaults=yes or fresh CHR instances. If the list is missing, create it first and add your WAN interface (typically ether1):

/interface/list add name=WAN
/interface/list/member add interface=ether1 list=WAN
# Allow WireGuard handshake on WAN
/ip/firewall/filter
add chain=input action=accept protocol=udp dst-port=13231 \
in-interface-list=WAN comment="Allow WireGuard (cottage)"
# Allow forwarded traffic between home LAN and cottage LAN
add chain=forward action=accept \
src-address=192.168.1.0/24 dst-address=192.168.2.0/24 \
comment="Home LAN to cottage LAN"
add chain=forward action=accept \
src-address=192.168.2.0/24 dst-address=192.168.1.0/24 \
comment="Cottage LAN to home LAN"

Place these rules before any generic drop rules in the chain.

Cottage router — same forward rules, WireGuard input rule only needed if cottage has a public IP:

/ip/firewall/filter
add chain=forward action=accept \
src-address=192.168.2.0/24 dst-address=192.168.1.0/24 \
comment="Cottage LAN to home LAN"
add chain=forward action=accept \
src-address=192.168.1.0/24 dst-address=192.168.2.0/24 \
comment="Home LAN to cottage LAN"

No NAT bypass needed: Unlike IPsec, WireGuard uses a real interface (wg-cottage/wg-home). Masquerade rules that match out-interface-list=WAN do not apply to WireGuard tunnel traffic, so no extra NAT bypass rule is required.


WireGuard handles dynamic IPs gracefully:

  • The cottage router sets endpoint-address to the home router’s DDNS hostname. RouterOS resolves the hostname when re-establishing the peer connection.
  • The home router accepts connections from any IP matching the cottage’s public key and updates its view of the cottage endpoint automatically when it receives a valid packet.
  • persistent-keepalive=25s on the cottage peer ensures the connection stays alive and the home router tracks the current cottage WAN address.

Enable MikroTik Cloud DDNS on the home router:

/ip/cloud
set ddns-enabled=yes
# Then use the assigned hostname in the cottage peer endpoint-address:
# <unique-id>.sn.mynetname.net

Check the WireGuard interface and peer status

Section titled “Check the WireGuard interface and peer status”
/interface/wireguard/print detail
/interface/wireguard/peers/print detail

A healthy peer shows a recent last-handshake timestamp and non-zero rx and tx byte counters. If last-handshake is blank or very old, the tunnel is not established.

/ip/route/print where dst-address=192.168.1.0/24
/ip/route/print where dst-address=192.168.2.0/24

Both routes should show status A (active) via the WireGuard interface.

Note: RouterOS route print does not support the in operator for IP prefix filtering. Use separate where dst-address= queries for each prefix.

Ping the opposite router’s tunnel IP first:

# From home router CLI
/ping 10.10.10.2
# From cottage router CLI
/ping 10.10.10.1

Then ping a device on the opposite LAN:

# From home router, reach a cottage LAN device
/ping 192.168.2.1

No handshake / last-handshake never updates

Section titled “No handshake / last-handshake never updates”

Verify the public key on each peer — a single wrong character prevents the handshake. Re-print keys with /interface/wireguard print on both routers and compare.

Check the home router firewall input chain:

/ip/firewall/filter/print

Ensure the UDP 13231 accept rule exists and appears before any drop or reject rule that would match inbound WAN traffic.

Confirm the DDNS hostname resolves to the home router’s WAN IP:

/ip/dns/cache/print
/ping home.example.dyndns.org

Check that the forward chain rules exist and are ordered before any drop rule:

/ip/firewall/filter/print where chain=forward

Check that routes point to the WireGuard interface and are active:

/ip/route/print detail where dst-address=192.168.2.0/24

Confirm that devices on each LAN have a gateway that routes inter-site traffic through the router (not directly to the internet).

WireGuard sends no traffic when the tunnel is idle, so NAT mappings on ISP routers (especially CGNAT) expire — typically after 30–60 seconds. When the mapping is gone, inbound packets from the other side are dropped silently. persistent-keepalive prevents this by sending a small handshake packet before the mapping can expire.

Ensure persistent-keepalive is set on the initiating side (cottage — the side behind NAT or CGNAT):

/interface/wireguard/peers/print detail

If persistent-keepalive is 0s or absent, add it:

/interface/wireguard/peers
set [find comment="Home router"] persistent-keepalive=25s

25s is the standard value — short enough to beat most ISP NAT timeouts (typically 30–60 s).

One side is behind CGNAT (no public IP on either site)

Section titled “One side is behind CGNAT (no public IP on either site)”

If both sites have private WAN addresses, direct peer-to-peer WireGuard is not possible. Options:

  1. MikroTik CHR on a VPS — deploy a hub router with a public IP and create two tunnels (home→hub, cottage→hub); route between them on the hub.
  2. Request a static IP or business plan from one ISP — one public endpoint is sufficient.