MikroTik CAPsMAN Setup Guide for RouterOS 7: Controller, CAPs, and VLANs

Most of what makes a MikroTik CAPsMAN setup guide go wrong happens before the first command: people configure the legacy /caps-man controller for access points that run the new wifi driver, or the reverse, and then spend an evening wondering why the CAP never appears. This guide is for the RouterOS 7 wifi package, one controller, one to four CAPs, and an IoT VLAN, which is the shape of nearly every home and small-office deployment.

Which CAPsMAN you are actually setting up

RouterOS has two controllers that share a name and nothing else. The /interface/wifi/capsman menu manages radios driven by the wifi-qcom (Wi-Fi 6/6E) and wifi-qcom-ac (802.11ac, ARM CPU only) packages. The older /caps-man menu manages radios on the legacy wireless package. MikroTik’s WiFi CAPsMAN manual is blunt about it: “WiFi CAPsMAN can only control WiFi interfaces, and WiFi CAPs can join only WiFi CAPsMAN.”

So the first step is inventory: /system/package/print on every AP. wifi-qcom or wifi-qcom-ac means the new controller. wireless means legacy /caps-man, or a migration; the WiFi manual says an 802.11ac unit must uninstall wireless and install wifi-qcom-ac, which “is NOT compatible with any of our 802.11ac products which have a MIPS CPU” and leaves less free RAM. The wifi menu arrived in RouterOS 7.13 (before that, the separate wifiwave2 package). Anything still on v6 gets upgraded first.

The controller needs no radio of its own. An RB5009 or a hEX S with no Wi-Fi is a perfectly good CAPsMAN; the forum guide cited below runs an RB5009 controlling hAP ax3, hAP ax2 and cAP ax units on RouterOS 7.14.3.

Topology

ISP -> [ether1] RB5009 (router, CAPsMAN) [ether2..4: trunk, tagged 10/20/30/100]
            |                |                 |
        cAP ax #1        cAP ax #2        hAP ax3 (as CAP)
    ether1 = trunk    ether1 = trunk     ether1 = trunk
    mgmt on VLAN 100  mgmt on VLAN 100   mgmt on VLAN 100

Every CAP uplink is an 802.1Q trunk, the CAP’s management address lives on a VLAN interface over its bridge, and the controller listens only on its management VLAN interface, so an IoT client cannot reach the CAPsMAN service at all.

VLAN plan

VLAN	Name	CIDR	DHCP range	Gateway	Policy
10	Trusted	10.10.10.0/24	.100-.199	10.10.10.1	to WAN; to IoT on explicit ports only
20	Guest	10.10.20.0/24	.100-.199	10.10.20.1	WAN only; client-isolation on
30	IoT	10.10.30.0/24	.100-.199	10.10.30.1	WAN only; no initiation toward 10 or 100
100	Mgmt	10.10.100.0/24	.50-.99	10.10.100.1	CAPs and controller only

The bridge VLAN table on the RB5009 and on each CAP has to carry all four; the mechanics and the lockout traps are covered in VLAN filtering on RouterOS bridges. Build that table and confirm you can still reach each CAP on 10.10.100.x before touching CAPsMAN.

Controller configuration

The manual’s minimal example, verbatim, is four lines: a security profile, a configuration profile, a provisioning rule, and the enable.

/interface/wifi/security add authentication-types=wpa3-psk name=sec1 passphrase=HaveAg00dDay
/interface/wifi/configuration add country=Latvia name=5ghz security=sec1 ssid=CAPsMAN_5
/interface/wifi/provisioning add action=create-dynamic-enabled master-configuration=5ghz supported-bands=5ghz-n
/interface/wifi/capsman set ca-certificate=auto enabled=yes

For the plan above: one datapath per VLAN, one configuration per SSID, one provisioning rule per band, and interfaces=vlan100-mgmt on the capsman entry instead of the default all, as the forum guide does. A datapath carries bridge, vlan-id, client-isolation, interface-list, bridge-cost and bridge-horizon. The manual states that CAPs on wifi-qcom “can get ‘vlan-id’ via Datapath from CAPsMAN”: the CAP adds the resulting interface to its bridge untagged with that PVID. On wifi-qcom-ac CAPs that does not work; leave vlan-id out of the datapath and set pvid= on each wifi bridge port by hand, with the uplink tagged for the same VLAN.

