VPN Between Home and Cottage Networks

Overview

This guide explains how to connect two separate LANs — a home network and a cottage (or cabin/office) network — using a site-to-site VPN on RouterOS 7.x. Once connected, devices at either location can communicate as if they were on the same local network.

Two approaches are covered:

Method	Best For	NAT Traversal	Complexity
WireGuard (recommended)	RouterOS 7.x, both sides behind NAT	Yes	Low
IKEv2/IPsec	RouterOS 6.x/7.x, no extra PPP overhead	Yes (NAT-T)	Medium
L2TP/IPsec	Legacy/mixed environments, PPP features	Yes	Medium

:::note IPv6 This guide covers IPv4 site-to-site VPN only. IPv6 tunneling over these VPN types is not covered here. :::

Topology:

[Cottage LAN]          [Internet]          [Home LAN]
192.168.20.0/24  ←──── VPN tunnel ────→  192.168.10.0/24
  MikroTik                                  MikroTik
  (spoke/client)                            (hub/server)

The home router acts as the hub — it has a reachable public IP (or DDNS hostname). The cottage router initiates the connection outbound, so it can be fully behind NAT.

Prerequisites

RouterOS 7.1 or later on both routers
Home router: public IP address or DDNS hostname (e.g. home.example.net). MikroTik Cloud provides a free hostname (<id>.sn.mynetname.net) via /ip cloud set ddns-enabled=yes
Cottage router: any internet connection (NAT is fine)
Non-overlapping LAN subnets on each side (e.g. 192.168.10.0/24 and 192.168.20.0/24)
Admin access to both routers
NTP configured on both routers (required for IKEv2/IPsec — clock skew of more than a few minutes causes IKE phase 1 to fail)

:::note NTP for IPsec IKEv2/IPsec uses timestamps in the IKE exchange. If the two routers’ clocks differ by more than ~2 minutes, phase 1 negotiation will fail intermittently or consistently. Configure NTP on both routers before attempting IPsec:

/system ntp client set enabled=yes servers=pool.ntp.org

:::

:::note Subnet Planning If both locations currently use 192.168.1.0/24, you must renumber one side before setting up the VPN. Overlapping subnets cannot be routed correctly through a tunnel. :::

:::warning CGNAT / Both Sides Behind NAT If the home router is behind CGNAT (carrier-grade NAT), it does not have a reachable public IP and neither approach below will work without an intermediary. Contact your ISP to request a dedicated public IP, or use a VPS relay hub. The cottage router may be fully NATed — only the home (hub) side needs inbound reachability. :::

Configuration

Option A: WireGuard (Recommended)

WireGuard is fast, modern, and handles NAT well. RouterOS 7.x includes native WireGuard support.

Step 1 — Create WireGuard interfaces and note public keys

On the home router:

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

Note the public-key value — you will need it when configuring the cottage router.

On the cottage router:

/interface wireguard add name=wg-cottage
/interface wireguard print

Note the public-key value — you will need it when configuring the home router.

Step 2 — Assign tunnel addresses

On the home router:

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

On the cottage router:

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

Step 3 — Add peers

On the home router (add the cottage as a peer):

/interface wireguard peers add \
    interface=wg-home \
    public-key="COTTAGE_PUBLIC_KEY" \
    allowed-address=10.255.10.2/32,192.168.20.0/24 \
    persistent-keepalive=25

Replace COTTAGE_PUBLIC_KEY with the actual public key from the cottage router.

On the cottage router (add the home as a peer):

/interface wireguard peers add \
    interface=wg-cottage \
    public-key="HOME_PUBLIC_KEY" \
    endpoint-address=home.example.net \
    endpoint-port=13231 \
    allowed-address=10.255.10.1/32,192.168.10.0/24 \
    persistent-keepalive=25

Replace HOME_PUBLIC_KEY with the actual public key from the home router, and home.example.net with the home router’s public IP or DDNS hostname.

:::note Keepalive persistent-keepalive=25 keeps the tunnel alive through NAT by sending a keepalive packet every 25 seconds. Set this on the cottage side at minimum; setting it on both sides is fine. :::

Step 4 — Add routes

On the home router (route to cottage LAN):

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

On the cottage router (route to home LAN):

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

