MikroTik · RouterOS v7

MikroTik IPsec Commands: Peers, Policies and SA Counters

Quick answer #

Check the IKE peer, then the IPsec policy, then the installed security associations. An established peer does not prove that the tested subnet pair is protected or that both directions carry data. Use selected SA fields so that the diagnostic output does not include encryption or authentication keys.

Scope: RouterOS v7 on RouterBOARD, CCR, CRS running RouterOS, or CHR where the relevant feature exists. Not SwOS. Output fields depend on release and hardware. RouterOS IPsec implementation; not WireGuard. Example focuses on policy-based site-to-site inspection. IKEv2 CHILD_SA and IKEv1 phase-two terminology differ.

Commands #

These commands do not reset peers or flush SAs. The selected SA output intentionally omits auth-key and enc-key. Keep peer identities and internal addressing private when sharing the remaining output.

Commands
RouterOS v7 · RouterOS v7 terminal; absolute menu paths

Read-only
/ip/ipsec/active-peers/print detail
Read-only
/ip/ipsec/policy/print detail
Read-only
/ip/ipsec/installed-sa/print proplist=spi,src-address,dst-address,state,current-bytes
Read-only
/ip/ipsec/statistics/print
Read-only
/ip/firewall/nat/print stats
Read-only
/ip/firewall/filter/print stats
Read-only
/log/print where topics~"ipsec"
Output may contain sensitive operational data.

Read the result #

The active-peer view answers whether the IKE relationship exists and which endpoints are involved. The policy view answers which source and destination selectors should be encrypted. The installed-SA view provides the actual data-protection associations and their counters. Keep these views separate rather than describing all three as merely tunnel up or down.

Use a short test between hosts that match the policy selectors. Record SA counters immediately before and after it. Directional growth is more informative than an old total: outbound growth without corresponding inbound activity gives a different next question from counters that do not move at all.

An installed SA contains cryptographic material in its detailed properties. Do not publish a full detailed dump as an example output or attach one to a public forum. The explicit property list above is designed to retain the useful state and byte evidence while avoiding those key fields.

Follow one subnet pair #

Write down the inner source and destination addresses as well as the outer peer addresses. Confirm that the test actually matches a policy, then compare the SA directions and counters. If there is no matching activity, examine routing, translation and the forwarding path that precede encryption. If only one direction grows, collect the corresponding evidence at the remote peer.

Use host-originated traffic for a host-to-host problem. A ping generated by the router may select a source address outside the protected selector and therefore test something else. Capture the source selection in the incident notes so that the next engineer can reproduce the result.

Pitfalls #

Do not flush all installed SAs or kill every active peer as an exploratory step. On a shared router, that can interrupt unrelated customers and erase the state you needed to compare.

IPsec traffic must be considered when reviewing FastTrack and NAT behaviour. A tunnel that works only while a diagnostic tool runs deserves an acceleration-path investigation. Keep proposed configuration corrections separate from this read-only reference and validate them against the actual peer design.

Sources

Documentation reviewed: 8 October 2026