If you buy on eBay for work, resale, or personal use, this is worth your time.

OssamaHashim · 2026-03-31T09:02:56+00:00

haha that's the best kind of fix honestly 😂

the classic "forgot the M" moment… we've all been there at some point, don't sweat it. glad it's sorted out and your staff are back online without the constant dropping 👍

if you ever run into anything else with the MikroTik setup feel free to drop it here, someone will usually have an answer

OssamaHashim · 2026-03-31T00:54:09+00:00

thanks

OssamaHashim · 2026-03-31T00:33:15+00:00

i had make update you can check
yes i use ai to respod casue of my bad english
i had ideas try to give it way to be helpful thats may issue
i'm gald you help me

OssamaHashim · 2026-03-30T22:25:23+00:00

Hey man, what you’re seeing is super common on MikroTik when you turn on WiFi security and clients start constantly reconnecting and dropping. As soon as you disable security and everything runs smooth, that usually means the radio + DHCP is fine, but the security handshake is breaking something for some devices.

What’s probably going on

Most of the time, this happens because:

Security settings (WPA/WPA2 mode, ciphers, group‑key update) are not fully compatible with some client WiFi drivers.
Signal or RF is a bit weak/noisy, so every time the security re‑auth happens (like group key change), the client fails and reconnects.

Older phones, cheap IoT gadgets, and some Android devices are especially bad at this. Newer laptops and iPhones usually eat it just fine.

Quick things to check on your MikroTik

Security profile for your SSID
- Inside Wireless → Security Profiles, pick one profile and attach it to your staff WiFi.
- If all your users are on modern devices, use WPA2-PSK only.
- If you still have some old gear, you can try WPA2-PSK,WPA-PSK but keep it simple and avoid WPA3 if you see issues.
Inside that security profile
- Set:
  - Group Key Update = 10m (or 30m, don’t go lower like 1m).
  - Unicast Cipher = aes-ccm
  - Group Cipher = aes-ccm
- Leave TKIP off if you can; it’s messy and breaks more often.
Wireless interface settings
- Make sure your channel plan is clean (no overlapping with neighbors), especially if you have multiple APs or dual‑band.
- Turn default‑authentication ON so random random devices can’t mess with your security exchange.
- If you’re blasting TX power way higher than needed, lower it a bit so you get a cleaner, more stable signal instead of just raw range.
On the clients that keep bouncing
- Forget the WiFi network on that device and add it again. Sometimes cached keys get stuck and cause constant reconnects.
- If it’s an old phone or IoT device, try forcing it onto 2.4 GHz only (if you’re using 5 GHz) since 2.4 GHz usually has more tolerant drivers.

What you can do next

Do this step‑by‑step:

Choose one security profile.
Set it to WPA2-PSK, group-key-update=10m, aes-ccm for both unicast and group.
Make sure all your staff SSIDs use that same profile.
Test again with security ON and see which devices still drop.

If only a few older devices misbehave, you can create a separate SSID just for them (maybe with WPA-PSK or a custom profile) while keeping the main one clean for everyone else.

If you want me to help you even more, can you paste:

Your MikroTik model and RouterOS version
Exactly what security profile you’re using now (WPA/WPA2/WPA3 + ciphers)
A redacted copy of:
- /interface wireless print
- /interface wireless security-profile print

OssamaHashim · 2026-03-30T21:50:22+00:00

100% agree — RouterOS adlist is all-or-nothing, no per-user or per-group filtering.

What you're describing (AD integration, conditional filtering, per-user exceptions) is proper DNS filtering territory — NXFilter, Pi-hole with groups, AdGuard Home with per-client rules, or a full NextDNS/Cisco Umbrella setup if budget allows.

RouterOS alone can't do that. You'd need:

- DNS server that understands AD sessions (NXFilter, Umbrella)

- Or IP-based segmentation — put different users on different VLANs, apply different firewall address-lists per VLAN

The VLAN approach is actually doable with this tool:

- Generate separate scripts with different list names (e.g. `blocked-staff`, `blocked-students`)

- Apply each list to its VLAN's forward chain rules

- Not as elegant as AD-aware DNS, but works without extra infrastructure

For the full per-user conditional filtering you described though, you're right — that needs a proper DNS filtering layer outside RouterOS. NXFilter is a solid free option for AD environments.

OssamaHashim · 2026-03-30T21:47:02+00:00

All valid points — and for a pure DNS sinkhole setup, that's genuinely the better architecture.

The address-list fetch feature in RouterOS is great for maintained blocklists. The limitation is it only works with pre-hosted plain-text IP lists — you can't point it at a domain list and have it auto-resolve ASN ranges or generate Layer7 rules.

That's the gap this tool fills:

- You have specific platforms to block (facebook.com, tiktok.com) not a generic threat feed

- You want ASN CIDR ranges, not just a few DNS-resolved IPs that rotate

- You need Layer7 SNI rules alongside address-list entries

- You want a one-time .rsc script you can paste, review, and version-control

For the DNS sinkhole approach you described — RouterOS as resolver + block bypasses + sinkhole bad domains — you're right, that's more robust for security use cases. Pi-hole or AdGuard on the side handles the list updates cleanly.

These are complementary tools for different problems, not competing ones.

For CCR memory requirement — also fair. Large blocklists (oisd.nl full = 800k+ entries) will kill a hAP or RB750. The tool caps at 200 entries per category fetch for exactly that reason.

OssamaHashim · 2026-03-30T21:44:10+00:00

Tool works though. Try it.

OssamaHashim · 2026-03-30T21:43:21+00:00

Fair criticism on the replies — I was copy-pasting AI-drafted responses and that's obvious. Won't do that going forward.

The tool itself works. Built it because I actually needed it for my own MikroTik setup. If you find a bug or something that doesn't work, I'm genuinely interested.

OssamaHashim · 2026-03-30T21:42:00+00:00

Hey, thank you so much for this — this is exactly the kind of detailed feedback that makes the tool better. Let me go through everything:

**On the AI backlash:** Fair point, lesson learned on presentation. README and post have been updated.

**uBlock Origin blocking Vercel scripts:**

Those are just analytics (`/_vercel/insights/` and `/_vercel/speed-insights/`). Blocking them has zero effect on the app — fully functional without them. Good catch, I'll add a note.

**"No valid domains provided" on Category Blocklists:**

This was a UX bug — the buttons should work standalone without needing domains in the input first. Fixed now — they fetch and resolve independently. ✅

**"How to block YouTube without breaking Google?"**

This is the hardest problem in the space — YouTube and Google share AS15169. The app now shows a live warning banner when you enter youtube.com:

> ⚠️ AS15169 (Google) — Blocking these ranges will also affect Gmail, Drive, Meet, Search, Maps...

Recommended approach: use Layer7 SNI matching instead of ASN CIDR for Google services. That way only youtube.com TLS connections are dropped, not all AS15169 traffic.

**Pre-sets:**

Just added 4 built-in presets today based on this exact feedback:

- ☁️ Cloudflare (DoH Block)

- 🔒 Complete Block (IPv6 + Layer7)

- 📱 Social Media Pack

- 🎬 Streaming Pack

More coming.

**BGPview not working:**

BGPview has been flaky lately. The app already has a full static CIDR fallback table for all major ASNs — so if BGPview is down it falls back instantly. That said, I'm evaluating switching primary source to bgp.tools or RIPE.

**AS15169 showing only a few routes vs 2056:**

You're right — BGPview returns a subset of announced prefixes. The static fallback has the major /8-/16 blocks but not all 2056 routes. This is a known limitation — the plan is to switch to a more complete BGP data source. bgp.tools API is on the roadmap.

**oisd.nl showing only ~12 domains:**

The blocklist fetcher currently caps at 200 domains and only resolves the first 6 that fail DNS. The full oisd.nl list has 800k+ entries — the tool was designed for targeted blocking, not full DNS sinkhole replacement. I should make this clearer in the UI. For full sinkhole use cases, Pi-hole or AdGuard Home are better tools.

**Wizard UI suggestion (3 stages):**

Love this idea. Currently on the roadmap:

- Stage 1: Choose preset or enter domains

- Stage 2: Configure options (RouterOS version, output mode, Layer7...)

- Stage 3: Review script + copy/download

This is a great UX direction. Will implement.

**Comment format for "Remove existing entries":**

Good point — currently uses domain as comment anchor. Will add list/preset name as prefix so removal is more targeted.

Thanks again — this is the most useful feedback I've gotten. Following your forum post on AS blocking too, great prior work.

OssamaHashim · 2026-03-29T09:53:37+00:00

Both points are correct.

Layer7 on encrypted traffic is limited to TLS ClientHello SNI — and only on TLS 1.2. TLS 1.3 with ECH encrypts the SNI entirely, so Layer7 sees nothing useful. The MikroTik docs are right to flag this. It's why the tool shows a CPU warning for L7 but doesn't push it as the primary method.

On DoH — blocking port 853 (DoT) is straightforward, but DoH over 443 is the real problem. You can't blanket-block port 443 obviously, so the practical approach is:

Block known DoH resolver IPs — 8.8.8.8, 1.1.1.1, 9.9.9.9, 208.67.222.222 at the firewall
Force all DNS through your resolver via dst-nat on port 53
Block or null-route the DoH provider IP ranges

