Enhancement & Improvement Recommendations

[Phoenix-999]

Hi NasNet Team,
Firstly, thanks so much for the incredible work you’ve generously done to help your fellow Iranians have a chance to stay connected to the free world. Truly appreciated 🙏

I’m a bit of a noob with all this, but I had a few suggestions that might help enhance and improve the Neighbor-Link setup.

---

Routing Enhancements via CIDR Lists

Regarding the routing section in MikroTik, instead of having a long list of individual IPv4 addresses to route through the local ISP, what if you use a [CIDR] IP list instead?It’s much more efficient, easier to manage, and can also cover IPv6 addresses.
You can even set up a weekly auto-updater script to fetch the latest IP list automatically, which makes it more secure, efficient, and reliable.

👉 Source: https://www.iwik.org/ipcountry

IPv4: https://www.iwik.org/ipcountry/IR.cidr
IPv6: https://www.iwik.org/ipcountry/IR.ipv6

🛠 Example GeoIP Auto-Updater Script:

/system scheduler
add name=update_geoip interval=7d on-event="/tool fetch url=https://www.iwik.org/ipcountry/IR.cidr dst-path=IR.rsc; /import file-name=IR.rsc;"

---

DNS Setup (Encrypted DNS)

I noticed the current script is using traditional unencrypted DNS (Do53). Since there’s no DoH (DNS over HTTPS) or DoT (DNS over TLS) configured, DNS queries are vulnerable — they can be intercepted, logged, or spoofed.