:::note Routing and allowed-address In RouterOS 7.x, WireGuard does not automatically install routes based on allowed-address. Explicit /ip route entries are always required for LAN-to-LAN routing. :::

Step 5 — Firewall and NAT

Home router — allow WireGuard inbound on WAN:

/ip firewall filter add chain=input protocol=udp dst-port=13231 action=accept comment="WireGuard VPN" place-before=0

Both routers — exclude VPN traffic from FastTrack:

If FastTrack is enabled (it is by default in many RouterOS configurations), VPN traffic must be explicitly excluded or it bypasses the routing/firewall path and traffic will be silently dropped. Add these rules before the FastTrack accept rule:

/ip firewall filter add chain=forward \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    action=accept comment="VPN: bypass FastTrack home→cottage" place-before=0

/ip firewall filter add chain=forward \
    src-address=192.168.20.0/24 dst-address=192.168.10.0/24 \
    action=accept comment="VPN: bypass FastTrack cottage→home" place-before=0

Both routers — exclude VPN traffic from masquerade NAT:

Add these rules before your existing masquerade rule:

/ip firewall nat add chain=srcnat \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    action=accept comment="VPN: no masquerade home→cottage"

/ip firewall nat add chain=srcnat \
    src-address=192.168.20.0/24 dst-address=192.168.10.0/24 \
    action=accept comment="VPN: no masquerade cottage→home"

Without these rules, your masquerade rule will NAT inter-site traffic and routing will break.

Option B: IKEv2/IPsec (Policy-Based)

IKEv2/IPsec provides a native encrypted tunnel without the PPP layer overhead of L2TP. It uses policy-based routing — traffic matching the configured selectors is automatically encrypted; no static route is needed for the tunnel itself.

Step 1 — Configure IPsec profile, proposal and policy on both routers

On both routers, create a profile that enables NAT traversal and a matching proposal:

/ip ipsec profile add name=home-cottage nat-traversal=yes dpd-interval=30 dpd-maximum-failures=5

/ip ipsec proposal add name=home-cottage auth-algorithms=sha256 enc-algorithms=aes-256-cbc pfs-group=modp2048

On the home router — the home side is the responder (passive), so the cottage can connect from any IP:

/ip ipsec peer add name=cottage address=0.0.0.0/0 exchange-mode=ike2 \
    profile=home-cottage passive=yes

/ip ipsec identity add peer=cottage auth-method=pre-shared-key secret="StrongPSK" \
    generate-policy=port-strict

/ip ipsec policy add peer=cottage tunnel=yes \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    sa-src-address=HOME_WAN_IP sa-dst-address=0.0.0.0 \
    proposal=home-cottage

Using passive=yes and address=0.0.0.0/0 allows the home router to accept connections from a cottage with a dynamic IP. generate-policy=port-strict lets RouterOS create child SA policies dynamically from the IKE negotiation.

On the cottage router (replace HOME_WAN_IP with the home router’s public IP or DDNS hostname):

/ip ipsec peer add name=home address=HOME_WAN_IP exchange-mode=ike2 \
    profile=home-cottage send-initial-contact=yes

/ip ipsec identity add peer=home auth-method=pre-shared-key secret="StrongPSK"

/ip ipsec policy add peer=home tunnel=yes \
    src-address=192.168.20.0/24 dst-address=192.168.10.0/24 \
    sa-src-address=COTTAGE_WAN_IP sa-dst-address=HOME_WAN_IP \
    proposal=home-cottage

:::note Policy-Based Routing IPsec tunnel mode intercepts traffic matching the src-address/dst-address selectors before routing. No static route is needed for the tunnel itself. Devices must still have a default gateway pointing to their local MikroTik router. :::

:::note Dynamic IP recovery send-initial-contact=yes on the cottage (initiator) peer causes RouterOS to send an Initial-Contact notification at the start of each IKE exchange. This forces the home responder to clear any stale SA state from a previous session and renegotiate cleanly — important when the cottage’s WAN IP changes (DHCP renewal, reconnect). Without it, the home side may retain a stale SA and refuse the new exchange until its DPD timeout fires. :::

Step 2 — Firewall

Home router — allow IPsec inbound on WAN:

