MikroTik Deployment Checklist for WISP Operators
A deployment is successful only when the network is understood, the recovery path is ready, and one test subscriber passes the acceptance checks.
A safe RouterOS deployment is not the same thing as a script that imports without an error. A production change also needs a known topology, a reachable recovery path, a small test scope, and a rollback plan. Use this checklist before applying any PPPoE, Hotspot, NAT, or firewall configuration generated by this site.
Important: this checklist does not certify a configuration for your hardware or provider. It is a change-control aid. Keep a local console or out-of-band path available before changing WAN, firewall, routing, or management rules.
1. Record the current state
Take an export and record the facts that the generated script cannot know. The goal is to make the change reversible and to prevent an interface or subnet assumption from becoming an outage.
/export file=before-ispscripts-change
/system resource print
/interface print
/ip address print
/ip route print
/ip firewall export file=before-firewall-change- Write down the exact RouterOS version, device model, active WAN interface, subscriber interface, and management path.
- Save the current export somewhere outside the router. A backup stored only on the device is not a rollback plan after a failed reset.
- Record the current subscriber count, active sessions, RADIUS server address, and the expected gateway and pool ranges.
2. Validate topology and addressing
Before importing, draw the traffic path in one sentence: subscriber device → access interface or VLAN → MikroTik → RADIUS and upstream → internet. If the generated file does not match that path, stop and edit the inputs instead of compensating with unrelated firewall rules.
| Check | What to verify | Why it matters |
|---|---|---|
| WAN and subscriber side | They are different physical or logical interfaces and have the intended roles. | A reversed interface can expose management or strand subscribers. |
| Gateway and pool | The gateway is unused, the pool is inside the intended subnet, and it does not overlap another site. | Overlap creates intermittent routing and authentication failures. |
| MTU and MRU | PPPoE overhead is considered and the value is tested with the upstream path. | Incorrect MTU often looks like selective slowness or broken HTTPS. |
| CGNAT | The WAN address is checked; a provider-side private address is not treated as a public address. | Inbound management and port forwarding will not work through provider CGNAT. |
3. Test RADIUS before the subscriber rollout
Authentication and accounting are separate tests. A subscriber can log in successfully while the billing platform receives no usage data. Confirm the router is configured as an allowed RADIUS client, the shared secret is unique, and UDP ports 1812 and 1813 are permitted on the path.
- Use one test account with a known plan and an intentionally identifiable username.
- Connect one test subscriber only. Confirm an Access-Request and an Access-Accept in the RADIUS logs.
- Keep the session active long enough to observe an Interim-Update, then disconnect and confirm a Stop record.
- Compare the assigned address and rate limit with the attributes returned by the RADIUS server.
For a focused procedure, use the RADIUS troubleshooting guide rather than changing several variables at once.
4. Protect the management path
Do not apply a WAN hardening rule while connected through that same WAN path unless you have a recovery route. Prefer a dedicated management VLAN or a WireGuard path. Close unused services and allow administrative access only from known management sources.
/ip service print
/ip firewall filter print stats
/log print where topics~"firewall|ppp|radius"Review the counters after the change. A rule that looks correct but never matches may be attached to the wrong interface, chain, address list, or traffic direction.
5. Roll out in a controlled way
Start with one reachable router and one test subscriber. Observe login, address assignment, DNS resolution, NAT, browsing, accounting, and management access. Only then expand to a second device or a wider subscriber group. Record the exact time and configuration revision so a support report can be matched to logs.
6. Define rollback before you need it
A rollback should be an explicit action, not a guess. Keep the pre-change export, the generated file, and the tested command history together. If the change breaks reachability, use the local console or out-of-band path, restore the known-good configuration, and verify one test subscriber before reopening the wider service.
Minimum acceptance test
- One subscriber authenticates with the expected RADIUS profile.
- Accounting Start, Interim-Update, and Stop records appear.
- Subscriber traffic reaches the internet through the intended NAT rule.
- DNS, HTTPS, and the largest routine application flows work without unexplained fragmentation.
- Management remains reachable through the documented path, while unwanted WAN services remain closed.
Interactive change checklist
Tick each item only after you have evidence, not merely because the configuration was imported. The state is saved locally in this browser and is not sent to the site.
References
This checklist follows the concepts documented in the official RouterOS RADIUS documentation, PPP AAA documentation, RouterOS Firewall documentation, and RouterOS Log documentation. Review the version-specific manual before applying commands.