Skip to content
MikroTik RouterOS Docs

Connecting a Home Network to a Cottage: VPN Overview

Connecting a Home Network to a Cottage: VPN Overview

Section titled “Connecting a Home Network to a Cottage: VPN Overview”

A site-to-site VPN gives both locations a single unified network: printers, NAS drives, cameras, and smart-home gear at either site are reachable by IP address from the other. This page helps you choose the right technology and understand the practical constraints before you configure anything.

What you get after setup:

  • Devices at each site reach the other LAN transparently
  • All cross-site traffic is encrypted
  • The tunnel reconnects automatically after an IP change or reboot

Choosing a Technology

Section titled “Choosing a Technology”
ScenarioRecommended approach
Both routers run RouterOS 7.xWireGuard
One router is not MikroTikIPsec IKEv2
Already using IPsec elsewhereIPsec IKEv2
Both sites are behind CGNATRelay via VPS

WireGuard is the recommended default for MikroTik-to-MikroTik tunnels. It uses fewer configuration objects, handles dynamic IPs and NAT traversal cleanly, and has lower per-packet overhead than IPsec.

IPsec IKEv2 is the right choice when you need standards-based compatibility with third-party equipment, or when you want the stronger identity guarantees of certificate authentication.

Understanding Your IP Situation

Section titled “Understanding Your IP Situation”

The biggest variable is whether each site has a publicly reachable WAN address.

One site has a public IP (most common)

Section titled “One site has a public IP (most common)”

This is the typical setup for a home–cottage pair. Home broadband often has a stable or DDNS-trackable public IP; the cottage connection may be mobile data or a residential ISP with dynamic addressing.

  • The site with the public IP acts as the listener (home router in examples below)
  • The CGNAT or dynamic side initiates the tunnel outbound
  • DDNS on both sides is recommended — see IP Cloud / DDNS

Both WireGuard and IPsec guides use this layout:

HomeCottage
LAN subnet192.168.1.0/24192.168.2.0/24
WANPublic, DDNS-trackedDynamic or behind NAT

Both sites behind CGNAT

Section titled “Both sites behind CGNAT”

If your ISP assigns a private WAN address (e.g. 100.64.x.x, 10.x.x.x, or 192.168.x.x), neither site can receive inbound connections directly.

How to tell: run /ip/cloud/print or check the WAN IP against the IANA reserved ranges. If the address is private, you are behind CGNAT.

Solution — relay via a VPS:

  1. Rent a small cloud VPS (any provider) with a public IP
  2. Install RouterOS CHR or any WireGuard-capable OS on the VPS
  3. Both home and cottage establish outbound WireGuard tunnels to the VPS
  4. The VPS acts as a hub that forwards traffic between the two spokes
Home ──────────────► VPS (public IP) ◄────────────── Cottage
192.168.1.0/24      10.0.0.1 (hub)                  192.168.2.0/24
10.10.10.2/30 ◄────── 10.10.10.1/30 ──────► 10.10.10.3/30

On the VPS, enable IP forwarding and add routes to both LAN subnets. On each branch router, route the remote LAN via the VPS tunnel address.

DNS Across the Tunnel

Section titled “DNS Across the Tunnel”

Once routing is working, decide how each site resolves the other’s hostnames.

Simplest: use IP addresses

Section titled “Simplest: use IP addresses”

No DNS configuration needed — reach devices by IP. Works fine for small setups.

Split DNS with conditional forwarding

Section titled “Split DNS with conditional forwarding”

Each site keeps its own local DNS server (/ip/dns) and conditionally forwards the remote zone:

# On home router — forward cottage.local to cottage's DNS
/ip/dns/static
add name=cottage.local type=FWD forward-to=192.168.2.1 match-subdomain=yes

This requires the tunnel to be up for remote hostnames to resolve, which is normal expected behaviour.

Single central resolver

Section titled “Single central resolver”

Run DNS only at one site and set the other site’s router to use it as its upstream resolver. Simpler to manage but all remote queries traverse the tunnel.

MTU and MSS

Section titled “MTU and MSS”

Tunnels add encapsulation overhead, which reduces the effective MTU of packets crossing them. A symptom is that ping works but large file transfers or web pages load slowly or hang.

WireGuard over Ethernet: outer IP (20) + UDP (8) + WireGuard header (32) = 60 bytes of overhead. Set the WireGuard interface MTU to 1420 (default in RouterOS 7.x).

IPsec/ESP over Ethernet: overhead varies by cipher and NAT-T; typical safe value is 1400 for the tunnel interface MTU.

To avoid fragmentation, clamp TCP MSS on the VPN interface:

/ip/firewall/mangle
add action=change-mss chain=forward \
    in-interface=<wireguard-or-ipsec-interface> \
    new-mss=clamp-to-pmtu \
    passthrough=yes \
    protocol=tcp tcp-flags=syn

FastTrack and Connection Tracking

Section titled “FastTrack and Connection Tracking”

RouterOS FastTrack bypasses the full firewall chain for established connections, which can interfere with IPsec policy matching and marks applied in mangle rules.

If tunnel traffic stops flowing shortly after the tunnel comes up, check whether FastTrack is capturing VPN flows:

/ip/firewall/filter
add action=accept chain=forward \
    in-interface=<vpn-interface> \
    connection-state=established,related \
    comment="Allow VPN-forwarded traffic before FastTrack"

Place this rule before any FastTrack or drop rules.

Implementation Guides

Section titled “Implementation Guides”

See Also

Section titled “See Also”