/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept comment="IKEv2/IPsec" place-before=0
/ip firewall filter add chain=input protocol=ipsec-esp action=accept comment="IPsec ESP" place-before=0

Both routers — FastTrack exclusion (add before FastTrack rule):

/ip firewall filter add chain=forward \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    action=accept comment="VPN: bypass FastTrack home→cottage" place-before=0

/ip firewall filter add chain=forward \
    src-address=192.168.20.0/24 dst-address=192.168.10.0/24 \
    action=accept comment="VPN: bypass FastTrack cottage→home" place-before=0

Both routers — NAT bypass (add before masquerade rule):

/ip firewall nat add chain=srcnat \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    action=accept comment="VPN: no masquerade home→cottage"

/ip firewall nat add chain=srcnat \
    src-address=192.168.20.0/24 dst-address=192.168.10.0/24 \
    action=accept comment="VPN: no masquerade cottage→home"

:::note Certificate Authentication For higher security, replace PSK with certificate-based authentication. Create a CA on the home router, sign a certificate for each router, export/import the remote certificate, and use auth-method=digital-signature certificate=<local-cert> remote-certificate=<peer-cert> match-by=certificate in the identity. The certificate common-name must match the remote-id used, or phase 1 authentication fails even with a valid trusted cert. Example CA setup:

# On home router — create CA and sign two router certs
/certificate add name=CA-cert common-name=CA key-usage=key-cert-sign,crl-sign
/certificate sign CA-cert

/certificate add name=home-cert common-name=home
/certificate sign home-cert ca=CA-cert

/certificate add name=cottage-cert common-name=cottage
/certificate sign cottage-cert ca=CA-cert

# Export cottage cert and CA cert, import them on the cottage router
/certificate export-certificate cottage-cert export-passphrase=""
/certificate export-certificate CA-cert export-passphrase=""

After importing CA-cert and cottage-cert on the cottage router, update the identities on both sides:

# On home router — remove PSK identity and add cert identity
/ip ipsec identity remove [find peer=cottage]
/ip ipsec identity add peer=cottage auth-method=digital-signature \
    certificate=home-cert my-id=fqdn:home \
    remote-certificate=cottage-cert match-by=certificate

# On cottage router — remove PSK identity and add cert identity
/ip ipsec identity remove [find peer=home]
/ip ipsec identity add peer=home auth-method=digital-signature \
    certificate=cottage-cert my-id=fqdn:cottage \
    remote-certificate=home-cert match-by=certificate

my-id sets the identity this router presents to the peer; match-by=certificate means the peer is authenticated by certificate rather than by IP or DNS name. The common-name values (home and cottage) used when signing certs must match the my-id values, otherwise phase 1 authentication fails with a generic “no proposal chosen” or “id mismatch” error. :::

Option C: L2TP/IPsec

L2TP/IPsec uses a pre-shared key for IPsec and PPP credentials for authentication. It works with RouterOS 6.x and 7.x.

Step 1 — Configure the home router as L2TP server

/interface l2tp-server server set enabled=yes use-ipsec=yes ipsec-secret="StrongIPsecPSK"

/ppp secret add name=cottage password="StrongPassword" service=l2tp \
    local-address=10.255.30.1 remote-address=10.255.30.2

Choose a strong, unique value for both ipsec-secret and password.

Step 2 — Configure the cottage router as L2TP client

/interface l2tp-client add \
    name=l2tp-to-home \
    connect-to=home.example.net \
    user=cottage \
    password="StrongPassword" \
    use-ipsec=yes \
    ipsec-secret="StrongIPsecPSK" \
    disabled=no

Step 3 — Add routes

On the home router (use the PPP remote address assigned to the cottage peer):

/ip route add dst-address=192.168.20.0/24 gateway=10.255.30.2

On the cottage router (use the L2TP client interface):

/ip route add dst-address=192.168.10.0/24 gateway=l2tp-to-home

Step 4 — Firewall

Home router — allow L2TP/IPsec inbound on WAN:

/ip firewall filter add chain=input protocol=udp dst-port=500,4500,1701 action=accept comment="L2TP/IPsec" place-before=0
/ip firewall filter add chain=input protocol=ipsec-esp action=accept comment="IPsec ESP" place-before=0

Both routers — FastTrack exclusion (add before FastTrack rule):

