NetCrosswalk: Cross-Vendor Network Task Translator

IPsec

1. Profile (phase 1 proposal): /ip ipsec profile add name=to-branch enc-algorithm=aes-256 hash-algorithm=sha256 dh-group=modp2048
2. Peer: /ip ipsec peer add name=branch address=203.0.113.20 profile=to-branch exchange-mode=ike2
3. Identity (auth): /ip ipsec identity add peer=branch auth-method=pre-shared-key secret="<psk>"
4. Proposal (phase 2): /ip ipsec proposal add name=to-branch enc-algorithms=aes-256-cbc auth-algorithms=sha256 pfs-group=modp2048
5. Policy (selectors): /ip ipsec policy add src-address=192.168.88.0/24 dst-address=192.168.99.0/24 tunnel=yes peer=branch proposal=to-branch
6. Exclude the tunnel from NAT — add above your masquerade rule: /ip firewall nat add chain=srcnat action=accept src-address=192.168.88.0/24 dst-address=192.168.99.0/24 place-before=0
7. GUI: IP → IPsec with a tab per object. Verify: /ip ipsec active-peers print and /ip ipsec policy print

• The NAT exclusion is the number one MikroTik IPsec failure. Your masquerade rule rewrites the source address before the IPsec policy can match it, so the tunnel establishes and no traffic ever uses it. Add the action=accept srcnat rule *above* the masquerade rule.
• RouterOS IPsec is policy-based by default: five separate objects (profile, peer, identity, proposal, policy) that must be internally consistent. Any mismatch shows as a phase 1 or phase 2 failure in /log print with topics=ipsec.
• Allow the protocols in the input chain: UDP/500, UDP/4500, and IP protocol 50 (ESP). A default drop rule blocks the tunnel silently.
• /log print where topics~"ipsec" is the only way to debug this — the status flags alone will not tell you which proposal mismatched.
• The right choice when the far end is a non-MikroTik box (FortiGate, PAN-OS, Cisco, pfSense) — IPsec is the one protocol every vendor here actually interoperates on.

WireGuard (RouterOS 7.x, MikroTik-to-MikroTik or any WireGuard peer)

1. On Site A: /interface wireguard add name=wg-branch listen-port=13231 then /ip address add address=10.99.0.1/30 interface=wg-branch.
2. On Site B: /interface wireguard add name=wg-hq listen-port=13231 then /ip address add address=10.99.0.2/30 interface=wg-hq.
3. Exchange public keys (/interface wireguard print on each side shows its own).
4. On Site A, add Site B as a peer: /interface wireguard peers add interface=wg-branch public-key="<site-B-public-key>" endpoint-address=203.0.113.20 endpoint-port=13231 allowed-address=10.99.0.2/32,192.168.99.0/24 persistent-keepalive=25s.
5. On Site B, mirror it back: /interface wireguard peers add interface=wg-hq public-key="<site-A-public-key>" endpoint-address=198.51.100.10 endpoint-port=13231 allowed-address=10.99.0.1/32,192.168.88.0/24 persistent-keepalive=25s.
6. Add routes for the remote LAN via the tunnel on both sides: /ip route add dst-address=192.168.99.0/24 gateway=wg-branch (and the mirror on Site B).
7. Allow the WireGuard port in each router's input chain, and add forward-chain rules for the traffic you want to pass between the two LANs.
8. Verify: /interface wireguard peers print — check last-handshake on both ends.

• Genuinely simpler than IPsec here: one interface, one peer, no five-object policy chain, and no NAT-exclusion trap — allowed-address doubles as both the crypto scope and the routing statement, so there's one thing to get right instead of five.
• persistent-keepalive matters more for site-to-site than it might seem: without it, a NAT device between the sites can drop the UDP mapping during idle periods and the tunnel silently stops passing traffic until fresh traffic re-triggers a handshake.
• This only interoperates with another genuine WireGuard endpoint — a MikroTik router, or any other box (pfSense, a Linux box, another WireGuard implementation). It will not talk to a pure-IPsec vendor like FortiGate or PAN-OS, since they don't speak WireGuard at all.
• Overlapping allowed-address ranges between two different peers on the same interface will misroute traffic — keep each peer's ranges disjoint.

