This guide shows how to build a permanent encrypted tunnel between a home router and a cottage router, so both LANs can reach each other as if they were on the same network. Both sites are assumed to have consumer ISP connections — dynamic WAN IPs and upstream NAT are handled automatically by IPsec NAT traversal (NAT-T).
What you get after setup:
Devices at the cottage can reach home file servers, printers, and NAS by IP
Devices at home can reach cottage cameras, smart home gear, or remote desktops
All traffic between the two sites is encrypted (AES-256)
RouterOS 7.x on both routers (IKEv2 is stable; VTI is fully supported)
A DDNS hostname for at least one site — both sides can use DDNS
UDP 500 and UDP 4500 reachable inbound on both WAN interfaces
IP protocol 50 (ESP) permitted inbound — or NAT-T (UDP 4500) if one site is behind carrier NAT
Tip — carrier-grade NAT (CGNAT): If your ISP assigns a private WAN IP (100.64.x.x or 10.x.x.x), you cannot receive inbound connections. In that case, install a cheap VPS as a relay, or switch to a service with a public IP. One side with a public IP is sufficient — the CGNAT side initiates the tunnel.
This guide uses IKEv2 with a pre-shared key (PSK) — the simplest approach for two RouterOS routers you control. For certificate-based auth (stronger, no shared secret), see Certificate Authentication.
RouterOS applies the srcnat chain before the IPsec policy engine evaluates outgoing packets. Without a bypass rule, masquerade rewrites the source IP from 192.168.1.x to the WAN address before the IPsec policy selector (src=192.168.1.0/24) is checked — so the packet is sent unencrypted. The bypass action=accept in srcnat prevents masquerade from running on IPsec-bound traffic.
If you prefer a topology-independent rule that works regardless of subnet:
NAT-T (nat-traversal=yes, the default) handles peers behind NAT automatically — ESP is wrapped in UDP/4500 when NAT is detected. Both peers can be behind their ISP’s NAT.
For dynamic WAN IPs, use DDNS hostnames in the address= field of /ip ipsec peer. RouterOS resolves the hostname when initiating the tunnel. If the remote IP changes, DPD (dpd-interval=30s) detects the dead peer and re-initiates, resolving the hostname again.
Recommended DDNS setup (on each router):
/ipcloud
setddns-enabled=yes
# Use the assigned hostname: <id>.sn.mynetname.net
/ip ipsec peer
set peer-cottage address=<cottage-cloud-id>.sn.mynetname.net
Or use a third-party DDNS provider via /ip dns scripts.
Certificates eliminate the shared secret. If the PSK is ever compromised, an attacker could impersonate either router. With certificates, each router proves its identity with a private key that never leaves the device.
Clock sync required: IKEv2 validates certificate validity periods against the current time. If either router’s clock is more than a few minutes off, certificate authentication will silently fail with no useful log message. Before generating or importing certificates, verify NTP is working:
/system/ntp/client/print
/system/clock/print
If NTP is not configured: /system/ntp/client set enabled=yes servers=pool.ntp.org
“no suitable proposal found” — Phase 1 or Phase 2 crypto parameters do not match. Verify that hash-algorithm, enc-algorithm, and dh-group in /ip ipsec profile are identical on both sides, and that /ip ipsec proposalenc-algorithms, auth-algorithms, and pfs-group also match.
No log entries at all — neither side is initiating. Check that the peer address= resolves correctly:
Verify the NAT bypass rule is in place and before the masquerade rule:
/ipfirewallnatprint
The bypass action=accept entry must have a lower rule number than any action=masquerade entry that matches WAN traffic.
Confirm the IPsec policy is matching traffic:
/ip ipsec policy printdetail
The ph2-count field should increment when you send traffic across the tunnel. If it stays at zero, the traffic is not matching the policy — check that source and destination subnets in the policy exactly match the actual LAN subnets.
Check that IPsec-encrypted traffic is not being dropped by the forward chain:
/ipfirewallfilterprint
Ensure there is no drop rule that blocks forwarded traffic between the two subnets.
This usually means the NAT bypass is missing or misordered on one router. Apply the fix to both sides and recheck installed-sa print for two-direction SAs.