Provisioning rules match on radio-mac, identity-regexp, common-name-regexp and supported-bands (2ghz-ax, 5ghz-ax, 6ghz-ax and the 802.11be variants). master-configuration is the first SSID on the radio; slave-configurations is the comma-separated list of additional SSIDs, which is where Guest and IoT go. action defaults to none; use create-dynamic-enabled. Put %I (CAP identity) in name-format so /interface/wifi/print stays readable past one CAP.

On forwarding mode: the manual documents traffic-processing=on-cap (local) and traffic-processing=on-capsman, but “CAPsMAN forwarding is only possible starting with 7.21beta2 version” and “is not supported by wifi-qcom-ac devices.” Plan on local forwarding: the CAP bridges wireless frames onto its own trunk and the controller never carries client data.

CAP configuration

Again from the manual:

/interface/wifi/cap/set enabled=yes
/interface/wifi/set wifi1,wifi2 configuration.manager=capsman-or-local

Add the discovery constraints so a CAP cannot be adopted by something on the wrong segment. The forum guide’s line is caps-man-addresses=192.168.100.1 certificate=request discovery-interfaces=vlan100-mgmt enabled=yes slaves-static=yes; substitute your controller address. caps-man-addresses defaults to the DNS name _capsman._tcp.lan, so a CAP with no static address still finds a controller if your DHCP hands out a lan domain and the SRV record resolves. lock-to-caps-man=yes pins the CAP to the certificate common name it first accepted, and on the controller require-peer-certificate=yes refuses CAPs that never requested one. Both default to no. Turn them on once every CAP has joined, not before.

upgrade-policy (none, require-same-version, suggest-same-upgrade) with package-path pointing at a folder of RouterOS packages lets the controller push firmware. CAPs are the boxes most likely to be forgotten when a RouterOS advisory lands, which is worth tracking through a feed like techsentinel.news. A profile edit on the controller is pushed to every provisioned interface the moment it is applied, so a passphrase typo drops every client on that SSID at once.

Discovery: how a CAP finds the manager

The manual lists Layer 2 discovery on discovery-interfaces, DHCP option 138, and DHCP option 15 (the domain, resolved as _capsman._tcp.<domain>). Option 138 is not a MikroTik invention: RFC 5417, “CAPWAP Access Controller DHCP Option”, defines DHCPv4 option 138 as a list of IPv4 controller addresses (and option 52 for DHCPv6). On the RB5009, /ip/dhcp-server/network set [find address=10.10.100.0/24] caps-manager=10.10.100.1 populates it for the management scope only. Layer 2 discovery does not cross VLANs, which is the point of the design: a CAP plugged into a Trusted access port will not see the controller, and that is correct behaviour, not a fault.

The management connection is DTLS. The legacy CAPsMAN manual says the same for /caps-man, notes that a CAP needs a Level 4 licence, and confirms that manager-forwarded client data is not encrypted, one more reason local forwarding is the default answer.

Things to test before you call it done

On the controller, /interface/wifi/capsman/remote-cap/print must list every CAP by identity, and /interface/wifi/print must show one provisioned interface per SSID per radio, with the %I names you chose. Then, from a laptop on each SSID:

ip -4 addr show
ping -c 5 10.10.30.1
ping -c 5 10.10.10.1
mtr -rwc 20 1.1.1.1
iperf3 -c 10.10.10.5 -t 30
dig @10.10.100.1 _capsman._tcp.lan SRV

An IoT client with an address in the right /24 that can also ping 10.10.10.1 has a firewall problem, not a CAPsMAN problem; see RouterOS firewall rules explained. A client with no address at all almost always means a wrong PVID on the CAP’s wifi interface or an uplink not tagged for that VLAN. Roaming stalls between CAPs were, in the forum thread, cured by enabling RSTP on the CAP bridges, not by anything in CAPsMAN.

Finally, set lock-to-caps-man=yes on the CAPs and require-peer-certificate=yes on the controller, then repeat the ping tests. A controller that will adopt a CAP from any VLAN is not finished.

Related across the network

• Best Homelab Firewall in 2026: OPNsense, pfSense, UniFi, MikroTik — firewallcompare.com
• pfSense Alternatives: 7 Platforms Compared for 2026 — firewallcompare.com
• Keyboard Wireless: Bluetooth vs 2.4GHz Latency Explained — kbdcompare.com
• Wireless vs Wired Mechanical Keyboards: What Matters — kbdcompare.com
• Best Wireless Mechanical Keyboard for Mac: Top Picks — keyboardranker.com