Why MikroTik PCC Breaks HotSpot On Dual WAN
Tech GuruQuick Answer
Do not treat a few PCC exclusions as proof that MikroTik HotSpot supports arbitrary multi-table load balancing. MikroTik still documents a default-routing-table limitation for the HotSpot proxy and says PCC is not a valid method for that case. It separately describes a local-destination precedence repair. Start from a known-working portal path, then test routing, payments, session continuity and each WAN failure before accepting a design.
Evidence status: The current MikroTik HotSpot and PCC manuals were checked. They contain both the proxy limitation and narrower local-route guidance. No topology, rule set, packet trace, paid session or failover was tested; no copy-paste multi-WAN configuration is certified here.
What To Check
The PCC manual explicitly warns about HotSpot using the default table. The HotSpot manual also discusses mangle taking precedence over a local destination. Those statements describe different boundaries; fixing local delivery does not establish general multi-table proxy support.
Draw client-to-router portal traffic separately from authenticated internet traffic, router-originated requests, DNS and payment callbacks. A route that helps one of these flows can break another or return through the wrong NAT path.
Key Concepts In Plain Language
- PCC: a classifier that groups connections using selected address/port fields; it is not a complete failover or portal design.
- Local delivery: traffic addressed to the router itself, distinct from internet traffic forwarded through it.
- Return-path consistency: the reply path and NAT state needed for the observed connection to keep working.
Technical Checklist
- Map main/policy tables, PCC/connection marks, routing rules, local addresses, DNS, payment destinations, NAT and health checks.
- Respect the documented HotSpot default-table limitation; distinguish a local-delivery correction from complete multi-table support.
- Test new login, paid session, DNS/payment, each WAN failure, failback and return-path NAT from ordinary clients.
- Use flow/routing evidence and narrowly justified exceptions; do not add broad walled-garden or WAN bypass rules.
Interactive Operating Model
Use the planned checks below with this overview. No test result is implied by the diagram.
Before You Start: Safe Defaults
Preserve the working configuration, independent management, portal/session and transaction records. Map main/policy tables, rules, connection/routing marks, local addresses, DNS, NAT and gateway monitoring. Use permitted test vouchers/payments; do not disrupt real customer balances during routing experiments.
- Back up router, portal, voucher, payment, and session records before changing authentication or routing.
- Keep portal, DNS, payment, and management destinations reachable through the intended main path.
- Use test accounts and low-value test transactions with the payment provider's documented environment or process.
- Define a customer-credit, refund, and exception procedure before intentionally testing retries or link failure.
Go, Hold, Recover, Or Escalate
Keep or restore a supported known-working portal path when the proposed multi-table design is unexplained. Obtain release/topology-specific support before treating a local-route workaround as a complete PCC solution. Stop on unexpected pre-authentication access, payment mismatch or loss of management.
Planned Checks And Recovery
The current HotSpot manual points to /routing/settings and /routing/rule for ensuring HotSpot-server traffic reaches the local table before mangle, including HTTP 80 detection traffic. This is a vendor-linked diagnostic direction, not a ready-to-run rule for an unknown topology. The frozen page uses an older path; use the installed-release manual.
Step 1: Establish a working portal baseline
With the approved known-working routing configuration, capture DNS, portal redirect, login and a test entitlement. Record source/destination and observed table/egress. Keep the baseline configuration available independently of the router.
Step 2: Trace local and forwarded flows
Compare router-local destination handling with mangle marks and policy rules. Trace DNS, portal and payment paths separately, including return traffic and NAT. Do not infer the applied table from the name of a saved rule alone.
Step 3: Evaluate the bounded design
Resolve the vendor's support limitation before adding multi-table behavior. Test any approved local-delivery correction on an isolated canary. Verify unauthenticated clients cannot gain unrelated access through newly broadened exceptions.
Step 4: Exercise failure and restore
Test new and existing paid sessions during each WAN failure and failback. Record reconnects and payment/retry results rather than promising seamless sessions. Restore the known-working routing configuration if results diverge, while preserving newer entitlement and financial records.
Validation Checklist
- Local portal and forwarded customer traffic have distinct observed paths.
- The design acknowledges the documented HotSpot/PCC limitation rather than claiming exclusions remove it.
- DNS, payment and return NAT work through each approved failure/failback case.
- Unauthenticated access remains bounded and paid balances reconcile after recovery.
Troubleshooting
- Internet works but login page does not: Inspect router-local destination handling before changing general WAN routes.
- Login works but payment stalls: Trace the specific payment/DNS and callback paths, not only the portal page.
- New sessions work after failover, old ones fail: Compare connection/NAT state and changed egress; record reconnection instead of claiming transparent continuity.
Security, Privacy, Legal, And Recovery Boundaries
Security
Protect portal administration, payment secrets, router management, voucher generation, and session APIs with least privilege and auditable access.
Privacy
MAC addresses, phone identifiers, payment references, and connection history can identify customers; minimize collection and set a retention policy.
Legal
Comply with payment-provider terms, consumer-protection duties, tax and record requirements, and applicable privacy law; never test against another operator.
Recovery
Keep exportable transaction and voucher records, a router rollback, a manual credit path, and an exception queue that survives portal or webhook downtime.
Record any local exception, its owner, its expiration condition, and the evidence required to remove it.
What The Evidence Does Not Prove
The manuals do not validate a complete PisoWiFi/PCC topology. Their local-route guidance does not override the explicit proxy restriction. Exact rules, rule order, release behavior and provider callbacks need a controlled implementation test or vendor review.
Related TechGeeks Resources
- PisoWiFi Operations Notes: Start Here
- Networking Field Notes: Start Here
- 15 Router Security Settings to Audit Before Something Breaks
References
Next Action
Prove the baseline portal flow and trace one failing local-destination flow. Resolve the supported topology before expanding the load-balancing configuration.