IPsec (Manual, or Site Magic for UniFi-to-UniFi)

1. Settings → VPN → Site-to-Site VPN → Create New → choose *Manual IPsec* (or *Site Magic* for UniFi-to-UniFi).
2. Set the remote gateway IP, the remote and local subnets, and the pre-shared key.
3. Under *Advanced*, match the encryption, hash, DH group, and PFS to the far end exactly.
4. Save; the gateway provisions. Status appears on the VPN page.

• Site Magic (UniFi-to-UniFi, cloud-orchestrated) is easy and reliable but only works between UniFi gateways on the same Ubiquiti account. For anything third-party you need *Manual IPsec*.
• The Advanced parameter list is narrower than other vendors' — some proposal combinations a FortiGate or PAN-OS offers simply cannot be selected here, so you may have to weaken/adjust the far end to a UniFi-supported set.
• There is no negotiation log in the UI. Debugging a failing manual tunnel means SSH to the gateway and reading swanctl --list-sas / ipsec statusall and the strongSwan logs — a big step down from the other platforms.
• Route-based (VTI) support has varied by firmware; policy-based is the safer assumption for interop.

OpenVPN

1. Settings → VPN → Site-to-Site VPN → Create New → choose *OpenVPN* as the type instead of Manual IPsec.
2. Set the remote peer's address, the shared key or certificate (depending on controller version), and the local/remote subnets.
3. Save; the gateway provisions and pushes the tunnel config.
4. Verify: the Site-to-Site VPN page shows the tunnel's connection status.

• The native, first-class non-IPsec option here — it's in the same wizard as IPsec, not a workaround, so it gets the same auto-provisioning and status page.
• Interoperates with any standard OpenVPN peer, not just UniFi-to-UniFi, which makes it a reasonable choice when the far end is a Linux box or another OpenVPN-capable firewall rather than a matching UniFi gateway.

WireGuard (manual Server + Client bridge — not an official site-to-site feature)

1. There is no dedicated WireGuard site-to-site option in the Site-to-Site VPN wizard — this uses the remote-access building blocks instead, cross-connected.
2. On Site A's gateway: Settings → VPN → VPN Server → Create New → WireGuard, add a peer representing Site B, and note the generated config.
3. On Site B's gateway: Settings → VPN → VPN Client → WireGuard, import the config generated on Site A so Site B's gateway connects in as a client.
4. On Site A, manually add a static route (Settings → Routing) sending Site B's LAN subnet via the tunnel address assigned to that peer — the wizard only expects a single device, not a whole subnet behind it.
5. On Site B, add the mirror static route sending Site A's LAN subnet via the tunnel.
6. Add firewall rules on both sides permitting the cross-site traffic — this path doesn't auto-create policies the way the official Site-to-Site wizard does.
7. Verify: both the VPN Server (Site A) and VPN Client (Site B) pages show the connection active with a recent handshake.

• This is a documented community workaround, not an officially supported site-to-site mode — Ubiquiti has an open feature request for real WireGuard site-to-site that hasn't shipped. Expect exact menu wording to drift between controller versions since it isn't a first-class, stable feature.
• Because it's built from remote-access primitives, only one side can be the WireGuard "server" — plan which site holds the stable/reachable public IP before starting.
• The manual routing step is the one people skip: without it, the tunnel comes up (peer shows connected) but only the two gateway IPs can reach each other, not the LANs behind them.

IPsec

1. VPN → IPsec → Tunnels → Add P1 — set *Key Exchange* IKEv2, *Remote Gateway*, *Authentication* Mutual PSK, identifiers, and the phase 1 encryption list.
2. Then Show Phase 2 Entries → Add P2 — set *Mode* Tunnel IPv4, *Local Network*, *Remote Network*, and the phase 2 proposals.
3. Apply Changes, then add firewall rules on the IPsec interface tab to permit the tunnel traffic.
4. For route-based, set P2 *Mode* to Routed (VTI) and assign the VTI as an interface, then add static routes.
5. Verify: Status → IPsec, and Status → System Logs → IPsec for negotiation detail.

