Running an ISP or a hotspot business on MikroTik touches a lot of moving parts at once: a RADIUS platform to actually bill and authenticate subscribers, the hotspot or PPPoE service on the router itself, more than one upstream link so one outage doesn't take you offline, and a firewall stack that has to keep the network safe without breaking any of it. Here's how the pieces fit together, and where our own platforms sit in that picture.
Two ways to run RADIUS: DMA RADIUS Manager vs. Nexvora RADIUS
DMA RADIUS Manager is the RADIUS billing and subscriber-management platform we've sold and deployed for years — PPPoE and hotspot authentication and accounting, plan/package management, and license-based pricing that scales with a single ISP's subscriber base. It's a proven, mature product for an ISP that wants one RADIUS server handling one network.
Nexvora RADIUS is our newer, multi-tenant platform, built for operators who need to run more than one brand or site from a single backend — subscriber authentication, billing, hotspot and PPPoE portals, and site connectivity over WireGuard, all tenant-isolated. If DMA is "one ISP, one deployment," Nexvora is built for "several networks, one operations team."
Both work as the RADIUS server your MikroTik routers point their PPPoE and hotspot services at — the choice comes down to whether you're running a single network or need multi-tenant separation from day one.
MikroTik Hotspot: the captive portal your RADIUS platform authenticates against
RouterOS's built-in /ip hotspot service is what actually shows a customer a login page, holds their traffic in a walled garden until they authenticate, and then releases it. On its own it can manage users locally, but that doesn't scale past a handful of accounts and gives you no billing. Point it at a RADIUS server instead — use-radius=yes under the hotspot profile — and DMA or Nexvora becomes the source of truth for who's allowed online, what plan they're on, and how long their session accounting runs, while the router just enforces what RADIUS tells it. The same RADIUS integration point also drives PPPoE authentication for wired subscribers, so one platform covers both connection types.
RouterOS 6 vs. RouterOS 7: what actually changed
Both versions are still in active use, and the choice matters for a production ISP router. RouterOS 7 brought a rebuilt routing engine with better BGP/OSPF handling, native WireGuard support (no more relying on third-party packages for site-to-site links — this is what Nexvora's connectivity layer builds on), container support for running extra services directly on the router, and improved hardware offload on newer ARM64 boards. It also changed some defaults and removed a few things long-time RouterOS admins relied on, like the "redirect to" option in the web proxy.
In practice: for new deployments on current-generation hardware (like the routers in our MikroTik router guide), we specify RouterOS 7. For older boards, or a production network where a specific v6 configuration has been stable for years, there's a real case for staying put until there's a concrete reason to move — an in-place major version upgrade on a live subscriber network is not something to do casually.
Load balancing & failover: Normal (PCC) vs. Recursive routing
These solve different problems, and a lot of networks need both. PCC (Per Connection Classifier) — the "normal" load-balancing method — hashes each new connection across your available uplinks so both links carry real traffic simultaneously, giving you combined throughput rather than one link sitting idle as a pure backup.
Recursive routing solves failover instead of balancing: rather than pointing a default route straight at your ISP's gateway, you route to a stable, distant address (a public resolver like 1.1.1.1 or 8.8.8.8) that's itself reachable only through a monitored route to that gateway. If the monitored route drops — meaning the actual upstream path is down, not just the local link — the recursive route disappears and traffic shifts to the next-distance route automatically. That distinction matters: checking the far end catches an upstream outage that a simple ping to your own gateway would miss. Most production dual-WAN MikroTik setups combine both — PCC for day-to-day balancing, recursive routes layered underneath for real failover when a link actually dies.
Firewall Filter: what's allowed to reach the router and the network
The /ip firewall filter chains — input, forward, and output — decide what traffic is allowed to reach the router itself versus what's allowed to pass through it to the rest of the network. The two mistakes we see most often on ISP edge routers: leaving input open to the WAN (so the router's own management services are reachable from the internet) instead of restricting management access to specific addresses or a VPN, and not dropping invalid connection-state traffic early, which wastes CPU running every malformed packet through the rest of the rule set.
Firewall NAT: source NAT vs. destination NAT
/ip firewall nat covers two different jobs that get confused for each other. Source NAT (usually a masquerade action on the WAN interface) is what lets an entire subscriber network share one or more public IPs to reach the internet — this is the rule every internet-sharing router needs. Destination NAT does the opposite: it takes traffic arriving from outside and redirects it inward, whether that's a port forward to an internal server or the automatic redirect that catches unauthenticated hotspot traffic and sends it to the login page. Getting srcnat and dstnat swapped, or ordering them wrong relative to your firewall filter rules, is a common source of "it works from inside but not outside" (or vice versa) support tickets.
Firewall Mangle: marking packets for routing and QoS
/ip firewall mangle doesn't block or allow anything by itself — it tags packets and connections with marks that other parts of RouterOS then act on. This is the mechanism that actually makes PCC load balancing work: mangle rules mark each new connection to a specific WAN, and routing rules then send marked traffic out that link. The same marking approach drives queue trees for QoS — marking VoIP or RADIUS-priority traffic so it gets guaranteed bandwidth ahead of ordinary browsing traffic during congestion. If load balancing or QoS "isn't working" on a MikroTik router, the mangle rules are almost always the first place to look.
Site blocking with a MikroTik router
ISPs usually need to block specific domains — a regulator-mandated blocklist, a known malicious-domain list, or a customer-requested content filter. The practical, current approach is DNS-based: static DNS entries or a maintained /ip dns adlist that resolves blocked domains to nothing, combined with a firewall filter rule that blocks direct queries to third-party DNS servers so subscribers can't simply bypass your resolver. Older approaches — the Layer7 protocol matcher, or transparent web-proxy redirects — still exist in RouterOS, but Layer7 inspects packet content, which doesn't work against encrypted HTTPS traffic, and the web proxy's transparent-redirect behavior changed in RouterOS 7. For a subscriber network today, DNS-level blocking is the method that actually holds up against modern HTTPS-everywhere traffic.
Where this actually comes together
None of these pieces work in isolation — a RADIUS platform without correctly configured hotspot/PPPoE profiles doesn't authenticate anyone, load balancing without the right mangle marks doesn't balance anything, and a firewall that's too loose or too strict breaks something either way. This is exactly the kind of network we design and support end-to-end, from the RADIUS backend down to the firewall rules on the edge router. If you're setting up a new ISP network, adding a second uplink, or inheriting a MikroTik configuration nobody fully understands anymore, get in touch and we'll take it from there.