Real networks are mixed. The HQ has a Cisco ISR the last integrator left; the new branch got a MikroTik hEX because it costs a tenth as much. They still need one encrypted IPsec tunnel between them. This is the exact build — IKEv2 on both, the proposal values that must line up to the letter, and the one conceptual mismatch (route-based vs policy-based) that wastes everyone's first afternoon.
IPsec is a standard, so a Cisco router and a MikroTik will build a tunnel — the protocol doesn't care who made the boxes. What trips people is that the two vendors expose the same two-phase negotiation through completely different words, and default to different styles of tunnel. Cisco's modern default is route-based (a VTI you route over); MikroTik's default is policy-based (a policy that says "traffic matching src/dst gets encrypted"). Mix the two carelessly and Phase 1 comes up while traffic goes nowhere.
This build keeps it policy-based on both ends — the lowest common denominator that any firewall or router speaks, and the least surprising when the far side is a MikroTik. We use IKEv2, AES-256/SHA-256/DH-14 with PFS, a matched pair of traffic selectors (10.1.0.0/16 ↔ 10.2.0.0/16), and the NAT-exemption fix on both routers. Every value that must be identical is called out explicitly, because IPsec fails silently and unhelpfully when one of them isn't.
00
Before typing anything, hold the two vocabularies side by side. Everything after this is just filling these rows in with matching values.
| Concept | Cisco IOS |
|---|---|
| Phase 1 crypto (IKE) | crypto ikev2 proposal + policy |
| Peer + PSK | crypto ikev2 keyring + profile |
| Phase 2 crypto (ESP) | crypto ipsec transform-set |
| What to encrypt | crypto map ACL (policy) / route (VTI) |
| NAT exemption | deny line above permit in NAT ACL |
| See active tunnel | show crypto ikev2 sa |
| Concept | MikroTik RouterOS v7 |
|---|---|
| Phase 1 crypto (IKE) | /ip ipsec profile |
| Peer + PSK | /ip ipsec peer + /ip ipsec identity |
| Phase 2 crypto (ESP) | /ip ipsec proposal |
| What to encrypt | /ip ipsec policy (src/dst address) |
| NAT exemption | /ip firewall nat accept rule above masquerade |
| See active tunnel | /ip ipsec active-peers print |
01
We deliberately use a crypto map here rather than a VTI, because a policy-based peer is the least-surprising thing to hand a MikroTik. Same four crypto objects as the VTI post, terminated with a crypto map on the WAN interface.
# --- Phase 1: IKEv2 proposal / policy (must match MikroTik profile) --- R1(config)# crypto ikev2 proposal PROP-MT R1(config-ikev2-proposal)# encryption aes-cbc-256 R1(config-ikev2-proposal)# integrity sha256 R1(config-ikev2-proposal)# group 14 R1(config)# crypto ikev2 policy POL-MT R1(config-ikev2-policy)# proposal PROP-MT # --- Peer + pre-shared key (identity = branch public IP) --- R1(config)# crypto ikev2 keyring KR-MT R1(config-ikev2-keyring)# peer BRANCH R1(config-ikev2-keyring-peer)# address 198.51.100.2 R1(config-ikev2-keyring-peer)# pre-shared-key S3cr3t-Cross-Vendor! R1(config)# crypto ikev2 profile PROF-MT R1(config-ikev2-profile)# match identity remote address 198.51.100.2 255.255.255.255 R1(config-ikev2-profile)# authentication local pre-share R1(config-ikev2-profile)# authentication remote pre-share R1(config-ikev2-profile)# keyring local KR-MT # --- Phase 2: transform set + PFS (match MikroTik proposal) --- R1(config)# crypto ipsec transform-set TS-MT esp-aes 256 esp-sha256-hmac R1(cfg-crypto-trans)# mode tunnel # --- Interesting-traffic ACL: HQ LAN -> Branch LAN --- R1(config)# ip access-list extended VPN-TRAFFIC R1(config-ext-nacl)# permit ip 10.1.0.0 0.0.255.255 10.2.0.0 0.0.255.255 # --- Crypto map: tie peer + transform + PFS + ACL, apply to WAN --- R1(config)# crypto map CMAP-MT 10 ipsec-isakmp R1(config-crypto-map)# set peer 198.51.100.2 R1(config-crypto-map)# set ikev2-profile PROF-MT R1(config-crypto-map)# set transform-set TS-MT R1(config-crypto-map)# set pfs group14 R1(config-crypto-map)# match address VPN-TRAFFIC R1(config)# interface GigabitEthernet0/0 R1(config-if)# crypto map CMAP-MT
02
Same negotiation, RouterOS words. The profile is Phase 1, the proposal is Phase 2, the peer+identity carry the PSK, and the policy is the mirror of Cisco's interesting-traffic ACL. The values are copy-paste identical to HQ.
# --- Phase 1 profile: MUST match Cisco PROP-MT exactly --- /ip ipsec profile add name=PROF-CISCO enc-algorithm=aes-256 hash-algorithm=sha256 \ dh-group=modp2048 lifetime=8h # modp2048 == Cisco group 14 # --- Peer: the HQ public IP, IKEv2, using that profile --- /ip ipsec peer add name=HQ address=203.0.113.1/32 profile=PROF-CISCO exchange-mode=ike2 # --- Identity: the pre-shared key, char-for-char identical to Cisco --- /ip ipsec identity add peer=HQ auth-method=pre-shared-key secret="S3cr3t-Cross-Vendor!" # --- Phase 2 proposal: MUST match Cisco TS-MT + PFS group14 --- /ip ipsec proposal add name=PROP-CISCO enc-algorithms=aes-256-cbc auth-algorithms=sha256 \ pfs-group=modp2048 lifetime=1h # --- Policy: mirror of Cisco's ACL (Branch LAN -> HQ LAN) --- /ip ipsec policy add peer=HQ tunnel=yes proposal=PROP-CISCO \ src-address=10.2.0.0/16 dst-address=10.1.0.0/16
modp2048 = DH Group 14, and Say It Twice
MikroTik names Diffie-Hellman groups by bit-length (modp2048), Cisco by number (group 14) — they're the same group, but you have to translate. And there are two DH settings: the profile's dh-group (Phase 1) and the proposal's pfs-group (Phase 2 PFS). Cisco's set pfs group14 in the crypto map only sets the Phase-2 one — if you set PFS on one vendor and not the other, Phase 2 fails after Phase 1 succeeds, which looks baffling. Match both, or disable PFS on both.
03
Phase 1 is READY, both sides show the peer as connected, and not a single packet crosses. Nine times out of ten it's one of these three — and none of them show up as an obvious error.
If you built the Cisco end as a VTI (from the site-to-site post) but the MikroTik as a policy, the two disagree about how traffic enters the tunnel. Cisco's VTI wants to route; MikroTik's policy wants src/dst selectors. Keep both policy-based (as above), or both route-based (MikroTik: an IPIP/GRE interface with an IPsec policy in tunnel-mode bound to it). Don't cross them.
Cisco's ACL says 10.1.0.0/16 → 10.2.0.0/16; MikroTik's policy must say src 10.2.0.0/16 → dst 10.1.0.0/16 — the exact mirror, same masks. A /24 on one side and /16 on the other is a proposal mismatch and Phase 2 refuses. Cisco is stricter than most about selectors matching to the bit.
Each router already masquerades its LAN to the internet, and will happily NAT the VPN-bound traffic too — mangling it before encryption. You must exempt site-to-site traffic on both boxes.
# CISCO: deny (exempt) VPN traffic ABOVE the permit, in the NAT ACL R1(config)# ip access-list extended NAT-LIST R1(config-ext-nacl)# deny ip 10.1.0.0 0.0.255.255 10.2.0.0 0.0.255.255 R1(config-ext-nacl)# permit ip 10.1.0.0 0.0.255.255 any # MIKROTIK: an accept rule ABOVE masquerade for the same pair /ip firewall nat add chain=srcnat action=accept place-before=0 \ src-address=10.2.0.0/16 dst-address=10.1.0.0/16 add chain=srcnat action=masquerade out-interface=ether1 # WAN
On both vendors the exemption must sit above the masquerade/permit — first match wins. And if the tunnel was up and NATing before you fixed it, clear the stale state or you'll swear it's still broken: Cisco clear ip nat translation *, MikroTik the src-nat connections in /ip firewall connection. This is the same trap as the Cisco-to-Cisco build — it just has to be solved twice here.
04
Confirm Phase 1, then Phase 2 with climbing counters, from each vendor's perspective. The failure is always at one identifiable layer — check them in order.
R1# show crypto ikev2 sa # Phase 1 -> Status READY R1# show crypto ipsec sa | inc pkts|ident # encaps/decaps both climb R1# ping 10.2.0.1 source 10.1.0.1 # LAN-sourced, not the WAN IP
/ip ipsec active-peers print # state=established, uptime climbing /ip ipsec policy print stats # ph2-state=established, in/out bytes > 0 /ping 10.1.0.1 src-address=10.2.0.1 # installed-sa shows the actual keys/SPIs if you need to go deeper: /ip ipsec installed-sa print
| Symptom | Where to look |
|---|---|
| No Phase 1 / not established | Profile mismatch (enc/hash/DH) or PSK typo. MikroTik: /log print where topics~"ipsec". |
| Phase 1 up, no Phase 2 | Proposal/PFS mismatch, or selectors not exact mirrors (§03A/B). |
| Phase 2 up, encaps climbs, decaps 0 | Far side's return NAT/route — the other router is mangling or dropping. |
| SAs up, zero packets | NAT eating traffic (§03C) or no route/policy sending LAN traffic in. |
Cross-vendor tunnels are perfectly stable once matched, but every parameter is a place for the two configs to drift apart over time. Pick one crypto profile — AES-256 / SHA-256 / DH-14 / PFS-14 / IKEv2 — and reuse it on every tunnel in the estate regardless of vendor. Document the pairs. When a branch tunnel drops at 2am, "they all use the same numbers" is the difference between a five-minute fix and an afternoon of diffing two dialects.
Takeaways
modp2048=group 14. Get those and the rest is filling in a table.NOCTIS designs and documents cross-vendor VPN estates across Crete — Cisco HQ, MikroTik branches, Starlink backhaul — with one standard crypto profile, clean failover, and tunnels that survive the 2am phone call.
Book a Discovery Call →