Starting from RouterOS 7.6, MikroTik supports DoH natively, but there are some limitations , Only one global DoH server can be set (e.g., Cloudflare, No per-zone or split-routing DNS support, It doesn’t affect clients using their own DoH (like Chrome, Firefox, or Android)
While this is okay for basic encryption, it’s not ideal for advanced setups like Split tunneling, FRN, DOM, or full VPN routing.

Better Approach for Advanced Privacy to fully secure all DNS traffic (and prevent DNS leaks, especially over Starlink), it’s better to use a DoH resolver like dnscrypt-proxy or cloudflared directly on your VPS, and Run WireGuard or Xray on your VPS Forward all DNS queries through the VPN tunnel MikroTik or your client devices send DNS → through VPN → VPS encrypts and forwards them via DoH to Cloudflare, Google, or another secure DNS provider.

Benefits of This Setup would be No DNS leaks — even over Starlink or public networks , All DNS traffic is encrypted end-to-end, Your DNS queries stay hidden from Starlink, ISPs, governments, or any local snoopers, Zone-level separation and future-proof DNS control.

---

Recommended Hybrid Setup (Best of Both Worlds)

Your current setup is already really solid, WireGuard, mangle rules, and IP-based segmentation are doing a great job at keeping things private and under control. But I’ve been thinking… we could take this a step further and really lock things down in a way that’s basically bulletproof.
The Problem

Even with those geo IP CIDR lists for Iran, China, etc., there’s still a risk: some domains might NOT be covered by the IP ranges. They can slip through unnoticed, and if any of that traffic goes through Starlink, there’s a chance of getting flagged or detected, especially with how aggressive some detection systems are now.

Sure, the VPN tunnel hides the real Starlink IP, but what happens if the tunnel drops or if DNS requests leak outside the tunnel? That’s where the real exposure happens.

I’ve been thinking, what if we take the current setup and push it even further with a more advanced, layered approach? Something that cleanly separates local and international traffic, locks down DNS leaks, and keeps everything airtight, especially for privacy and anti-censorship.

Here’s what the full setup could look like:

🔧 VPS Side (Privacy Core)

A VPS that supports both IPv4 and IPv6
Install Xray-core using:
vless + reality + xtls-rprx-vision
Enable DoH DNS (e.g. Cloudflare’s https://1.1.1.1/dns-query)
Use GeoIP + GeoSite routing to handle domestic vs. international domains
Enable IPv6 + uTLS fingerprinting to mimic real browser behavior
Also run a WireGuard server on the same VPS for MikroTik to connect to

📡 MikroTik Setup (Dual-WAN Routing)

ether1 = Starlink
ether2 = Local ISP
Enable IPv6 if it’s not already on
Create separate routing tables for each ISP (Starlink and Local)
Apply GeoIP blocklists (IR, CN, RU, etc.) to make sure their traffic never goes over Starlink
Use mangle rules to tag and route traffic cleanly
All international traffic → tunneled through the VPS using WireGuard

🛡 Firewall & Safety Nets

Add a kill switch: If the VPN tunnel drops, block all Starlink traffic
Prevent leaks: .ir, .cn, .ru traffic is always routed locally, never via Starlink
Block all DNS requests outside the tunnel
Enforce DoH/DoT only (completely drop any port 53 traffic to prevent leaks)

🔁 NAT Rules

Enable masquerade to make sure everything routes correctly
Keep logs minimal for privacy and performance

---

I apologize if my message was too long or if some parts didn’t make total sense. I’m no expert (far from it), but I’m diving into all of this because, well… necessity breeds motivation, right? With the current situation in the country, I have a strong feeling things are only going to get worse when it comes to internet freedom. People are being squeezed out of any real choice and sooner or later, they’ll be forced to rely on whatever works, even if it’s risky. Right now, like it or not, Starlink might be the most reliable option left — even with all the danger and red flags around it.

Looking forward to hearing your thoughts
and hey, thanks in advance

[Phoenix-999]

Domain-Based Routing with MikroTik (Even Without Native Domain Support)

So here’s the deal:

MikroTik routers are great in many ways, but there's one big limitation: they don’t support domain name matching in firewall or routing rules. That becomes a real issue when you want to route or block traffic based on domain names like aparat.com, blogfa.com, tebyan.net, Sanjesh.org, etc. especially when those services don’t use .ir domains and rely on dynamic or globally distributed IPs.

That said, there’s a potential workaround worth considering. The Idea (Not Fully Tested Yet, But Looks Promising)
We can work around this limitation by tagging domain traffic with a Fake IP using dnsmasq running on a VPS.
This lets MikroTik recognize and act on traffic associated with specific domains, even though it doesn’t support domain-level rules directly.

How the Setup Would Work

• Set up dnsmasq on a VPS

On the VPS, configure dnsmasq to respond to selected domains (like Iranian services) with a predefined fake IP address
(eg. 192.0.2.123)

Chosen from the 192.0.2.0/24 TEST-NET range
Silent, unroutable, valid format
Will not leak, crash apps, or create suspicious activity
You can choose any from the set: 192.0.2.1 - 192.0.2.254

address=/<domain>/<fake_ip>

example of each entry points to a fake IP:

> address=/digikala.com/192.0.2.123
> address=/aparat.net/192.0.2.123
> address=/bankmellat.ir/192.0.2.123

With over 130,000 domain entries — covering both .ir and non-.ir Iranian-related domains — manually editing or managing each one is simply not feasible. I've already compiled and prepared the complete list, which you’re welcome to review and use. It's the most accurate and up-to-date version available to date.

iran-domains-dnsmasq.xlsx

iran-domains.txt

NEXT

• Force all DNS requests through the VPS

On the MikroTik router, redirect all DNS queries from clients to the VPS. This ensures all lookups are handled by our controlled resolver.

• Tag target domains with a Fake IP

The VPS will only return the fake IP for the domains we want to monitor or route specially. All other DNS requests resolve as usual.

• MikroTik matches the fake IP

When traffic is directed to the fake IP, MikroTik can identify it as domain-based traffic from the controlled list.

• Apply routing rules, MikroTik can then:

• Route traffic to the fake IP via the local ISP interface (e.g., ether2)
• Block this traffic from using Starlink or VPN interfaces

example of MikroTik Config

/ip firewall address-list
add list=IR-DOMAIN-FAKE address=73.82.65.78 comment="Tagged Iranian Domains"

example of Mangle Rule

/ip firewall mangle
add chain=prerouting dst-address-list=IR-DOMAIN-FAKE \
action=mark-routing new-routing-mark=to-DOM passthrough=no

example of Drop if Misrouted

/ip firewall filter
add chain=forward dst-address-list=IR-DOMAIN-FAKE out-interface-list=FRN-WAN action=drop comment="BLOCK .IR to Starlink"
add chain=forward dst-address-list=IR-DOMAIN-FAKE out-interface-list=VPN-LAN action=drop comment="BLOCK .IR to VPN"

Automate Domain list Updates

To top it all off, we can automate the updates to the domain list by hosting the iran-domains-dnsmasq.txt file on a public platform—such as the GitHub Pages of nasnet-community.

From there, MikroTik can be configured to fetch and import the file regularly, ensuring the latest domain data is always in use. The update process can be scheduled to run weekly or monthly, minimizing manual maintenance while keeping the system current and reliable.

---

This approach ensures that traffic to Iranian-related services is always routed through the local ISP connection (such as ether2), even when those services do not use .ir domains and even in cases where traditional IP-based routing using CIDR blocks fails, is incomplete, or certain domains are not covered in the IP list.

In practice, many Iranian services are hosted under generic top-level domains like .com, .net, or .org, and their infrastructure may rely on global content delivery networks (CDNs) or cloud providers. These services often change IP addresses dynamically, making it difficult to maintain an accurate and up-to-date list of CIDR blocks. As a result, relying on IP-based rules alone can lead to traffic being unintentionally routed through unapproved connections, such as Starlink or VPN tunnels.

It’s a creative solution to a common limitation and could be very useful in the right scenarios.

---

P.S. This article is the result of independent research and experimentation, and it’s shared in the hope that it helps make the setup process a bit smoother. I've also included a PDF that may shed more light on this topic and provide additional clarity where needed.

Domain-Based Routing with MikroTik (Even Without Native Domain Support).pdf

✌🏾

[Phoenix-999]

Below is an optimized dnsmasq configuration example designed for maximum security, privacy, and reliability. This setup prioritizes fast upload and download speeds, minimizes latency, jitter, and ping times, and ensures a consistently stable connection. It’s also hardened against DNS leaks and supports encrypted DNS queries, making it ideal for performance-focused yet privacy-conscious environments.

✅ dnsmasq.conf — Advanced DNS Performance & Security

#=============================================================#
# ✅ dnsmasq.conf — Advanced DNS Setup for Starlink & VPN    #
#=============================================================#
#
# 🧠 PURPOSE:
# This configuration is built for environments using split-routing
# with Starlink (global access), a secure VPN tunnel (WireGuard),
# and a local ISP (Iran-based traffic).
#
# 🎯 GOALS:
# - Maximize DNS speed and reliability
# - Route all DNS queries through secure DoH
# - Completely block access to >130,000 Iranian domains using fake IP
# - Ensure zero DNS leaks (IPv4/IPv6)
# - Improve caching, reduce latency, and maintain stealth
#
# 📦 DEPLOYMENT CONTEXT:
# - MikroTik router (split routing)
# - VPS with WireGuard tunnel
# - DoH proxy (e.g. dnscrypt-proxy, cloudflared)
# - `dnsmasq` running locally (on router, VPS, or LAN server)
#
#=============================================================#


#=============================================================#
# 🔐 CRITICAL DNS LEAK PROTECTION & SECURITY HARDENING        #
#=============================================================#

no-resolv                         # Do NOT read system /etc/resolv.conf (prevent OS DNS leaks)
server=127.0.2.1#53               # Primary DoH proxy (dnscrypt-proxy, listening on port 53)
server=127.0.0.1#5053             # Secondary DoH proxy (cloudflared or other DoH fallback)
strict-order                      # Use DNS servers in the listed order (primary > fallback)
bogus-priv                        # Block private IP replies (avoids DNS rebinding)
stop-dns-rebind                   # Extra protection against DNS rebinding attacks
domain-needed                     # Block incomplete hostnames (forces fully-qualified domains)
filter-A                          # Block all AAAA (IPv6) responses for stealth
bogus-nxdomain=::                 # Return fake IPv6 result for blocked domains

#=============================================================#
# 🚫 FAKE IP RESPONSE FOR BLOCKED DOMAINS (IRAN DOMAINS)      #
#=============================================================#

bogus-nxdomain=192.0.2.123        # Send TEST-NET (safe) IP to all Iranian domains
                                  # Prevents leaks, app crashes, and false DNS routing
                                  # Use with large domain rule list in dnsmasq.d/

#=============================================================#
# 🚀 PERFORMANCE OPTIMIZATION & SPEED                         #
#=============================================================#

cache-size=20000                 # Large cache for fast repeat lookups
min-cache-ttl=600                # Minimum time to keep cached results (10 min)
max-cache-ttl=86400              # Maximum time to cache (24 hours)
neg-ttl=60                       # Cache failed lookups (NXDOMAIN) for 60s
dns-forward-max=1000            # Allow high concurrency on upstream DNS queries
local-ttl=3600                  # TTL for locally-resolved entries
no-poll                         # Don’t monitor /etc/hosts file (lower CPU load)
dns-loop-detect                 # Prevent endless DNS forwarding loops
query-port=0                    # Use fixed port to avoid issues with DoH proxies

#=============================================================#
# 🧱 LOCAL INTERFACE BINDING & ACCESS CONTROL                 #
#=============================================================#

interface=lo                     # Only bind to loopback
listen-address=127.0.0.1         # Accept DNS requests only from localhost
bind-interfaces                  # Do not bind to all interfaces (secure against LAN misuse)

#=============================================================#
# 🌐 LAN-SPECIFIC DOMAIN CONFIGURATION                        #
#=============================================================#

local=/myhome.lan/               # Optional: define a local LAN domain for internal use

#=============================================================#
# 📓 HOST OVERRIDES & STATIC ENTRIES                         #
#=============================================================#

expand-hosts                     # Expand short names using local domain
addn-hosts=/etc/hosts            # Load static hosts from standard file

#=============================================================#
# 📂 EXTERNAL DOMAIN RULESETS (IRANIAN DOMAINS ETC)          #
#=============================================================#

conf-dir=/etc/dnsmasq.d/         # Load all additional domain-based blocking configs here
                                 # Example: iran_domains_dnsmasq_192.0.2.123.conf

#=============================================================#
# 📈 LOGGING FOR DEBUGGING (REMOVE FOR STEALTH MODE)         #
#=============================================================#

log-queries                      # Log all DNS requests (optional)
log-facility=/var/log/dnsmasq.log  # Path to log file (disable in stealth mode)

#=============================================================#
# ✅ END — Fully Hardened, Optimized for High-Security DNS   #
#=============================================================#

[Phoenix-999]

Below is an optimized WireGuard configuration example, designed to deliver maximum security, privacy, and performance. It ensures fast speeds, low latency, DNS leak prevention, and seamless compatibility with MikroTik routers, dnsmasq, and dnscrypt-proxy

✅ wg0.conf — Final WireGuard Client Configuration

#===============================================================================#
# 🔐 WireGuard Client Configuration — Starlink + MikroTik + DoH + Stealth VPN #
#===============================================================================#
# PURPOSE:
# This configuration delivers:
# - Military-grade encryption with optional PreSharedKey (PSK)
# - End-to-end DNS leak protection via local DoH resolver (dnscrypt-proxy/dnsmasq)
# - Full IPv4 + IPv6 tunneling for international traffic
# - Seamless MikroTik integration for .ir traffic bypass
# - Optimized MTU for Starlink + low latency, minimal jitter
# - TCP Fast Open for reduced handshake time and connection reuse
# - Clean split routing with optional policy control

# SUITABLE FOR:
# - Clients using MikroTik dual-WAN setups (local ISP + Starlink)
# - Starlink routing international traffic via VPS
# - Local traffic (.ir and Iran-based domains) staying on Iranian ISP
#===============================================================================#


#-----------------------------------------------------------------------#
# [Interface] — Local WireGuard Client Settings                        #
#-----------------------------------------------------------------------#
[Interface]
PrivateKey = YOUR_CLIENT_PRIVATE_KEY            # Replace with your private key
Address = 10.77.0.2/32                           # Internal tunnel IP
DNS = 127.0.0.1                                  # Use local dnscrypt-proxy/dnsmasq for DoH

# Optional advanced routing control (uncomment if using routing policy)
# FwMark = 0xca6c                                 # Only if MikroTik/router uses fwmark

#-----------------------------------------------------------------------#
# Performance Optimization & Security Hardening                        #
#-----------------------------------------------------------------------#
MTU = 1412                                       # Optimized for Starlink and WireGuard
Table = auto                                     # Use system-managed routing table
PreUp = sysctl -w net.ipv4.tcp_fastopen=3       # Enable TCP Fast Open (faster TLS/DNS)
PostUp = ip link set mtu 1412 dev %i             # Ensure tunnel MTU is correctly applied
PersistentKeepalive = 25                        # Keeps NAT mapping alive through idle periods

#-----------------------------------------------------------------------#
# [Peer] — Remote WireGuard VPS Endpoint                               #
#-----------------------------------------------------------------------#
[Peer]
PublicKey = YOUR_SERVER_PUBLIC_KEY              # Replace with your server’s public key
PresharedKey = YOUR_PRESHARED_KEY               # Optional, adds extra encryption (recommended)
Endpoint = your.vps.ip.or.domain:51820          # Replace with your VPS IP/domain and port

# Full tunnel for both IPv4 and IPv6:
AllowedIPs = 0.0.0.0/0, ::/0

# If using MikroTik to route .ir traffic locally:
# Replace AllowedIPs with this:
# AllowedIPs = 0.0.0.0/1, 128.0.0.0/1, ::/0

#-----------------------------------------------------------------------#
# MikroTik Split-Tunnel Strategy (For .IR Safety & Routing Control)    #
#-----------------------------------------------------------------------#
# ✔️ Block .ir domains using dnsmasq sinkhole (192.0.2.123 or similar)
# ✔️ Add MikroTik mangle rules to detect destination IPs in Iran ranges
# ✔️ Mark and route Iranian traffic to local ISP (not VPN)
# ✔️ Let international traffic pass through WireGuard → VPS → Internet
#
# MikroTik handles dynamic routing:
# - GeoIP lists block Iranian IPs (IPv4 & IPv6)
# - Sinkholed domains (.ir + Iranian .com/.org) resolved to fake IPs
# - MikroTik blocks these fake IPs from entering the tunnel
#
# Important: This prevents Starlink exposure to Iran-owned domains

#-----------------------------------------------------------------------#
# End of Configuration                                                 #
#-----------------------------------------------------------------------#

#===========================================================================#
# ✅ END — Prioritized for Starlink + VPN + DoH + MikroTik Split Routing  #
#===========================================================================#

[Cacti5]

First, my apologies for the delayed reply.

The last release took far longer than expected to test; we were short on volunteers and had to do a lot of manual work.
And also, thank you so much for these wonderful suggestions, I'm glad to see them.

1- Routing Enhancements via CIDR Lists

• We already use a maintained CIDR IP list that covers most domestic, sensitive services (banks, VODs, government sites, etc.).
• weekly auto-updater is good idea we have some work around that but we are worried about security of our users this type of works is highly sensetive I mean this code is running on user router lets say we have a list of ips that gonna be replaced in command that could be easily escaped and run something else we are trying diffrent approaches when we make sure it's most secure way we are gonna release that

2- DNS Setup (Encrypted DNS)
First, review how NasNet Connect DNS works.
NasNet Connect currently creates four isolated networks (split VPN: foreign vs. domestic).
For each network, we have a bridge and also a DNS server that's totally separated from each other.

When a user wants to resolve a domain, the request comes to the router. The router changes the destination of that request and then returns the response based on the DNS server we set. With this approach, we maintain a DNS leak-proof solution.

But with this approach, we don't have features like DNS caching, ad blocking, or DNS over HTTPS.

If we want to use the router OS DNS server, we have to mangle the traffic that comes from each network, then try to use a proper DNS server for that. Like we could use DNS over HTTPS for the domestic network, but we have to make sure we don't have any DNS leaks for each network.

For achieving this goal, we have to use the VRF feature on the RouterOS. So we have to change our entire setup. In the last update, we didn't have much time to do that, but this is our priority for the next version.

I love that Cloudflare DNS Proxy idea. It's nice to use a DNS proxy, but NasNet Connect is for users who don't have any technical background. To achieve this goal, we have to keep things simple:

• Handle everything on the routers
• Make sure it's gonna run smoothly on every Mikrotik router
  Like, if in the next version we want to use routers like HAP AC2 or HAP AC3. It's just for example because AC-2 and AC-3 don't have enough resources for handling most of the NasNet Connect applications or even a base 500 mb/s speed.

3- What if our VPN client fails?
Okay. In the third section of your first message, I see you recommend a setup. First, let's say what if our VPN client fails to connect to the server? Like the Starlink situation in Tehran. There are so many ping drops or disconnections. It's kind of exhausting.
In this situation, when the VPN client fails to connect, all of the routes that go to the VPN client are going to fail. That includes the DNS request from a split network. So even if users try to see a website in the domestic network, they can't do that because the DNS request is not resolving. Even if we have connected a domestic WAN.

And also, if any of our networks or routes are going to fail, there will be no leakage at all. Cuz it's not like the router is gonna decide if this route is going to fail, I'm gonna choose another route. Everything is gonna be handled by our decision.

And also for setup, I love the idea of having two networks:

• One for failover
• One for the main usage
  But we have a problem:
• I don't like the idea of having a domestic server; it's going to cost so much money,
• It's not trustworthy
• I don't like the idea of giving my data to a datacenter that knows what this server is using it for. They might steal my data or other things.

Let's say we have another setup. On the MikroTik RouterOS, we could use Docker containers.
So we could run that X-Ray core on the ROS docker container.
And we have a route to that container. That we are using that as a failover for our Foreign Route.
In this setup, we don't have to use another domestic server for routing our traffic or anything else. And it's much, much cheaper.

I'm not even recommending using Starlink as a VPN server for most of our users because it is too expensive for users, as they have to pay the domestic link and the mobile phone internet bills. It's not really cheap for day-to-day use. And also, most of our users don't have a domestic link with high upload bandwidth.

-Domain-Based Routing with MikroTik (Even Without Native Domain Support)
First, RouterOS does support domain name matching in firewall or routing rules.
We could use this in two ways:

• Add our domain to an address list. Then, the address list tries to resolve that domain, and we could use that IP. If the domain in our address list IP is found, the router always tries to use that IP for that domain.
• In the firewall rules, mangle or RAW sections, we could use fields like content or TLS host. With that, we could use the domain.
• And also RouterOS supports Layer 7 protocols. But we have to make sure it's not going to use all of our resources because it's a really resource-intensive operation.
  Once again, I hate Domestic VPS. We could use DNSmasq on the ROS using Docker.

Always remember something. Most of the IR services are going to use worldwide services like Cloudflare, CloudFront or any other CDN. We really can't include those IPs for the Domestic Address list or other things because it's going to break the configuration.

Let's not make it too difficult to handle these kinds of things. I mean, when we talk about this, we only do it for the convenience of our users so they don't have to switch VPNs or other things when we are services like banks, VODs, government websites.
And even if we could do that, it's not really beneficial 'cause most of our users are using unlimited bandwidth and unlimited traffic for their services. So, it's a better approach to use the foreign link traffic for most of the usage, and to use domestic traffic, which is really expensive.

Oh my god, we have so many ideas, we have so many cool things we could do, but we don't have enough maintainers and developers for this project. If I want to tell you at the glamps what we are going to do on the next updates:

• We are going to move all the things we have to a Docker setup
• It's going to be like your typical modem that has a settings panel.
• On that panel, you could change every single setting you could find on the NasNet Connect.
• After that, we establish a basic setup. We could add many sorts of things, like the DNS servers are separated from the RouterOS, so we could use anything like DNSmasq, DNSproxy or things like AdGuard Home, etc.
• Even we could run the Xray core, Sing Box core, anything you say, and we have a panel that we could manage that proxy.
• And use those proxies for handling the failover route for our Foreign route.
  Everything you mentioned on these issues could be solved by this setup, and I mean solve, not hack.

[Phoenix-999]

@Cacti5

Hey my friend, thanks so much for the thoughtful reply 🙏🏽
Totally get how hectic things must be on your end, so no worries at all. I’m a patient guy, and always happy to hear from you, no matter how long it takes.

I read through your message line by line, just wanted to make sure I understood everything before replying. Hopefully this one hits the mark. I’ll try to keep it a bit shorter this time... but yeah, no promises 😅

---

About the VPS Idea

So yeah, after thinking it through, I’m completely with you. I was originally toying with the idea of adding a second foreign VPS for more flexibility or security, but honestly, it's probably not worth it.
It adds extra cost, extra complexity, and a lot of moving parts for very little gain.
One of those “sounds cool in theory, turns messy in real life” kind of ideas. Happy to let it go.

---

Auto-Updating CIDR Lists & Security Concerns

You raised a really important point here. Auto-updating CIDR lists on user routers is risky, especially when commands are getting injected. One mistake, and things could go sideways fast.

If you're not already doing this, here are a few ideas to consider:

• Check file integrity using a known SHA256 hash before applying anything
• Use signed CIDR lists with GPG and only trust verified ones
• Limit download sources to a hardcoded list of trusted domains
• Run the update logic inside a read-only container, stripped of exec rights

Just some food for thought if you ever revisit that feature later down the road. Definitely not something to rush into.

---

DNS Setup with Unbound, dnscrypt-proxy, and RPZ

I’m currently experimenting with Unbound as the primary resolver on my MikroTik setup. It’s rock solid, fast, and offers amazing flexibility — especially compared to dnsmasq, which just can’t handle modern needs like:

• Domain-aware routing (for CDN separation)
• DoH/ODoH support
• DNSSEC validation
• RPZ (Response Policy Zones)

One of the main reasons I'm using RPZ in Unbound is because it gives us total control over DNS resolution policies without needing to mess with the routing layer. Unbound handles all that beautifully and plays nicely with MikroTik. Plus, with Unbound's support for local-zone tagging, it integrates seamlessly into routing logic when needed.

Since I'm using a MikroTik hAP ax³ (also tested on RB5009), both powerful and Docker-capable, I’ve got the headroom to run Unbound + dnscrypt-proxy in containers together — and so far it's been super stable. That combo gives you the best of both worlds:

• DoH-first, with fallback
• DNSSEC support
• CDN-aware routing
• Full logging and RPZ capabilities

It’s honestly the closest thing to a "military-grade" DNS stack I’ve used outside of an enterprise environment.

---

Running Xray Core Inside MikroTik Docker

This is where things get spicy
I’m testing Xray Core on the same MikroTik (hAP ax³) in Docker containers. Here's what I’ve learned so far:

• MikroTik containers don’t support systemd, so you’ll need a lightweight, standalone Xray binary
• No GPU or crypto offloading, so under TLS, XTLS (an optimized TLS variant for Xray), or Reality you may hit performance ceilings — though the CCR2004 would be better here if I need to scale
• For light to moderate use (up to 5–10 users), it's handling things well, but I will load test further

Bottom line: Xray inside Docker on these MikroTik models is possible and practical, but it’s important to tune it right, monitor resource use, and expect some trade-offs.

---

.ir Domains, CDNs, and Smarter Routing

You’re absolutely right about .ir domains — most of them now sit behind global CDNs like Cloudflare and Akamai, so IP-based routing just doesn’t cut it anymore.

Here’s what I’m doing:

• Using RPZ in Unbound to tag .ir and other Iran-related domains
• Routing those tagged requests through the local ISP
• Sending everything else through Xray or WireGuard, depending on the setup

This approach gives you control without bloating the routing table or risking misroutes.
Everything happens at the DNS layer, so it stays cleaner, smarter, and simple.

Still experimenting with what happens if a tagged domain fails to resolve, might add fallback logic later (like forwarding to a backup DNS) if it makes sense.

---

Storage and Speed Note (for Docker Performance)

For container storage, I’m running everything on a SanDisk Ultra Luxe 64GB USB 3.1 stick with up to ~400MB/s real-world read speeds. This is critical if you're running containers — otherwise, you risk bottlenecks or high I/O latency that could cripple services like DNS or proxies.

Simple upgrade, big impact.

If you’re looking for even greater performance and reliability under load, an external SSD is a solid upgrade, faster, more durable, and better equipped to handle heavy workloads. And if price isn’t a concern, it’s easily the better choice.

So far, the hAP ax³ has held up impressively, and the RB5009 and CCR2004+ offer even more breathing room if needed. If you’re using similar hardware, this stack should work great for you too.

Beyond performance, the USB stick also doubles as persistent storage for critical container files, config backups, and update packages. In scenarios where automatic updates aren’t ideal or network access is limited, you can simply pre-load the latest versions onto the USB, plug it into the router, and let the system pull from there, no need to re-download or re-script from scratch.

---

Perspective on Starlink and Domestic Traffic Usage

I saw your point about Starlink and completely agree — it's not a cost-effective VPN exit node for most users, especially when you factor in mobile data prices and limited domestic uplink speeds.

That said, I’d like to offer another perspective based on real usage patterns in Iran, ISP pricing, and behavior trends.

Domestic Traffic is Often Discounted

Most Iranian ISPs apply around a 50% discount on domestic traffic, in line with national policy. This primarily covers a few key platforms like Snapp Taxi, Digikala, Divar, banking services, and select government sites, etc. So even without routing-level separation, domestic traffic typically accounts for a small portion of user costs and is limited in scope.

Over 90% of Real Usage is Foreign

In reality, more than 90% of Iranian internet activity is on international services like Instagram, WhatsApp, YouTube, app stores, and global learning tools. That’s why foreign traffic dominates bandwidth usage, which makes:

• Split-routing the most logical model
• Domestic traffic low-impact on bandwidth and cost
• Foreign traffic the real focus for privacy protection

With this ratio in mind, DNS-layer tagging plus smart policy routing gives you the precision without overengineering the setup.

---

Panel Features, Custom Routing & Built-in Testing Tools

Also just wanted to add something while we’re talking about the panel setup.
I love the idea of managing Xray Core, Sing-box Core, or anything else through a simple interface.
If we can make it easy for users to switch things on and off or control their proxies from a clean panel, that would be awesome.

One thing that could make this even better is adding a small section for custom domain-based routing. Like, a search bar or input field where users can either type in a domain manually (e.g. example.com) or pick one from a list. That way, if someone wants a specific domain to always go through the local ISP or the foreign proxy, they can just add it in a few seconds — no technical knowledge needed.

And maybe we can also include a test page inside the panel to help users check if everything's working the way it should. Something really simple like:

• Show which IP is being used right now, using websites like WhatIsMyIPAddress or IPView
• Let users test a couple of random domestic and foreign sites
• Show a clear result about whether the traffic is going through the right route
• Maybe even give a small summary like “✅ You’re good to go” or “⚠️ This domain is being routed incorrectly”

Just small touches like this could really help users feel confident that everything is running properly — without needing to dig into logs or guess what’s going on behind the scenes.

Of course, only if it’s realistic and won’t break the system or overload the router. Not critical features, just some quality-of-life ideas that might be nice finishing touches if they fit the design and performance limits.

---

Honestly, I’m just a noob figuring things out as I go, mostly out of necessity, but man, I’ve already learned so much thanks to this project. You guys are doing some seriously incredible work, and I know how heavy it must feel when there aren’t enough hands on deck. So please don’t take any of my messages as pressure, I’m not here as a passive consumer, I’m here as part of the crew, wrench in one hand, coffee in the other.

If there’s anything I can do, even in my limited way, I’m ready to roll up my sleeves. We’re all in this together, and if we keep chipping away at it side by side, we’ll get this beast flying smoothly and land it somewhere solid, maybe even with style.

Big respect, big appreciation, and all the fuel to keep building forward. 🤞🏽🙏🏽

تا ریشه در آب است امید ثمری هست
بر بام و در دوست پریشان نظری هست

[Phoenix-999]

@Cacti5

Just wanted to drop in with a quick follow-up, no pressure to reply fast or anything. Been thinking more about our setup after our last exchange, and I ended up testing a few new things that I thought might be worth sharing. Consider this a mini add-on to my earlier message, maybe helpful, maybe overkill, but I figured I’d throw it in the mix just in case.

Performance-Boosting Tweaks for MikroTik hAP ax³ (Starlink Setup)

After digging deeper into Starlink’s behavior and running some experiments on my hAP ax³, I found a few tweaks that noticeably improve stability, latency, and overall performance, especially under load. Nothing drastic, just tuning a few knobs RouterOS already gives us.

---

Smart Queuing (CAKE / fq_codel)

I tried enabling CAKE (also works with fq_codel), and it’s been a game changer for reducing latency spikes during uploads. Zoom, iCloud, even Discord feel noticeably smoother now.
CAKE and fq_codel auto-prioritize latency-sensitive traffic and even out bandwidth usage, basically stopping one device from nuking the network with a big upload.

Works natively in RouterOS v7 via:

/queue type add kind=cake ...

No Docker needed, takes two minutes to set up in Simple Queue or Queue Tree.

---

TCP MSS Clamping

One weird issue I ran into was MTU mismatches causing packet loss. Starlink often defaults to around 1420 MTU, but LAN clients assume 1500, which breaks things subtly.
A simple mangle rule like this solved it:

/ip firewall mangle
add chain=forward protocol=tcp tcp-flags=syn out-interface=starlink-wan action=change-mss new-mss=1380

Especially helpful if you're tunneling with VPNs or running containers.

---

Interface MTU Tuning

Related to the above, I manually set MTUs for key interfaces:

/interface set starlink-wan mtu=1420
/interface wireguard set wg0 mtu=1380

Definitely improves consistency, but yeah, you have to test carefully or risk breaking routing.

---

PCQ Queuing (Per Connection Queue)

This one’s underrated. I set up PCQ to make sure no single device can hog all the bandwidth, especially handy in shared setups. It works great on its own or alongside CAKE.

Here’s a simple setup:

/queue type
add name=pcq-download kind=pcq pcq-rate=150M pcq-classifier=dst-address
add name=pcq-upload kind=pcq pcq-rate=25M pcq-classifier=src-address

/queue simple
add name="FairShare" target=bridge-lan queue=pcq-upload/pcq-download

You can use it in Simple Queues or Queue Trees. The hAP ax³ handles it effortlessly with its quad-core CPU.
PCQ has been around since RouterOS v6 and got even better in v7. It’s a lightweight, software-based feature that runs before routing decisions, and it makes a big difference when the network gets busy.

---

FastPath

FastPath is a handy feature that lets your router speed up traffic handling while using less CPU. I enabled it with a simple command:

/interface bridge settings set use-ip-firewall=no

It speeds up traffic by skipping firewall, NAT, and queues, perfect for trusted LAN traffic and light network loads.
But here’s the catch, if you're using bridge firewall or NAT rules, FastPath will skip right over them, so it’s best to turn it off in those cases. Fully supported on the hAP ax³ And if you add any bridge-level filtering later on, yep, revisit this setting.

---

Nothing mission-critical here 😊
but all these little tweaks really helped dial things in , especially with Starlink doing its thing and a bunch of people jumping online at the same time. Just made everything feel smoother and way less annoying.

[Phoenix-999]