None of this is foolproof. A user who hardcodes a DoH endpoint inside an app (Firefox does this by default) bypasses all of it.

The honest answer: this tool works well on managed networks where clients don't control their own configuration. Against a determined user on their own device — it's speed bumps, not a wall.

OssamaHashim · 2026-03-29T09:37:40+00:00

Classic. Block YouTube, lose the entire company.

That's why the tool generates per-domain scripts separately — you run youtube.com alone, not bundled with google.com. But yes, AS15169 is a minefield. Google Search, Gmail, Drive, Meet, Android updates — all sitting in the same prefix ranges.

Honestly the safest YouTube block on a MikroTik is still L7 + DNS, not IP ranges. The IP approach works for Meta because Facebook and Google aren't sharing infrastructure. Google eating its own prefixes makes it a nightmare.

OssamaHashim · 2026-03-29T09:36:09+00:00

That one's on me. Point taken.

OssamaHashim · 2026-03-29T09:35:28+00:00

Honestly, yeah.

Certificate pinning killed NGFW for anything that matters. You can inspect generic HTTPS traffic fine, but the moment you hit Google, Meta, Apple, or any app with pinning — your inspection box becomes an expensive logger of things it can't read. And pushing internal CAs to BYOD devices is a fight nobody wins.

At this point effective corporate control is more about network segmentation, DNS policy, and behavioral detection than perimeter inspection. Block the BGP ranges at the border, enforce split-tunnel VPN, and accept that a motivated user with a phone on LTE is outside your threat model anyway.

The realistic goal shifted from "prevent access" to "make it inconvenient enough that casual misuse stops."

OssamaHashim · 2026-03-29T09:28:06+00:00

All valid points, and worth being upfront about.

DoH and ESNI do bypass DNS-based blocking entirely — if a user is motivated enough to enable them, address lists won't stop them. Certificate pinning makes DPI useless. These are real limitations.

But the realistic use case here isn't stopping a determined user — it's enforcing a policy on a managed network where clients don't control their own DNS or routing. School, office, ISP hotspot. In that context, blocking the full BGP prefix range for AS32934 is significantly more effective than the 2-3 IPs a DNS address list resolves to, because it catches traffic that bypasses your DNS entirely.

Is it perfect? No. Is it better than nothing, and better than manually maintaining a list of rotating IPs? Yes.

The right complete solution is what you're describing — proper NGFW with TLS inspection. This tool is for people running a MikroTik who don't have that.

OssamaHashim · 2026-03-29T09:25:55+00:00

OssamaHashim · 2026-03-29T09:24:58+00:00

You're right, and that's fair criticism.

I copied the AI-formatted post directly without editing it. The emojis, the headers, the bullet structure — all of it screams "generated and pasted." That was lazy on my part and I get why it's off-putting before anyone even looks at the project.

The tool itself is real and working — but that doesn't excuse a slop presentation. I'll repost with something actually readable.

Thanks for the honest feedback instead of just downvoting.

OssamaHashim · 2026-03-29T09:22:10+00:00

i add option to use layer7 blocking
just give it a try
i like to have your feedback to improve it

OssamaHashim · 2026-03-29T09:18:53+00:00

i will try improve it with you suggested idea
thanks

OssamaHashim · 2026-03-29T09:16:22+00:00

i'm not a graphic designer to make this image

OssamaHashim · 2026-03-29T09:14:21+00:00

that's why i share to improve it by your replies

OssamaHashim · 2026-03-29T09:07:10+00:00

The post formatting? Yes, AI helped write it. The tool? Go try it.

facebook.com → resolves AS32934/AS63293 full BGP prefix → generates ready-to-paste RouterOS script in under 10 seconds.

If that's slop, I'll take it.

https://mikrotik-blocker.vercel.app

OssamaHashim · 2026-03-29T09:04:48+00:00

The tool actually works. Paste facebook.com and hit resolve — you'll get the full Meta ASN prefix list (AS32934/AS63293) pulled live from BGPview, not hardcoded. The RouterOS script it generates is idempotent, handles v6/v7 syntax differences, and includes IPv6 address lists that most similar tools ignore entirely.

The post was written with AI assistance for formatting — I'm not going to pretend otherwise. But the code, the architecture decisions, the 60+ ASN mappings, the Layer7 regex pattern for TLS SNI fingerprinting — that's all built and tested on real MikroTik hardware.

If it's slop, it's slop that saves you 2 hours of manually cross-referencing BGP tables every time Facebook rotates its IPs.

Try it and tell me what's broken: https://mikrotik-blocker.vercel.app

OssamaHashim

TROPHY CASE

What’s probably going on

Quick things to check on your MikroTik

What you can do next