Field notes: common onboarding issues

Real-world fixes collected by the ISPMan support team while onboarding routers. Menu paths refer to WinBox on the MikroTik.

Connectivity & Setup

1. No Internet After Setup

Symptom: MikroTik is powered on, but clients have no internet.

Likely Causes:

Wrong WAN method configured (PPPoE vs DHCP client)
Incorrect PPPoE username or password
WAN interface not selected correctly
LAN ports not added to the bridge (br-ispman)
LAN and WAN accidentally placed in the same bridge

Fix:

Confirm which physical port receives internet from the ISP/ONT.
For PPPoE: go to PPP > Interfaces, open your PPPoE client, and verify username/password.
For DHCP WAN: go to IP > DHCP Client, confirm DHCP client is enabled on the WAN port only.
Go to Bridge > Ports and confirm all LAN ports are in the LAN bridge.
Keep WAN outside the LAN bridge.

2. Cannot Access Captive Portal Page

Likely Causes:

Hotspot server not bound to the correct bridge/interface
Missing or wrong NAT masquerade rule
Device connected to the wrong network/interface
Captive portal DNS redirect not working

Fix:

Go to IP > Hotspot and confirm the hotspot server is enabled on the intended LAN bridge.
Go to IP > Firewall > NAT and verify a masquerade rule exists with out-interface=<WAN>.
Confirm the test device got an IP from MikroTik DHCP (IP > DHCP Server > Leases).
Open a non-HTTPS site (for example neverssl.com) to trigger captive portal redirect.

3. Slow Speeds

Symptom: Speed test shows far below subscribed package.

Likely Causes:

WiFi interference or weak signal
Wrong queue profile or queue limit
Ethernet link negotiated at 10/100 Mbps instead of 1 Gbps
High CPU usage on the MikroTik

Fix:

Test first with a wired client directly on LAN.
Check interface link rates in Interfaces and replace bad cables.
Review active queues in Queues and confirm the customer profile is correct.
Check Tools > Profile or interface stats for CPU bottlenecks.

4. DNS Not Resolving

Symptom: Websites don’t load but ping to 8.8.8.8 works.

Likely Causes:

DNS servers not configured on router
ISP DNS servers down
Router is not allowing remote DNS requests from clients

Fix:

Go to IP > DNS and set DNS servers (for example 1.1.1.1 and 8.8.8.8).
Enable Allow Remote Requests in IP > DNS.
Confirm DHCP network settings hand out the MikroTik LAN IP as DNS server.

5. WiFi Connected But No Internet

Symptom: Device shows WiFi connected, internet doesn’t work.

Likely Causes:

DHCP server not running on LAN bridge
Firewall filter rules blocking forward traffic
Client isolation or AP bridge misconfiguration

Fix:

Go to IP > DHCP Server and confirm DHCP server is enabled on the LAN bridge.
Check IP > Firewall > Filter Rules and ensure forward chain allows LAN to WAN.
Confirm AP or wireless bridge mode is correct and not isolating clients.
Renew client DHCP lease and retest.

WireGuard / VPN

6. Scheduler Script Fails: WireGuard Interface Already Exists

Symptom: Logs show: Script Error: failure: already have interface with name wg-ispman-v4 (interface/wireguard/add; line 4) and scheduler task fails repeatedly.

Likely Causes:

Scheduler runs the same setup script repeatedly
Script always tries to add interface instead of checking if it already exists
Previous setup partially succeeded, then rerun created duplicates

Fix:

Go to System > Scheduler and temporarily disable the ispman scheduler entry.
Go to Interfaces > WireGuard and confirm whether wg-ispman-v4 already exists.
If interface exists, do not add it again; update existing interface/peer settings instead.
Remove duplicate/failed test entries, then run setup once manually.
Update the script logic to be idempotent: check for existing interface before add.

7. WireGuard Handshake Keeps Retrying

Symptom: Logs repeatedly show: Handshake for peer did not complete after 5 seconds, retrying.

Likely Causes:

Wrong endpoint IP/domain or port
WAN internet is unstable or down
UDP port blocked by upstream NAT/firewall
Peer keys (public/private or preshared key) mismatch
Router time is wrong, causing tunnel/auth issues

Fix:

Confirm WAN is up and stable first.
Verify peer endpoint address and port in WireGuard > Peers.
Recheck public/private keys and preshared key on both ends.
Ensure UDP port is allowed on all upstream firewalls/NAT devices.
Set correct time and NTP in System > SNTP Client.
Set Persistent Keepalive (for example, 25s) for NATed peers.

Authentication & Captive Portal

8. Radius Server Not Responding

Symptom: Captive portal authentication fails and Radius checks time out.

Likely Causes:

WireGuard tunnel to Radius network is down
Radius IP/secret/port mismatch
Routing to Radius subnet is missing
Unstable WAN causing intermittent tunnel drops

Fix:

Confirm WireGuard interface is running and has recent handshake.
Verify Radius settings in Radius menu (IP, secret, authentication port).
Check route to Radius server subnet in IP > Routes.
Test connectivity from MikroTik using Tools > Ping to Radius server IP.
Stabilize WAN link first if packet loss is high.

9. Captive Portal Shows “Webpage Not Available” (ERR_CONNECTION_RESET)

Symptom: User connects to hotspot SSID, but captive portal page fails with Webpage not available and net::ERR_CONNECTION_RESET.

Likely Causes:

Forward chain filter rule uses the wrong out-interface
Source subnet in forward rule does not match hotspot subnet (example: 10.111.0.0/16)
NAT masquerade rule is bound to the wrong WAN interface

Fix:

Go to IP > Firewall > Filter Rules and verify there is an accept rule in chain=forward.
Confirm src-address is the hotspot subnet (for example, 10.111.0.0/16).
Confirm out-interface is the actual interface bringing internet into MikroTik (WAN/PPPoE uplink).
Go to IP > Firewall > NAT and verify the masquerade rule uses the same correct WAN out-interface.
If either interface is wrong, update it and retest captive portal login.

Network Segmentation

10. MikroTik Broadcast Domain Conflict — PPPoE & Hotspot Client Mixing

Overview: Occurs when multiple MikroTik routers are connected to the same unmanaged switch, causing PPPoE and Hotspot clients to authenticate on the wrong router.

Affected Setup:

Device	Intended Role
RB3011	PPPoE Server
RB5009	PPPoE Server
L009	Hotspot Server

All 3 MikroTiks connected to one unmanaged switch → OLT → Clients

Root Cause:

When all routers share the same unmanaged switch, they exist in the same Layer 2 broadcast domain.

PPPoE clients send a PADI broadcast to discover a server
Hotspot clients send a DHCP broadcast to get an IP

Since all 3 routers receive every broadcast, whichever router replies first wins the client — regardless of any dashboard assignment. This causes:

PPPoE clients assigned to RB3011 ending up on L009
Hotspot clients assigned to L009 ending up on RB3011
Authentication failures because the billing system has no record of the client on that router

Important: This is not a billing system issue. The billing system assigns clients correctly — the problem happens at the network level before billing is even involved.

Symptoms:

Clients randomly failing to authenticate
PPPoE clients connecting to the wrong router
Hotspot login failing with: login failed: mac auth is already in progress
Dashboard showing clients online on the wrong device
Issue worsens when a new router is added to the same switch

Immediate Fix:

Step 1 — Disable and Remove Conflicting Services

If a router is not supposed to run a service, disable it and remove it entirely to stop it from responding to broadcasts it shouldn’t handle.

# On RB3011 (PPPoE only) — disable then remove the Hotspot server
/ip hotspot set [find] disabled=yes
/ip hotspot remove [find]

# On RB5009 (PPPoE only) — same, remove Hotspot server if it exists
/ip hotspot set [find] disabled=yes
/ip hotspot remove [find]

# On L009 (Hotspot only) — disable then remove the PPPoE server
/interface pppoe-server server set [find] disabled=yes
/interface pppoe-server server remove [find]

Just disabling the service is not enough in some RouterOS versions — remove it completely to guarantee it stops responding to broadcasts.

Step 2 — Clear Stale Sessions

Clients that were previously picked up by the wrong router will have stuck sessions. Clear them to force a fresh authentication.

# Run on affected routers (e.g. L009 for hotspot issues)
/ip hotspot active remove [find]
/ip hotspot cookie remove [find]
/ip hotspot host remove [find]

Step 3 — Separate PPPoE Servers with Service Names

If multiple routers run PPPoE on the same broadcast domain, assign unique service names so clients only respond to their designated router.

# On RB3011
/interface pppoe-server server set [find] service-name="ISP-3011"

# On RB5009
/interface pppoe-server server set [find] service-name="ISP-5009"

Then configure each client’s PPPoE dial to specify the correct service-name. The server will ignore PADI requests meant for a different service name.

Step 4 — Ask Affected Clients to Reconnect

After clearing sessions, instruct end-users to disconnect from WiFi / PPPoE, reconnect, and try the login page again.

Permanent Fix (Recommended):

Since the OLT is unmanaged and does not support VLANs, VLAN segmentation is not available at this layer. The recommended permanent fixes are:

Option A — Separate physical uplinks per router

Give each MikroTik its own dedicated port/uplink from the OLT so they are no longer in the same broadcast domain. This requires an OLT that supports per-port isolation or multiple PON ports.

Option B — Ask the ISP to replace the unmanaged OLT with a managed one

Advise the client to contact their ISP and request an upgrade to a managed OLT, or to add a managed switch (e.g. MikroTik CSS106, CRS series) between the OLT and the routers. Once in place, VLAN segmentation can be implemented:

VLAN	Router	Purpose
VLAN 10	RB3011	PPPoE clients
VLAN 20	RB5009	PPPoE clients
VLAN 30	L009	Hotspot clients

Option C — Consolidate to a single router per service type

If hardware constraints prevent network changes, reduce to one PPPoE router and one Hotspot router, and enforce service-name separation (Step 3) as the mitigation layer.

VLAN configs on the MikroTik side alone will not help here — the broadcast bleed happens upstream at the unmanaged OLT before packets ever reach the routers.

Fix Summary:

Step	Action	Impact
1	Disable conflicting services	Stops cross-router client pickup
2	Clear stale sessions	Fixes stuck authentications
3	Set unique PPPoE service names	Separates PPPoE servers
4	Ask clients to reconnect	Resolves client-side cache
Long term	Separate uplinks or managed OLT	Permanent clean fix

Related Errors:

login failed: mac auth is already in progress

Client has a stuck session from a previous wrong-router connection. Fix: clear hotspot active, cookies, and hosts.

Layer 2 / Spanning Tree

11. PPPoE Mass Disconnects — “peer is not responding”

Symptom: On a PPPoE server, hundreds of sessions drop in waves with terminating... - peer is not responding, recover, then drop again ~60–90 seconds later.

Likely Causes:

A Layer 2 loop in the access network that spanning tree can’t see (GPON OLTs usually don’t forward BPDUs)
The PPPoE server isn’t the spanning-tree root, so an access switch dictates the topology
one-session-per-host=no letting stale duplicate sessions pile up until the keepalive reaps them in batches
keepalive-timeout too aggressive (10s) for a GPON / point-to-multipoint network

Fix: See the full guide: PPPoE mass disconnects.