• Firewall rules on the IPsec tab are required — an established tunnel with no rules passes nothing inbound. This is the most common pfSense IPsec complaint.
• Outbound NAT in Automatic mode generally does the right thing for policy-based (tunnel mode) IPsec, but with Manual/Hybrid outbound NAT you must ensure no rule NATs the VPN traffic.
• Choose deliberately between Tunnel IPv4 (policy-based, easy interop with MikroTik/Cisco crypto maps) and Routed VTI (route-based, matches FortiGate/PAN-OS). Do not mix modes across the two ends.
• Status → System Logs → IPsec gives readable strongSwan output naming the mismatched proposal — the best built-in IPsec debugging of the six.
• Set the phase 1 and phase 2 lifetimes to match the far end; mismatched lifetimes cause a tunnel that works then drops every few hours.
• The right choice when the far end isn't pfSense — it's the one protocol every vendor on this site actually interoperates on.

WireGuard (recommended when both ends are pfSense)

1. Install the package if not already present: System → Package Manager → Available Packages → wireguard (built in on 2.7.0+).
2. On Site A: VPN → WireGuard → Tunnels → Add Tunnel — generate a key pair, set a listen port, and give the tunnel an address (e.g. 10.60.0.1/30).
3. On Site B: same, with its own key pair, the same listen port, and 10.60.0.2/30.
4. Exchange public keys between the two admins.
5. On Site A, add a peer for Site B: its public key, *Endpoint* = Site B's public IP:port, and *Allowed IPs* = Site B's tunnel address and its LAN subnet (e.g. 10.60.0.2/32, 192.168.99.0/24).
6. On Site B, mirror it: Site A's public key, endpoint, and *Allowed IPs* covering Site A's tunnel address and LAN.
7. Interfaces → Interface Assignments on both boxes: assign the WireGuard tunnel as a real interface — required before routing or firewall rules work.
8. Add firewall rules on the new WireGuard interface tab on both sides permitting the cross-site traffic.
9. Verify: Status → WireGuard shows a recent handshake on both ends.

• Far less to get wrong than IPsec — one tunnel, one peer per side, and Allowed IPs covers both the crypto scope and the route in one field, instead of separate phase 1/phase 2/firewall-rule/routing steps.
• The tunnel must be assigned as an interface before anything routes through it — adding the tunnel alone under VPN → WireGuard is the most common reason it looks configured but passes no traffic.
• Only interoperates with another real WireGuard endpoint (pfSense, MikroTik RouterOS 7, a Linux box, etc.) — it won't talk to a pure-IPsec vendor like FortiGate, PAN-OS, or SonicWall.

OpenVPN (peer-to-peer mode)

1. VPN → OpenVPN → Wizards, or configure manually: choose Peer to Peer (SSL/TLS) mode for certificate-based auth, or Peer to Peer (Shared Key) for the simplest possible two-site setup with no CA to manage.
2. Set the *Tunnel Network* — a small point-to-point subnet just for this link (e.g. 10.70.0.0/30) — and the *Remote Network(s)* — the far end's LAN — so pfSense adds the routes automatically.
3. One side is configured as the OpenVPN server (listens), the other as the client (initiates) — pick whichever side has the more stable/reachable public IP as the server.
4. For Shared Key mode, generate the key on one side and copy the exact same key file to the other. For SSL/TLS mode, build a small CA and issue a certificate per side instead.
5. Add firewall rules on the OpenVPN interface tab on both sides to permit the cross-site traffic.
6. Verify: Status → OpenVPN shows the tunnel as up, and Diagnostics → Routes shows the remote subnet routed via the tunnel.

• Shared Key mode is the fastest path to a working two-site tunnel — no certificate authority to build, just one key file copied to both ends. SSL/TLS mode is more setup but scales better if you might add a third site later.
• Unlike the remote-access OpenVPN server, this peer-to-peer mode is a genuine site-to-site link, not a client pool — don't confuse the two wizards.
• Slower and heavier than WireGuard for the same link, but has a longer track record and broader legacy compatibility if either box is on an older pfSense release without the WireGuard package.