/ip firewall filter add chain=forward \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    action=accept comment="VPN: bypass FastTrack home→cottage" place-before=0

/ip firewall filter add chain=forward \
    src-address=192.168.20.0/24 dst-address=192.168.10.0/24 \
    action=accept comment="VPN: bypass FastTrack cottage→home" place-before=0

Both routers — NAT bypass (add before masquerade rule):

/ip firewall nat add chain=srcnat \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    action=accept comment="VPN: no masquerade home→cottage"

/ip firewall nat add chain=srcnat \
    src-address=192.168.20.0/24 dst-address=192.168.10.0/24 \
    action=accept comment="VPN: no masquerade cottage→home"

Optional: DNS Over the Tunnel

By default, devices at the cottage use their local DNS. To resolve home LAN hostnames from the cottage (or to use the home router as the DNS resolver at the cottage), configure the cottage router to forward DNS queries to the home router’s tunnel address.

On the cottage router — set the home router’s tunnel IP as an additional DNS server:

/ip dns set servers=192.168.10.1

Replace 192.168.10.1 with the home LAN address of your home router (or its tunnel IP, e.g. 10.255.10.1 for WireGuard). The DNS query travels over the VPN tunnel.

Optional: MSS Clamping (Prevent Fragmentation)

VPN encapsulation reduces the effective MTU of the tunnel. TCP connections that use the full 1500-byte MTU can stall or hang because oversized packets are silently dropped by some ISPs. Proactively clamp TCP MSS on both routers to prevent this:

On both routers:

/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn \
    action=change-mss new-mss=clamp-to-pmtu comment="Clamp MSS to PMTU"

clamp-to-pmtu automatically sets MSS based on the outgoing interface MTU (including tunnel overhead). This eliminates most TCP fragmentation issues without needing to manually calculate an MTU value.

Verification

WireGuard

Check tunnel state and peer handshake:

/interface wireguard print detail
/interface wireguard peers print detail

A healthy peer shows a recent last-handshake timestamp and incrementing rx/tx byte counters.

IKEv2/IPsec

# View active peers (phase 1)
/ip ipsec active-peers print

# View installed security associations (phase 2)
/ip ipsec installed-sa print

# View policy state
/ip ipsec policy print

# Check IKE logs
/log print where topics~"ipsec"

A working tunnel shows at least one active peer and installed SA entries for each direction.

L2TP/IPsec

# View L2TP client state
/interface l2tp-client print detail

# View active PPP sessions (on server)
/ppp active print

# View IPsec security associations
/ip ipsec active-peers print
/ip ipsec installed-sa print

End-to-end connectivity

From either router, ping a device on the remote LAN:

/ping 192.168.20.1       # from home router to cottage gateway
/ping 192.168.10.1       # from cottage router to home gateway

Confirm routing:

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

Troubleshooting

Tunnel is up but traffic between LANs is silently dropped (FastTrack)

FastTrack allows established connections to bypass the normal firewall/routing path for performance. If VPN inter-site traffic hits the FastTrack rule before the forward-chain accept rules, packets are dropped without logging. To diagnose:

/ip firewall filter print stats where action=fasttrack-connection

If the byte counter climbs when you attempt cross-site traffic, FastTrack is interfering. Add the FastTrack exclusion rules from the Firewall section above. Rule order matters: the VPN accept rules must appear before the FastTrack rule in the forward chain.

IPsec phase 1 fails intermittently — NTP/clock skew

IKE timestamps are validated during phase 1. If the clocks on the two routers are out of sync by more than ~2 minutes, IKE will reject the exchange. Check clock status:

/system clock print
/system ntp client print

If NTP is not configured or the time is wrong, fix it:

/system ntp client set enabled=yes servers=pool.ntp.org

After NTP syncs, wait 30 seconds and retry the IPsec connection.

WireGuard peer never handshakes

Verify UDP port 13231 is forwarded to the home router on the ISP modem/router.
Check the public keys on both sides match exactly (no extra spaces or newlines).
Confirm endpoint-address on the cottage peer is the home router’s current public IP.
If the home IP changes frequently, set up DDNS and use the hostname instead.

WireGuard endpoint does not update after DDNS changes (RouterOS 7.x)

RouterOS resolves the endpoint-address hostname once at peer creation and when the tunnel first establishes. It does not continuously re-resolve the hostname. If the home router’s IP changes and the DDNS record updates, the cottage peer may retain the stale IP until the tunnel drops and re-establishes. To force resolution: disable and re-enable the WireGuard interface on the cottage router, or restart the peer. For environments with frequent IP changes, consider using MikroTik Cloud (ip cloud) which guarantees the DDNS entry is updated by the router itself.

L2TP tunnel connects but no traffic flows between LANs

Confirm NAT bypass rules are in place and ordered before the masquerade rule.
Verify routes point at the correct interface (l2tp-to-home).
Check that subnets do not overlap.

IKEv2/IPsec peers connect but traffic does not flow

Confirm NAT bypass rules are in place and ordered before the masquerade rule.
Verify tunnel=yes is set on the /ip ipsec policy entries — the default is no.
Check that src-address/dst-address selectors match the actual LAN subnets on each side.
Confirm ESP is allowed inbound: /ip firewall filter must accept protocol=ipsec-esp.
Check /ip ipsec installed-sa print — if empty after peers connect, phase 2 is failing; check proposals match.

IPsec phase 1 fails (L2TP/IPsec or IKEv2)

Ensure both sides use the same PSK (ipsec-secret for L2TP, secret for IKEv2 peer).
Allow UDP 500 and 4500 inbound on the home WAN.
Check /ip ipsec active-peers print — if empty, phase 1 is not completing.
For IKEv2: verify exchange-mode=ike2 on both peers.

Tunnel drops after idle period

For WireGuard: add persistent-keepalive=25 on the cottage peer.
For IKEv2/IPsec: dpd-interval and dpd-maximum-failures are set on the IPsec profile (not the peer). The profile created in Step 1 above includes dpd-interval=30 dpd-maximum-failures=5. If you used the default profile, update it: /ip ipsec profile set default dpd-interval=30 dpd-maximum-failures=5.
For L2TP/IPsec: keepalive is controlled at two independent layers — PPP (/ppp profile set default keepalive-timeout=30) and IPsec DPD on the peer.

IKEv2 home side not accepting connections from cottage with dynamic IP

Confirm the home router peer uses address=0.0.0.0/0 and passive=yes.
Confirm the identity uses generate-policy=port-strict so child SAs are negotiated dynamically.
If using a static policy (/ip ipsec policy), set sa-dst-address=0.0.0.0 on the home router to match any initiator address.

Cannot reach devices behind the remote router

Confirm the remote device’s default gateway points to the local MikroTik router.
Devices with static IPs must have a route back through their gateway to the VPN subnet.

Traffic flows but throughput is poor or connections hang (MTU/fragmentation)

WireGuard adds ~60 bytes of overhead. If the WAN MTU is 1500, the effective tunnel MTU is ~1420 (the RouterOS default). If your ISP uses PPPoE, WAN MTU may be 1492, leaving even less headroom.
Test with a ping of known size: /ping 192.168.20.1 size=1400 do-not-fragment
If large pings fail but small ones work, lower the WireGuard interface MTU: /interface wireguard set wg-home mtu=1380
For L2TP/IPsec, set MRU/MTU on both the PPP profile and the L2TP client to 1400 as a starting point.

VPN Between Home and Cottage Networks

VPN Between Home and Cottage Networks

Overview

Prerequisites

Configuration

Option A: WireGuard (Recommended)

Step 1 — Create WireGuard interfaces and note public keys

Step 2 — Assign tunnel addresses

Step 3 — Add peers

Step 4 — Add routes

Step 5 — Firewall and NAT

Option B: IKEv2/IPsec (Policy-Based)

Step 1 — Configure IPsec profile, proposal and policy on both routers

Step 2 — Firewall

Option C: L2TP/IPsec

Step 1 — Configure the home router as L2TP server

Step 2 — Configure the cottage router as L2TP client

Step 3 — Add routes

Step 4 — Firewall

Optional: DNS Over the Tunnel

Optional: MSS Clamping (Prevent Fragmentation)

Verification

WireGuard

IKEv2/IPsec

L2TP/IPsec

End-to-end connectivity

Troubleshooting

See Also